standard CI packages files

[Barak Korren]

On 12 March 2018 at 10:48, Yedidyah Bar David <didi at redhat.com> wrote:
> On Mon, Mar 12, 2018 at 10:42 AM, Barak Korren <bkorren at redhat.com> wrote:
>> On 12 March 2018 at 09:55, Yedidyah Bar David <didi at redhat.com> wrote:
>>> Hi all,
>>>
>>> The various automation/*.packages* files are rather hard to maintain -
>>> with many partial duplicates, symlinks, and changes applied to some
>>> file forgotten to be applied to others that needed them.
>>>
>>> Can we have something more dynamic? E.g. that CI will run a single
>>> script, e.g. automation/get-needed-packages, provide it as args the
>>> action to be ran ("check-patch", "build-artifacts" etc.) and the
>>> distro ("el7", "fc27" etc.) and use whatever it outputs as the list of
>>> packages to install?
>>>
>>
>> The problem with this approach is that its a slippery slope - because
>> the script to calculate the packages might need packages of its own to
>> run...
>
> I see your point, but not sure it's a real problem.
>
>>
>> In STDCI V2 we laid the groundwork for using a single YAML file to
>> specify everything, this will open up the possibility of using YAML
>> inheritance and macros to share specification parts between different
>> jobs. I think that can be a good enough compromise.
>
> Perhaps. When will we have this?

We can migrate your project to V2 today (We're looking for early
adopters ATM), but current feature set does not include the in-lining
of package, repo, etc. definitions into YAML. We'll need to rewrite
mock_runner.sh for that (Or write <something-else>_runner.sh...) so no
definite deadline for that (This is why I wrote 'laid the groundwork'
as opposed to 'implemented').

The existing V2 feature-set can be useful though - the main thing is
that the definitions of the platforms, archs and oVirt versions you
target moves out of the 'jenkins' repo and into your own. There are
also some other useful things such are the ability to arbitrarily name
the scripts used and the ability to run multiple scripts in parallel.

-- 
Barak Korren
RHV DevOps team , RHCE, RHCi
Red Hat EMEA
redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted