Now that steps arguments are declared as dicts in the manifest, it's sometimes redundant to declare a separate key-value mapping for a value used only in one step.
Now:
steps:
[...]
foo-example-2:
[...]
- name: bar
inputs:
flag_one: some_val_used_once
flag_two: specific_to_ex2
flag_three: canonical_val
[...]
foo:
[...]
- name: bar
[...]
inputs:
# flag_one not used
flag_two: specific_to_bar
flag_three: canonical_val
[...]
paths:
[...]
canonical_val: "canonical and used many places"
some_val_used_once: "zyzzy"
specific_to_ex2: "example 2"
specific_to_bar: "canonical but only used once"
With literal strings:
steps:
[...]
foo-example-2:
[...]
- name: bar
inputs:
flag_one: "zyzzy"
flag_two: "example_two"
flag_three: canonical_val
[...]
foo:
[...]
- name: bar
[...]
inputs:
# flag_one not used
flag_two: "canonical but used only once"
flag_three: canonical_val
[...]
paths:
[...]
canonical_val: "canonical and used many places"
To my eye this would be easier to read, because it puts the full definition into the manifest steps without needing to scroll around to find variable definitions, and it means there's only indirection in places it's enforcing shared values.
@hdpriest-ui started an implementation of this in an early draft of #44 and may still have (or be able to quickly reconstruct) the code.
Now that steps arguments are declared as dicts in the manifest, it's sometimes redundant to declare a separate key-value mapping for a value used only in one step.
Now:
With literal strings:
To my eye this would be easier to read, because it puts the full definition into the manifest steps without needing to scroll around to find variable definitions, and it means there's only indirection in places it's enforcing shared values.
@hdpriest-ui started an implementation of this in an early draft of #44 and may still have (or be able to quickly reconstruct) the code.