How do I map branches to distros, like, how do I add fc28 only for master?

In other words, how do I replicate something like this v1 config?

    version:
      - master:
          branch: master
      - 4.2:
          branch: master
      - 4.1:
          branch: master
    distro:
      - el7
      - fc27
    exclude:
      - { version: 4.1, distro: fc27 }
    arch: x86_64


Greg


On Sun, Apr 22, 2018 at 3:18 AM, Daniel Belenky <dbelenky@redhat.com> wrote:
Hey,

I just got around to studying this.

- Nice clear email!
- Everything really makes sense.
- Thank you for fixing the -excludes thing in the yaml. That was rough :)
The graph view in Blue Ocean is easy to see and understand.
- "We now support “sub stages” which provide the ability to run multiple different scripts in parallel" -- what kind of races should we watch out for? :) For example in OST, I think I'll have to adapt docker stuff to be aware that another set of containers could be running at the same time -- not positive though.

You shouldn't expect any races due to that change. Sub stages are there to allow triggering of more than one task/job on a single CI event such as check-patch when a patch is created/updated, check-merged/build-artifacts when a patch is merged. Sub stages run in parallel but on different slaves. With sub-stages you can, for example, run different scripts in parallel and on different slaves to do different tasks such as running unit-tests in parallel with docs generation and build verification.

It looks like the substages replace change_resolver in OST. Can you go into that in more detail? How does this impact running run mock_runner locally? When I run it locally it doesn't appear to paralleilize like it does in jenkins / Blue Ocean.

That is true. In STDCI V1 we used to run change_resolver in check-patch to check the commit and resolve the relevant changes. STDCI V2 has this feature integrated in one of it's core components which is called usrc.py. We haven't decided yet how/if we will integrate this tool into OST, or how we will achieve the same behaviour when running OST locally with mock runner. For now, you can keep using the "old" check-patch.sh with mock_runner which will call change_resolver. I'd recommend to send a patch and let Jenkins do the checks for you. It will be faster in many cases where you'll have to run several suites in parallel.

We'll send a proper announcement regarding the new (STDCI V2 based) jobs for OST including instructions of debugging and how this change affects you as an OST developer.

Thanks,
-

DANIEL BELENKY

RHV DEVOPS