Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not require for all task inputs to be filled by the calling workflow #347

Closed
wants to merge 7 commits into from
Closed

Do not require for all task inputs to be filled by the calling workflow #347

Changes from all commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
10b055e
lift requirement for all workflow inputs to be filled
rhpvorderman Dec 11, 2019
dcbfafa
address @davycats review comments
rhpvorderman Dec 11, 2019
ecd270d
encourage filling in required inputs for tasks
rhpvorderman Jan 28, 2020
6ba8da5
Merge branch 'reworkinputs' of github.com:/rhpvorderman/wdl into rewo…
rhpvorderman Jan 28, 2020
60fcf59
Integrate cjllanwarne's proposal
rhpvorderman Feb 6, 2020
134f090
remove redundant new line
rhpvorderman Feb 6, 2020
549eed6
better wording
rhpvorderman Feb 6, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
30 changes: 25 additions & 5 deletions versions/development/SPEC.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2600,11 +2600,31 @@ In this example, `i`, and `f` are inputs to this task even though `i` is not dir

## Computing Workflow Inputs

Workflows have inputs that must be satisfied to run them, just like tasks. Inputs to the workflow are provided as a key/value map where the key is of the form `workflow_name.input_name`.

* If a workflow is to be used as a sub-workflow it must ensure that all of the inputs to its calls are satisfied.
* If a workflow will only ever be submitted as a top-level workflow, it may optionally leave its tasks' inputs unsatisfied. This then forces the engine to additionally supply those inputs at run time. In this case, the inputs' names must be qualified in the inputs as `workflow_name.task_name.input_name`.

Workflows have inputs that must be satisfied to run them, just like tasks.
Inputs to the workflow are provided as a key/value map where the key is of the
form `workflow_name.input_name`.

* A task usually has its inputs supplied when called by a workflow.
* Example: `call my_task { input: my_task_input=... }`
* A workflow is allowd not to specify all inputs in this block. In this case,
the inputs bubble up to become an input to the workflow instaead.
* Example: an unsupplied input might have the fully-qualified name
`my_workflow.my_task.my_task_input.`
* If that workflow is used as a subworkflow, the input is allowed to bubble up
again with a further-qualified name.
* Example: my_outer_workflow.my_workflow.my_task.my_task_input.
* There is currently no way to supply a bubbled-up input in an outer workflow's
call block.
* Example: one cannot say call my_workflow as subworkflow
`{ inputs: my_task.my_task_input=... }`
* All **required** inputs which bubble up like this must ultimately be provided
in the inputs set before the top-level workflow can be run.
* An engine must allow **optional** bubbled-up inputs to be filled in by end
users. These inputs are not required to be filled.
* Showing all optional inputs which are deeply nested in the workflow can lead
to a very large number of inputs. Therefore, it is up to the engine how many
layers of nesting it chooses to make visible in the UI.

Any declaration that appears outside the `input` section is considered an intermediate value and **not** a workflow input. Any declaration can always be moved inside the `input` block to make it overridable.

Consider the following workflow:
Expand Down