@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.
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.
Allow the rules DSL & GUI component to operate on existing collections to allow filtering, sorting, modifying identifiers and general re-organization of existing collections (e.g. the outputs of tools). Implementing this as a collection operation tool so that it should be executable interactively in the tool form and in a batch fashion as part of workflow executions.
For this to be tracked properly as a tool execution and to work properly in the tool form, I've implemented a new tool framework and tool form parameter type called "rules".
This can thought of as a more GUI friendly alternative to my proposed collection operations that consumed JavaScript expressions.
This includes API tests for both tool and workflow execution of the new tool as well as Selenium tests for tool form execution, workflow editor interactions, and workflow running.
Re-use test_data specification used by many of the API workflow tests and a workflow used by another test. Add abstractions and DOM element for mapping labeled test data to tool form inputs.
- More stuff tested:
- Connecting and disconnecting simple terminals as well as mapping terminals (ribbons).
- Rendering simple workflows, workflow with output collections, workflow with mapping, and workflow with a subworkflow.
- Collapsing side panels in the workflow editor.
- Small tweaks to editor DOM.
- More screenshots.
I did a few of these test conversions with 0ff639a29c but this covers many more the workflow API tests. The idea is to switch to this with statement and context manager that does a better job managing test histories including summarizing the history when problems occur (this summary will include job information after #5697).
This is using the simplest of workflows. I had to
remove the chromInfo part from the workflow, because the
path referenced would be changed dynamically and so the
job search wouldn't recognize this as being equivalent.
John Chilton