Projects v2: ensure a start node is set

[josephjclark]

When using new Project fetch to pull a project, the workflow.yaml a) does not include a start step and b) orders steps by id.

The problem with this, of course, is that when you try and run the workflow, it won't start from the trigger node - it'll start from the first step!

Either we need to pin the trigger to be the first step - which is a bit wierd. Or we need to set the start option in the workflow.yaml to be the trigger.

This start option needs to get ignored when pushing to the app. That needs a bit of finessing. I'd prefer that all options sync, or none of them - not a different rule per option.

[josephjclark]

Dang, this is slightly thorny.

The old workflow .json had the structure { workflow, options }

But the new workflow.yaml is just the workflow stuff, no top level workflow key.

And yet the workflow.yaml is actually executable!

So which is right?

Well I like the new workflow.yaml structure so let's keep that. I just want to check the implementation to understand how that works, because it sort of shouldn't

That means either:

• We have a new options key, and I have to decide whether options are synced
• We have a new start key, which specifies the start note
• We have a new cli key, where CLI only options like start can sit

We already have a CLI key elsewhere, so we do have precedence. And I like that it doesn't sync. So maybe let's do that.

On the other hand, alias is also CLI only and that's a top level key, not on the cli object.

[josephjclark]

This results in a diff in the runtime, where we read plan.options.start. Now we'd do plan.workflow.start.

Other supported options include timeouts, end, sanitise policies. If not supported already you can imagine statePropsToRemove might go here. Maybe also it would be nice to save memory limits, so that you can run with the same constraints as the app (this has been requested).

I think what this is telling me is that the correct approach is to keep start as an option, and to update how workflow.yaml gets serialized.

The top workflow key does annoy me a bit though. Maybe we should write all this stuff to workflow.options after all. We'd need legacy support for the old format.

[josephjclark]

Yeah ok, look: the bit that loads a workflow.yaml is actually kinda wrong. It bypasses the { workflow } top key.

So, related issue: refactor how we load workflow.yaml files. This is also related I think to the work in executing directly from a project - something else I got in a knot over.

[josephjclark]

Done in #1214