Repository navigation
Support new Project & CLI features for integration tests - #1057
Conversation
|
I've got a little problem here on the I'm too tired and frazzled to fix this now - this stuff really needs a good cleanup. I'll take a look later and see if I can fix quickly (you'd think so!) but it may require deeper surgery. Very annoying. |
| const { jobs, edges, triggers, name, ...remoteProps } = workflow; | ||
| const mapped: l.Workflow = { | ||
| id: slugify(workflow.name), | ||
| id: workflow.id ?? slugify(workflow.name), |
There was a problem hiding this comment.
Not really sure about some of this actually - might have to think carefully about names and ids and ensure we have clean clear docs
| } | ||
|
|
||
| if (!checkedProject.name) { | ||
| if (!targetProject.name) { |
There was a problem hiding this comment.
I don't want to do it in this PR, but all this needs to be id focused. Name is an optional label now.
| */ | ||
| export type ExecutionPlan = { | ||
| id?: UUID; // this would be the run (nee attempt) id | ||
| id?: UUID; // TODO make required |
There was a problem hiding this comment.
Don't want to do it as part of this PR, but it's a good note for #1065
| name: string; | ||
| uuidSeed: number; | ||
| openfnUuid: boolean; | ||
| openfnUuid: boolean; // TODO probably need to do this by default? |
There was a problem hiding this comment.
@doc-han can you remember what this property was supposed to control?
I inherited it from the older workflow generator but I'm not sure the purpose
I think what we want is:
- By default everything will have a UUID generated for it
- All UUIDs will use the seed if set, otherwise they'll be legit UUIDs
- If you want, you can set an option like
withUUIDsto false to prevent UUIDs being generated. But this feels like a "feature request" to be added later
| if (!raw.id) { | ||
| // Workflow ID is required, so make sure it gets set | ||
| // before calling the constructor | ||
| raw.id = 'workflow'; |
There was a problem hiding this comment.
An important change here:
The Workflow class now MUST have an id value. But the generator will default it, so that you don't have to add @id x to all the workflows you want to define
| const project = fromAppState(state, config); | ||
|
|
||
| t.is(project.name, 'aaa'); | ||
| t.is(project.name, 'My Workflow'); |
There was a problem hiding this comment.
As part of #1065, in tests, when using the Name field I want it to look like a name, not an id. So include capital letters and spaces. This just helps explain how the different properties are used.
The workflow generator MUST generate a name ALso some stuff is off in state serialization
|
Turns out this branch was a bit broken. Filtering through the name id stuff has been super hard and confusing. Hope its up and running now! |
Allow projects to be generated with a uuid map
f5d4dcb to
eee562e
Compare
Adding various small features for the CLI - just enough to keep me moving forward
nameandidper What's in a name? #1065The CLI one maybe needs a bit more thinking about because where do we checkout TO? Probably any arbitrary folder (the passed project path or the current working dir). In this mode we should probably warn when not expanding to an openfn project, but we should do it (and generate an openfn.yaml).
This lets me expand a project to a local folder for testing and debug purposes.
I suppose by the same token I should be able to do like
openfn checkout staging --out-dir /tmp/staging- even iftmp/stagingisn't an actual repoAI Usage
Please disclose how you've used AI in this work (it's cool, we just want to know!):
You can read more details in our Responsible AI Policy
Release branch checklist
Delete this section if this is not a release PR.
If this IS a release branch:
pnpm changeset versionfrom root to bump versionspnpm installpnpm changeset tagto generate tagsgit push --tagsTags may need updating if commits come in after the tags are first generated.