schema: add source workflows

[oliver-sanders]

Add source workflows to the schema.

Unblocks cylc/cylc-ui#548, though we will probably want to extend this to subscriptions for that.

Check List

• I have read CONTRIBUTING.md and added my name as a Code Contributor.
• Contains logically grouped changes (else tidy your branch by rebase).
• Does not contain off-topic changes (use other PRs for other changes).
• Applied any dependency changes to both setup.cfg (and conda-environment.yml if present).
• Tests are included (or explain why tests are not needed).
• CHANGES.md entry included if this is a change that can affect users
• Cylc-Doc pull request opened if required at cylc/cylc-doc/pull/XXXX.
• If this is a bug fix, PR should be raised against the relevant ?.?.x branch.

[dwsutherland]

Looks fine, tests passing.
Probably would need to create this on the cylc-flow end to add to subscriptions (which might make more sense, as field(s) in a data-store).

[hjoliver]

Is that a formal review/approval @dwsutherland ?

[oliver-sanders]

Getting this into subscriptions would make sense, making it easier for cylc-ui views to access this information.

Would we have to add these fields in cylc-flow or could we shim them into cylc-uiserver similar to how we extend the GraphQL schema?

[dwsutherland]

Would we have to add these fields in cylc-flow or could we shim them into cylc-uiserver similar to how we extend the GraphQL schema?

Well, if we add this to the cylc-flow schema then:

• it will be available both ends (schd and UIS)
• we may not need to figure it out if the Scheduler already knows (i.e. the resolver code here)
• and if it's a workflow field of the data-store, then it's automatically in the subscriptions

[oliver-sanders]

Because this is UIS specific functionality that the Scheduler should never know about it would be better to try and keep this logic centralised in cylc-uiserver. Is is possible to extend the protobuf schema in a similar way to how we extend the GraphQL schema?

[dwsutherland]

Ah, so it's not about knowing the source of installed/running workflows, it's about knowing cylc-src or it's aliases...

Yeah, better to keep it at UIS then, and we shouldn't need to deal with protobuf .. can just extend the subscriptions at the UIS

[oliver-sanders]

Ok, I'll look into doing that. Would it be possible to extend the store to hold this or would I need to add a parallel store?

[oliver-sanders]

(may as well draft this until the fields are available in subscriptions)

[oliver-sanders]

(rebased)

[oliver-sanders]

(may as well draft this until the fields are available in subscriptions)

I've now got a use case for this which doesn't "require" the data to be available via subscriptions - opening source workflow directories in Jupyter Lab.

Jupyter Lab appears only to work with relative file paths, not absolute ones, so I have added the path to the source workflow relative to the server's CWD.

[dwsutherland]

Nice:

Extending to subscriptions wouldn't be too hard, but like this I suppose you'd need to import more subscription machinery (to add it as a field of workflows sub).. Which we may end up doing more and more, the way we're heading.
Although it could just be a separate subscription (like logs etc), it shouldn't exactly change for a running workflow (?)