- Allow workflows to be uploaded via path using the GUI and and API for admins.
- Track the path and resync workflows on save (both .ga and format 2 workflows) - this will allow Planemo to leverage the Galaxy workflow editor to interactively save workflows.
We don't track workflow step inputs in any formal way in our model currently. This has resulted in some current hacks and prevents future enhancements. This commit splits WorkflowStepConnection into two models WorkflowStepInput and WorkflowStepConnection - normalizing the previous table workflow_step_connection on input step and input name.
In terms of current hacks forced on it by restricting all of tool state to be confined to a big JSON blob in the database - we have problems distinguishing keys and values when walking tool state. As we store more and more JSON blobs inside of the giant tool state blob - the worse this problem gets. Take for instance checking for runtime parameters or the rules parameter values - these both use JSON blobs that aren't simple values, so it is hard to tell looking at the tool state blob in the database or the workflow export to tell what is a key or what is a value. Tracking state as normalized inputs with default values and explicit attributes runtime values should allow much more percise state definition and construction.
This variant of the models would also potentially allow defining runtime values with non-tool default values (so default values defined for the workflow but still explicitly settable at runtime). The combinations of overriding defaults and defining runtime values were not representable before.
In terms of future enhancements, there is a lot we cannot track with the current models - such as map/reduce options for collection operations (https://github.com/galaxyproject/galaxy/issues/4623#issuecomment-389544980). This should enable a lot of that. Obviously there are a lot of attributes defined here that are not yet utilized, but I'm using most (all?) of them downstream in the CWL branch. I'd rather populate this table fully realized and fill in the implementation around it as work continues to stream in from the CWL branch - to keep things simple and avoid extra database migrations. But I understand if this feels like speculative complexity we want to avoid despite the implementation being readily available for inspection downstream.
Don't treat data and non-data inputs/outputs different at the API boundary or at the workflow-manager.js level. Keep differences at the level of walking inputs/outputs in the workflow module on the backend and at the terminal definition (models and views) level on the frontend. Make the code and interfaces more consistent in my opinion and is more compatible with future directions I'd like to take things with mix-mode inputs/outputs for CWL.
@mvdbeek and I discussed this in the Galaxy project gitter a few weeks ago and decided the propagation is too aggressive and should likely be done manually at the end of a workflow for now - using for instance the set tags collection operation tool.
- Selenium test case demonstrating their use in simple workflows.
- API test demonstrating they work with nested workflows from the run perspective.
- Update run variant of workflow to_dict to parse out replacement parameters to display on the backend and tweak the client to just accept these.
- Parse out replacement parameters for subworkflows recursively, include in new run output attribute - nested workflow replacement parameters work now.
- Selenium test case demosntrating subworkflow replacement parameters are rendered and used when submitted.
That should make the test less flakey. While in theory we should be able
to replace scheduled workflow jobs with cached jobs, this is not what
we're testing here, and I assume it doesn't work for now.
Turns out integers are used as is in `random.seed()`, but strings are
hashed (in the version 1 protocol), and the hashing isn't stable. So
instead we hack around this by using `ord()` on each character and
concatenating the digits. Yucky, but probably better than using numpy
and putting this tool on the list of tools that inherit galaxy's
environment (or adding a requirement tag and resolving with conda ...).
This doesn't quite work because of the dynamic output collection,
which fails with:
```
galaxy.tools.parameters.output_collect DEBUG 2018-06-06 18:40:38,784 (3) Add dynamic collection datasets to history for output [reverse] (171.970 ms)
galaxy.tools.parameters.output_collect ERROR 2018-06-06 18:40:38,839 Problem gathering output collection.
Traceback (most recent call last):
File "/Users/mvandenb/src/galaxy/lib/galaxy/tools/parameters/output_collect.py", line 340, in collect_dynamic_outputs
collection_builder.populate()
File "/Users/mvandenb/src/galaxy/lib/galaxy/dataset_collections/builder.py", line 88, in populate
elements = self.build_elements()
File "/Users/mvandenb/src/galaxy/lib/galaxy/dataset_collections/builder.py", line 59, in build_elements
new_elements[identifier] = element.build()
AttributeError: 'HistoryDatasetAssociation' object has no attribute 'build'
```
This seems to happen because the inner collection is wrongly detected as
nested. In general I doubt that mapping over colleciton output works
with dynamically discovered output collections.
mvdbeek