-
-
Notifications
You must be signed in to change notification settings - Fork 867
Description
Today to specify a task config file and override things like params
and inputs
, you do:
- get: concrete-input
- task: foo
file: input/foo.yml
config:
params: {FOO: 1}
inputs:
- name: concrete-input
path: generic-input
This is all well and good but things get weird when we add more things to task configs. For example, we don't override outputs
since we're not sure what would even mean. Turns out we do support overriding inputs
, which is done via a wholesale merge, and is occasionally used to remap a generic input name to a concrete one, while preserving the path.
It's also weird that config
contains essentially a partially instantiated task config, meaning if config
and file
are both present, it doesn't have to be valid, but if only config
is present, it has to be valid.
Today we merge the following fields:
platform
- not sure why, seems like the task.yml
should know this ahead of timeimage
- same, don't know when you'd want to override thisparams
- the most common use case (passing in secrets via pipeline config)inputs
- this is used for remapping input names while preserving the path expected by the.yml
, but it feels pretty inelegantrun.path
- also not sure why this is overrideable
So, instead, we should:
- no longer allow specifying both
config
andfile
- expect
config
to always be a fully-defined task config, if specified - no longer support overriding
platform
,image
,inputs
, andrun.path
- promote
params
to a separate field (maybe just reuseparams
and ensure the values are always strings on atask
step) - add configuration for remapping task inputs by name, e.g.
input_names: {generic-name: concrete-name}
Additionally folks have tried overriding outputs
, similar to how we support overriding inputs
, but that's just not implemented (part of the risk of overloading task config). We could add an output_names
mapping similar to input_names
mentioned above.
The full result would be something like:
- get: concrete-input
- task: foo
file: input/foo.yml
params: {FOO: 1}
input_names: {generic-input: concrete-input}
output_names: {generic-output: concrete-output}