This strategy proved to work around certain race conditions in tool testing so hopefully it will solve the transiently failing job searching and filtering test cases.
This is a slight tightening up of the ad-hoc, experimental workflow YAML definition used by the test framework (and by Kyle, but lets just admit Kyle is part of Galaxy's test framework).
This format is still defined entirely client side by transcoding the YAML or python object description into real (or format 1) Galaxy workflows - so these cannot realisticaly be declared part of Galaxy's public interface and can remain experimental and subject to change.
In addition to refactoring the code implementing these workflows for upstream modifications to explore new features, the format itself has been made slightly more stringent in two ways:
- 'steps' must now be explicit (previously converted auto-convert list to dict).
- Ensure the workflow declared a 'class' is defined and the class is 'GalaxyWorkflow'.
This will help with discovery of workflow objects with downstream tooling (planemo for workflows?) and brings the Galaxy definition slightly more inline with the CWL definition for workflows (very slightly).
Continuation of work started by @nsoranzo here 92a152d89c. In addition to increasing the max timeout it will now print the timeout in the assertion error so we can see if it is being overridden and attempt to adjust timeouts too small.
For tools which dynamically discover datasets for an output collection, keep the collection yellow until the structure of the HDCA has been fully defined. HDCAs still have the problem that they will always be green even if datasets contained within are in error, running, or queued states - but at least the structure is now reflected in the color.
By default if single data parameters are mapped over by collections, the collections are matched up (e.g. for two collections the items are paired off and two collections of dimension (N) will result in running N jobs and producing an (N) dimensional output for each define output). In the parameter meta value wrapper (where batch mode can be set with the ``batch`` flag), the linked flag is now respected for collection operations. If ``linked`` is ``False``, then the cross product of the inputs will be used to map over the tool. In the above simplest case, this would cause an NxN (``list:list``) collection to be created for each tool output.
This operation was previously available for individual datasets, but when supplied a collection it would not create an implicit collection pulling together all the relevant datasets with the correct structure - it would just run the jobs and leave the datasets uncollected. Now a collection with the correct structure and identifiers is created.
Limitations:
-----------------
This does not enable tool form support but the API for collections matches that for doing cross product operations over sets of individual datasets, so once support is added to the tool form for that collection support should be trivial.
Testing:
-----------------
The following test case has been extended to now ensure that an implicit collection is created and that it has the right dimensionality/structure and contents.
./run_tests.sh -with_framework_test_tools -api test/api/test_tools.py:ToolsTestCase.test_map_over_two_collections_unlinked
Runtime post job actions are post job actions inserted when the workflow is invoked instead of being part of the workflow object in the database. The bug noticed by @kellrott was that these actions were being appended to the original workflow post job actions instead of being transient things just attached to the jobs themselves.
This fixes that problem and adds a test to try to prevent regressions.
- Add example tool demonstrating/testing specifing format via conditional output actions.
- Add API test testing mapping collections over tools without output action formatting.
- Add API test testing more complex actions using the Cut1 tool.
- Add script to hit the API with workflows requests.
- Update testing Dockerfile to allow just booting up with a fixed master API key for this test to leverage.
- WIP: on updating test Dockerfile to work with slurm, multiple handlers, uwsgi, etc...
Going to use bioblend for performance testing instead of galaxy_interactor. This refactoring allows all of those helpers to be reused with bioblend backing the helpers instead of galaxy_interactor.
John Chilton