-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Re-implement edit-run #3751
Comments
I think we need to make the job file available in the GraphQL schema to that the clients can access it without having to go to the filesystem. Then the client sends a diff along with the trigger request to the scheduler. This will be a bit tricky for the UI as the forms are auto-generated and this involves an extra step so the diff field should use a custom type (extending string) to give the UI a fighting chance. |
My notes don't seem to have captured the Feb workshop discussion on this, but I think we were also considering presenting the parsed config via the UI, for edit-run capability, instead of the raw file. That could allow authorization control over different config items, for example. It would be presumably be a more complex solution to implement though. |
Since the job file is now just a bunch of functions called by the real job script (which you can't edit) there is very little value to being able to edit the actual job script itself. Being able to edit the script items and environment vars should suffice for all use cases, we can achieve this as broadcast+trigger. |
I must be misunderstanding you, as that seems to contradict your previous comment?? ("we need to make the job file available in the GraphQL schema to that the clients can access it", and then "there is very little value to being able to edit the actual job script itself.")
That's what I was suggesting - present the separate job config items, separately. Potentially then, we could allow the owner to edit any of those (mainly script and environment) and authorized others to only change environment variables (or perhaps even only some environment variables, but they'd have to be marked in the flow config somehow). |
Yes. In my second commend I'm suggesting that perhaps trigger-edit functionality does not need to be re-implemented, just use broadcast+trigger under the hood. This would require exposing the |
Alright, thanks for explaining - agreed then 🎉 |
Given this a little thought, two options for implementation using the query+broadcast model: Option 1 - use the
|
Especially if choosing option (2), suggest using Tui to provide the trigger-edit interface on the CLI. |
Note, we will need to apply active broadcasts to the configuration before returning the expanded configuration. |
I've spun off the |
I have opened a UI issue for this: cylc/cylc-ui#1104 |
Closing as superseded by: |
I know this is closed, but I think https://cylc.github.io/cylc-doc/latest/html/7-to-8/caveats.html#cylc-flow needs updating? |
cylc trigger --edit
was removed during SoD implementation. This is not really a "sod-follow-up" issue however (although I'm labeling it as such for now) because edit-run needs to be completely redone for Cylc 8 anyway, and for that it is a cross-component problem: cylc-flow, cylc-UI, and cylc-UIServer . It's not clear what needs to be done for this in cylc-flow yet.The text was updated successfully, but these errors were encountered: