action #66865
openopenQA Tests (public) - coordination #15132: [saga][epic] Better structure of test plans in main.pm
Support !inherit tag in YAML job templates
0%
Description
Motivation¶
Our extensive use of YAML merge keys <<
is hitting limits. Only the top level is merged. In the context of scenarios it can be more desirable to include settings, which are at the second level.
Acceptance criteria¶
- AC1: A "deep merge" of multi-level YAML sections are possible within one YAML document with a special tag
Suggestions¶
tinita wrote:
Just a note: YAML Merge Keys
<<
are not performing a "deep merge". It only merges at the top level.
So in the following example the settings would only contain theANOTHER_SETTING
.- .testsuite: &crypt_no_lvm description: | bla bla bla settings: YAML_SCHEDULE: schedule/yast/encryption/crypt_no_lvm.yaml YAML_TEST_DATA: test_data/yast/encryption/encrypt_no_lvm.yaml - crypt_no_lvm: settings: ANOTHER_SETTING: foo <<: *crypt_no_lvm
Resulting data with resolved merge keys:
- .testsuite: description: | bla bla bla settings: YAML_SCHEDULE: schedule/yast/encryption/crypt_no_lvm.yaml YAML_TEST_DATA: test_data/yast/encryption/encrypt_no_lvm.yaml - crypt_no_lvm: description: | bla bla bla settings: ANOTHER_SETTING: foo
A custom tag which I will call !inherit
could fix that. And although I'm hesistant to diverge from standard YAML, I think we could try and keep it generic and straightforward to implement in e.g. YAML schedules or Python code.
Proposal in #66865#note-1
Updated by tinita over 4 years ago
The idea was to introduce a custom tag which will perform a deepmerge, so it could for example look like this:
def:
- &default-template
settings:
a: A
b: B
desc: lala
# ...
- crypt: !inherit
*default-template :
settings:
a: NEW A
d: D
Result:
- crypt:
desc: lala
settings:
a: NEW A
b: B
d: D
I implemented a proof of concept here: https://gist.github.com/perlpunk/f90f9a4f2ab36565c2f7da19d5bced7d
That's not "standard" YAML, but a concept that several other YAML libraries implement, like PyYAML, ruamel.yaml, Javascript yaml.
Such custom tags are used in Ansible and AWS Cloudformation, for example.
Updated by okurz over 4 years ago
- Category set to Feature requests
- Priority changed from Normal to Low
Updated by okurz about 4 years ago
- Description updated (diff)
- Status changed from New to Workable
- Parent task set to #15132
Updated by pcervinka about 2 years ago
Is there any plan to implement it? It would be nice to have it, it would made pure yaml job group configuration with test suites much easier.
Updated by okurz about 2 years ago
We currently don't have a plan to implement that within the next months. I plan to prioritize #58184 first