mirror of
https://github.com/galaxyproject/galaxy.git
synced 2026-09-24 16:30:27 +08:00
John Chilton
67efd072ae
We don't track workflow step inputs in any formal way in our model currently. This has resulted in some current hacks and prevents future enhancements. This commit splits WorkflowStepConnection into two models WorkflowStepInput and WorkflowStepConnection - normalizing the previous table workflow_step_connection on input step and input name. In terms of current hacks forced on it by restricting all of tool state to be confined to a big JSON blob in the database - we have problems distinguishing keys and values when walking tool state. As we store more and more JSON blobs inside of the giant tool state blob - the worse this problem gets. Take for instance checking for runtime parameters or the rules parameter values - these both use JSON blobs that aren't simple values, so it is hard to tell looking at the tool state blob in the database or the workflow export to tell what is a key or what is a value. Tracking state as normalized inputs with default values and explicit attributes runtime values should allow much more percise state definition and construction. This variant of the models would also potentially allow defining runtime values with non-tool default values (so default values defined for the workflow but still explicitly settable at runtime). The combinations of overriding defaults and defining runtime values were not representable before. In terms of future enhancements, there is a lot we cannot track with the current models - such as map/reduce options for collection operations (https://github.com/galaxyproject/galaxy/issues/4623#issuecomment-389544980). This should enable a lot of that. Obviously there are a lot of attributes defined here that are not yet utilized, but I'm using most (all?) of them downstream in the CWL branch. I'd rather populate this table fully realized and fill in the implementation around it as work continues to stream in from the CWL branch - to keep things simple and avoid extra database migrations. But I understand if this feels like speculative complexity we want to avoid despite the implementation being readily available for inspection downstream.
70 lines
1.7 KiB
Python
70 lines
1.7 KiB
Python
from galaxy.workflow import render
|
|
from .workflow_support import yaml_to_model
|
|
|
|
TEST_WORKFLOW_YAML = """
|
|
steps:
|
|
- type: "data_input"
|
|
order_index: 0
|
|
tool_inputs: {"name": "input1"}
|
|
position: {"top": 3, "left": 3}
|
|
- type: "data_input"
|
|
order_index: 1
|
|
tool_inputs: {"name": "input2"}
|
|
position: {"top": 6, "left": 4}
|
|
- type: "tool"
|
|
tool_id: "cat1"
|
|
order_index: 2
|
|
inputs:
|
|
input1:
|
|
connection:
|
|
- "@output_step": 0
|
|
output_name: "di1"
|
|
position: {"top": 13, "left": 10}
|
|
- type: "tool"
|
|
tool_id: "cat1"
|
|
order_index: 3
|
|
inputs:
|
|
input1:
|
|
connection:
|
|
- "@output_step": 0
|
|
output_name: "di1"
|
|
position: {"top": 33, "left": 103}
|
|
"""
|
|
|
|
|
|
def test_render():
|
|
# Doesn't check anything about the render code - just exercises to
|
|
# ensure that obvious errors aren't thrown.
|
|
workflow_canvas = render.WorkflowCanvas()
|
|
|
|
workflow = yaml_to_model(TEST_WORKFLOW_YAML)
|
|
step_0, step_1, step_2, step_3 = workflow.steps
|
|
|
|
workflow_canvas.populate_data_for_step(
|
|
step_0,
|
|
"input1",
|
|
[],
|
|
[{"name": "di1"}],
|
|
)
|
|
workflow_canvas.populate_data_for_step(
|
|
step_1,
|
|
"input2",
|
|
[],
|
|
[{"name": "di1"}],
|
|
)
|
|
workflow_canvas.populate_data_for_step(
|
|
step_2,
|
|
"cat wrapper",
|
|
[{"name": "input1", "label": "i1"}],
|
|
[{"name": "out1"}]
|
|
)
|
|
workflow_canvas.populate_data_for_step(
|
|
step_3,
|
|
"cat wrapper",
|
|
[{"name": "input1", "label": "i1"}],
|
|
[{"name": "out1"}]
|
|
)
|
|
workflow_canvas.add_steps()
|
|
workflow_canvas.finish()
|
|
assert workflow_canvas.canvas.tostring()
|