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 <[email protected]> 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
>
_______________________________________________
Devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
