- 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.
We're now just copying the current python path. Also the handler names
have actually changed, I think this hasn't been updated after a late
change (it is now as it should be, based on the documentation).
There was an existing library dataset permission API and one proposed for HDAs in #6461. This tries to reconcile the two approaches and move toward managers.
- Proper treatment of "master_api_key" throughout the manager layers related to this.
- Use PUT instead of POST, since that is more appropriate for updates I believe.
- Use a similar URL pattern for library datasets, history contents, and dataset APIs.
- Generalize the dataset API to allow HDA or LDDA inputs (the proposal for the new API in #6461 added an HDA-only option to the dataset API - this isn't how that API layer is meant to be used I believe).
- Add an HDA only endpoint in the history contents API for this functionality to mirror the library dataset API.
- Use consistent and backward compatible payload parsing for these endpoints.
- Use consistent serialization for the result of these changes.
- Generalize the HDA variant of this to allow different actions - such as make public and make private that were available in the library dataset variant.
- Test cases for the new API endpoints, the roles API, tests for permissions during collection creation and running tools with both dataset and collection inputs.
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 ...).
Usually tests should have new histories but we should still capture this information so we can target tests are particular histories for debugging interactively and so we could potentially reduce the number of new histories created when testing remote Galaxies (there have been complaints about this in the past).
This seems to be necessary so that the workflow_stability test passes
under python 2 and python3, but does change the result under python 2,
hence the updated workflows (produced by uploading and downloading the
workflow to an instance running with this commit).
- Test hierarchical store uses its first disk store for new files and not the remaining entries.
- Test basic functionality of writing to the distributed object store.
- Test all job outputs get placed in the same object store.
Unlike upload 1.0, use different 'src' types to distinguish between URLs and pasted content - in the abstract this is better because it is more structured and practically this allows 'pasting' spreadsheets that start with URLs for instance (that is sometimes useful).
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.
John Chilton