QA » openQA Project

Unfortunately this is not the way merge keys '<<' are working. They are only designed for merging mappings.

But we could handle it in our code. Taking your example:

scenarios:
  ppc64le:
    sle-15-SP2-disabled-Installer-DVD-ppc64le: &tests
    - qa_userspace_apparmor-profiles
    - qa_userspace_bzip2
    - qa_userspace_cpio
  s390x:
    sle-15-SP2-disabled-Installer-DVD-s390x: *tests
  x86_64:
    sle-15-SP2-disabled-Installer-DVD-x86_64:
    - *tests
    - qa_userspace_coreutils
    - qa_userspace_findutils

Then the code which reads the YAML can expand *tests if it is a list.
I guess this would make the JSON Schema a bit more complicated.

Another possibility would be to add our own merge-list tag:

scenarios:
  ppc64le:
    sle-15-SP2-disabled-Installer-DVD-ppc64le: &tests
    - qa_userspace_apparmor-profiles
    - qa_userspace_bzip2
    - qa_userspace_cpio
  s390x:
    sle-15-SP2-disabled-Installer-DVD-s390x: *tests
  x86_64:
    sle-15-SP2-disabled-Installer-DVD-x86_64: !merge-lists
    - *tests
    - - qa_userspace_coreutils
      - qa_userspace_findutils

But that's slighty more unreadable.
Alternatively, using flow sequence style:

scenarios:
  ppc64le:
    sle-15-SP2-disabled-Installer-DVD-ppc64le: &tests
    - qa_userspace_apparmor-profiles
    - qa_userspace_bzip2
    - qa_userspace_cpio
  s390x:
    sle-15-SP2-disabled-Installer-DVD-s390x: *tests
  x86_64:
    sle-15-SP2-disabled-Installer-DVD-x86_64: !merge-lists [
      *tests,
      [qa_userspace_coreutils, qa_userspace_findutils]
     ]

Still, harder to understand.

And adding our custom tag makes us less flexible. This wouldn't be read correctly by a python script using pyyaml, unless we also add this tag to the pyyaml loader.

Yet another alternative:

scenarios:
  ppc64le:
    sle-15-SP2-disabled-Installer-DVD-ppc64le: *tests
  s390x:
    sle-15-SP2-disabled-Installer-DVD-s390x: &tests
    - qa_userspace_apparmor-profiles
    - qa_userspace_bzip2
    - qa_userspace_cpio
  x86_64:
    sle-15-SP2-disabled-Installer-DVD-x86_64:
    - _merge_: *tests
    - qa_userspace_coreutils
    - qa_userspace_findutils

This could then be handled by our code. It would have the advantage to not interfere with the official !!merge tag <<

What I would like to have is what is described on https://blog.daemonl.com/2016/02/yaml.html in the section "Extend <<"

Like discussed in chat, this could work:

product-arch1: &common
  testsuite1:
  testsuite2:
    settings:
      foo: bar
  testsuite3:
product-arch2:
  <<: *common
  suite-x:
  suite-y:
    settings:
      foo: baz
  suite-z:

And this is how it would look like if the scenario defining the anchor has additional testsuites as well:

product-arch1:
  <<: &common
    testsuite1:
    testsuite2:
      settings:
        foo: bar
    testsuite3:
  suite-a:
  suite-b:
product-arch2:
  <<: *common
  suite-x:
  suite-y:
    settings:
      foo: baz
  suite-z:

For reference: I'm voting against non standard yaml extensions 'in our code'. I think any kind of pre-processing/merging/whatnot should be done by a client working on git level.
I accept the user story (and would even agree it's pretty high on the list), but I reject the feature request.

coolo wrote:

For reference: I'm voting against non standard yaml extensions 'in our code'.

I agree.
One question is if we see the merge-keys as a standard. I would say it is, just that so far there was no perl module that could handle it.

But as far as I can see we cannot use mappings here anyway because it's possible to have the same testsuite several times, with different settings.

coolo wrote:

For reference: I'm voting against non standard yaml extensions 'in our code'. I think any kind of pre-processing/merging/whatnot should be done by a client working on git level.
I accept the user story (and would even agree it's pretty high on the list), but I reject the feature request.

I kind of agree. I'd prefer the YAML document always be valid against the schema and readable with other parsers. Otherwise the story of consuming YAML in scripts is going to be a lot weaker.