Demonstrates using the Apply Rules collection operation tool against existing collections to:
- Use grouping to build nested lists from flat ones.
- Invert nested collections.
- Filter collections.
- Filter while also grouping to build nested collections.
Based on count data used in the DESeq2 tutorial (http://bioconductor.org/packages/devel/bioc/vignettes/DESeq2/inst/doc/DESeq2.html), originally from the Bioconductor Pasilla package (http://bioconductor.org/packages/release/data/experiment/html/pasilla.html). Citation: Huber W, Reyes A (2018). pasilla: Data package with per-exon and per-gene read counts of RNA-seq samples of Pasilla knock-down by Brooks et al., Genome Research 2011.. R package version 1.8.0.
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.
- Replace test using Cut1 with two tests each using framework test tools loaded with Selenium tests by default.
- Create a symbolic link so that tour generator is configured with default test webhooks.
- Establish and use components and navigates_galaxy.py abstractions for tour generation and navigation.
- In one of the tool tests actually walk the tour (previously we only verified the initial tour popover).
I'm pretty sure the problem is that I was waiting on conditions (e.g. datasets to become "ok") using the API and then assuming the state of the GUI elements was the same. Obviously though the GUI is polling the API and there is some lag there. This commit changes things to specifically wait on history panel GUI changes - obviously the better thing to wait on in a GUI test.
Expand and then break out workflow management tests into its own file since these aren't related to the workflow editor per se. Includes new tests of workflow "viewing" and "renaming".
Add a new file for testing workflow execution. This currently contains tests for simple execution with a single input and a test for running workflows with tool version upgrades.
This includes a refactoring of some existing tests related to checking various things in the history panel - as part of building up good history panel abstractions. The previous constructs were ported fairly literally from older CasperJS tests. These abstractions therefore referred to everything has "hda"s instead of history items. The newer abstractions therefore allow for collections and are built around HIDs (a visual thing exposed to the user) instead of HDA IDs. I think this is higher-level and more appropriate for a web functional test.
Rebase into workflow GUI tests.
- Test parameters and tables appear on dataset details page after running a tool.
- Test a simple tool execution with an integer field.
- Test re-run a tool.
- Test a tool with a data drop down.
- Improved select2 abstractions.
Marius van den Beek