Test cases and one small fix to ensure this.
This should allow the API (or at least many of the actions) to work without knowledge of a toolbox potentially and I think it will allow use to track the tool state upgrades the workflow editor does automatically more formally.
Builds on refactoring the workflow run form landing and orchestration into Vue (#9147).
Implements #9111 - part of https://github.com/galaxyproject/galaxy/projects/15 and outlined in http://bit.ly/simplified-workflow-ui.
What is in the PR:
- Add new Galaxy configuration option - ``simplified_workflow_run_ui`` set to ``off`` by default.
- If instead the admin has set this parameter to ``prefer``, on the workflow run page scan the workflow run request and if three conditions are met show a simplfied tool form. These conditions are:
- No workflow "resource parameters" - pretty niche, not documented, I don't think anyone outside of Canada is using them and even them I'm not sure if they ever got to production.
- No "open" tools (i.e. tools with disconnected runtime inputs).
- No "replacement parameters" defined outside PJAs. I'm calling #{} inside PJA and ${} inside tool steps both "replacement parameters" because the user populates them the same way in the GUI. The API only handles them inside the context of the PJA - it seems the GUI is responsible for replacing them at runtime in the traditional form.
- The simplified workflow form:
- Drops tool and subworkflow steps from rendering all together and instead just renders the inputs. These are not rendered as separate "steps" or forms - but as just different inputs the same clean, simple form (more the like tool GUI). Labels (or step indexes as a fallback) are used at the input name, step annotations are used as the input help text.
- Simplify the workflow request made by the client - send only replacement parameters and inputs - do not serialize tool state for each module. I think this makes what we are tracking more structured and should be more performant as well. Prevents storing HDA IDs in unstructured JSON blobs in the database as well.
- Drops history target option to simplify the UI - simplified_workflow_run_ui_target_history can be set to either 'current' or 'new' to adjust this parameter Galaxy-wide for the simplified form.
- Drops job caching option to simplify the UI - simplified_workflow_run_ui_cache can be set to 'off' or 'on' to change this parameter Galaxy-wide for the simplified form.
- Drops resource parameters - we've already verified there are none for simplified workflows.
Split test/base into lib/galaxy_test/base and lib/galaxy_test/driver. Dividing things on whether they import galaxy-app code or not - with the goal of a galaxy-test-base package that doesn't depend on galaxy-app and a galaxy-test-driver package that does.
I've been refactoring around this division for a long time. Certain tests (namely the integration tests) always need to bootstrap Galaxy - but the API tests and the Selenium tests should be installable and runnable without Galaxy in the Python environment. So future galaxy-test-api and galaxy-test-selenium packages should have only an optional dependency on galaxy-test-driver.
Properly sturcturing these namespaces is a precursor for real packages on PyPI, clean separation of the tool shed testing code, and cleans up all the flake8 noqa hacks in test/.
Alexander OSTROVSKY