[GCC2024 - CoFest] Workflow editor embed ignore errors

[ElectronicBlueberry]

Adds a flag to the workflow editor embed which sets the workflow editor to ignore errors, and render the workflow with the information available.

Same workflow with flag disabled and enabled:

The editor is still missing important information about the tools, which is why this representation is not accurate. It does however give a much better understanding of what the workflow is supposed to do, and serves as a first step towards rendering workflows on any server.

How to test the changes?

(Select all options that apply)

• I've included appropriate automated tests.
• This is a refactoring of components with existing test coverage.
• Instructions for manual testing are as follows:
  1. [add testing steps and prerequisites here if you didn't write automated tests covering all your changes]

License

• I agree to license these and all my past contributions to the core galaxy codebase under the MIT license.

[mvdbeek]

I think we should always be in the ignore errors mode, but we should probably also render the nodes with some warning indicator ? 💀

[ElectronicBlueberry]

Yes, for the editor I agree. For the embed I do not think we should always show warnings, since rendering any workflow for an embed is a potential use-case.

If I understood #18470 correctly, this would allow us to retrieve the tool inputs from the toolshed?

I'm thinking that this would enable utilizing this mode in the editor in a more useful manner. A warning could be shown on each tool that isn't installed, but the correct inputs and outputs displayed, and the workflow could even remain fully editable.
I'd then like this to be the default view, with the ignore errors flag disabling the warnings visually for embeds.

[mvdbeek]

I don't think I understand in which view you would not want to know that a tool isn't available, embedded or not. If I see a preview of the workflow and I see the tools are not installed I'd probably move on to another workflow or instance. There's also the concept of dynamic tools, which might e.g. not be shared with you (yet).

If I understood #18470 correctly, this would allow us to retrieve the tool inputs from the toolshed?

yes, eventually

A warning could be shown on each tool that isn't installed, but the correct inputs and outputs displayed, and the workflow could even remain fully editable.

I agree, but being able to see the inputs and outputs on steps for which we don't have the tool doesn't need to wait on the tool state work.

[ElectronicBlueberry]

I don't think I understand in which view you would not want to know that a tool isn't available, embedded or not.

An embed can be set to be a purely visual preview, not linking to the instance it is being rendered from. In that case knowing if the tool is available or not is irrelevant, and the warning that the tool is not installed could even be distracting/confusing.

[hexylena]

If I see a preview of the workflow and I see the tools are not installed I'd probably move on to another workflow or instance

it was my use case, that I discussed with @ElectronicBlueberry, we're generating some .. rather unattractive previews of workflows currently (e.g. this one) and were considering how we could replace that with a better more useful preview. @ElectronicBlueberry and I discussed loading the workflows in a real galaxy to either embed or render a png that could be used as workflow preview in the GTN. I'd like to be sure that all of the nice features like workflow comments are also rendered.

So it's explicitly a use case not related to a specific Galaxy. And as for which instance it's displaying on, we can make a reasonable guess on the GTN side of "which galaxy has every tool needed for this workflow", which we could probably use to pick and choose which server we rendered it on, but there may not be a server for which we have api credentials where we could upload + render the workflow, and we would still like to generate some preview that's maximally useful.

[mvdbeek]

That's fine for the embed case, but WorkflowPublished should definitely show something.

[mvdbeek]

(e.g. this one)

this is nice, what do you use to generate these ?

[hexylena]

ancient graphviz dot, actually 😅, with emojis and galaxy's font so it's not as ugly as their default serif.

some ruby code to loop over the steps sequentially, in a really unintelligent way (e.g. subworkflows are just rendered as a box)
https://github.com/galaxyproject/training-material/blob/main/_plugins/jekyll-topic-filter.rb#L462-L526

and then let the classic dot render organise them sensibly. it's also exposed in the API (ctrl-f for graph_dot)
https://training.galaxyproject.org/training-material/api/topics/single-cell/tutorials/scrna-case_alevin/tutorial.json