[ovirt-devel] Toward self-configuring CI, or how can we stop writing YAML

[Barak Korren]

Hi all,

The premise of the CI standard is simple: You (the developers) place
simple script in the 'automation' directory, and we (the infa team)
take care of making Jenkins run it when it should.

But we haven't been able to fully deliver on this premise yet. Getting
a project to work with the CI standard also takes writing some YAML in
the 'Jenkins' repo. Even worse, this YAML needs to be maintained over
time as new project branches get created, new platforms get targeted,
etc.

The core reason behind having to write YAML, is that there are two
technical details that we need to know in order to run the CI jobs,
but are not specified in a way that allows detecting them
automatically. Those details are:
1. The platforms a certain project needs to be built and tested on.
2. The branches of the project that CI needs to look at, and how do
they map to an oVirt releases.

We need to specify a way to specify the details above in a way that
will allow the CI system to automatically detect them. Here are my
ideas on how to do that:

We already have a way to specify platforms in the 'automation'
directory: scripts and files in the 'automation' directory can be
suffixed with a platform name, this make them apply only to that
platform.

I suggest we make the platform suffix explicitly required (with a
compatibility fall-back, see below), so that to have 'check_patch' run
on Fedora 25 for x86_64, one will have to have a
'check_patch.sh.fc25.x86_64' script (or symlink) in the automation
directory.

It would be cumbersome to go and create symlinks in all the projects
at this stage, therefore, I also suggest that we will make the
architecture default to 'x86_64' when unspecified, and the OS default
to 'el7'. That way, 'check_patch.sh.fc25' will be equivalent to
'check_patch.sh.fc25.x86_64', and 'check_patch.sh' will be equivalent
to 'check_patch.sh.el7.x86_64'.

When it comes to branches, I think the way to go is to standardize
branch names. That standard should probably be something like
'ovirt-4.0', 'ovirt-4.1', etc. Alternatively we could use something
like 'ovirt(-.*)?-.4.0' or (<repo_name>-4.0) to accommodate existing
conventions like the engine`s.

Thoughts? Ideas?

( Jira ticket tracking this work:                    )
( https://ovirt-jira.atlassian.net/browse/OVIRT-1013 )

-- 
Barak Korren
bkorren at redhat.com
RHCE, RHCi, RHV-DevOps Team
https://ifireball.wordpress.com/