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(a)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