Repository navigation
Support non-editable workflows #72
Description
In GitLab by @woutdenolf on Jan 10, 2026, 17:19 GMT+1:
For several use cases (bes, ewoksid31, ewoksid29, ewoksmx etc.) we are moving towards workflows shipped with the ewoksapps libraries.
Ewoks itself supports for load/execute/show like this
ewoks show "ewoksid29.workflows.ambigator_run" -o representation=json_module
ewoks show "ambigator_run" -o root_module="ewoksid29.workflows"
ewoks show "ambigator_run" -o representation=json_module -o root_module="ewoksid29.workflows"In ewoksserver, all workflows as JSON files in the backend and these workflows have an identifier which is the file name as well.
What we would need:
- Support loading and executing workflows from ewoksapps libraries.
- Editing of these workflows should not be allowed.
- Button to discover workflows and workflows discovery on server startup. So very similar to task discovery.
Migrated from GitLab: https://gitlab.esrf.fr/workflow/ewoks/ewoksserver/-/issues/72
Metadata
Metadata
Assignees
Labels
No labels
Type
Fields
priority
None yet
progress
None yet
Activity
poautran commentedon Jan 10, 2026
In GitLab by @woutdenolf on Jan 10, 2026, 17:23 GMT+1:
About current workflow identifiers in ewoksserver:
id.So that's a duplication. For example
PUT /workflow/{identifier}takes a JSON workflow and ifidentifier != workflows["graph"]["id"]that we get a 400 error.The
idin the graph attribute is used for logging and ewoks events.The file names are used to read, delete and list workflows.
poautran commentedon Jan 10, 2026
In GitLab by @woutdenolf on Jan 10, 2026, 17:35 GMT+1:
The workflow
ewoksid29.workflows.ambigator_runhasambigator_run.jsonworkflows["graph"]["id"] = workflow_ID29ESRF_ambigator_runThese are no equal and the scope is the
ewoksid29package. Neither is guaranteed to be unique in the scope ofewoksserver.So the question is, what would be the id in the scope of ewoksserver?
Should we change the way we handle workflow id's in ewoksserver overall and decouple them from graph id's? That could lead to confusion when debugging. Also the id's in the ewoks events need to be the same as the workflow id's in the server I think.
Ewoksserver could load the workflows instead of letting the worker load them. In that case it could change
workflows["graph"]["id"]when executing to the ewoksserver id. To be discussed.woutdenolf commentedon Jul 6, 2026
Discussed with @loichuder : in the first approach everything will be handled in the backend
woutdenolf commentedon Jul 6, 2026
Needs workflow discovery to be exposed by the workers: ewoks-kit/ewoksjob#341.