7:52 a.m.
Hi,
This message is aimed for project maintainers. Other developers may
also find it interesting to have a glimpse at the oVirt-wide test and
composition processes.
TL;DR: To get accurate CI for oVirt 4.2, most projects
need to add 4.2 jobs in YAML.
Before I can explain what the current issue is and which action is
required, I'm need to provide a brief overview into how oVirt CI
works.
oVirt CI has two major components to it:
1. The STDCI component which is used to build and test individual
projects. Most developers interact with this on a daily basis as it is
responding on GitHub and Gerrit events.
2. The "change-queue" (CQ) component which is used to automatically
compose the whole of oVirt from its sub projects and run system tests
(OST) on it. This component is used to gather the information that is
used by the infra team to compose the "OST failure report" you can
occasionally see being sent to this list. The change queue is also
used to automatically maintain the 'tested' and '*-snapshot' (AKA
nightly) repositories.
The way the CQ composes oVirt is by looking at the post-merge STDCI
'build-artifacts' jobs, and collecting together artifacts built by
jobs that target a specific oVirt version into that version's change
queue. Essentially the '*_master_build-artifacts-*' jobs go into the
'ovirt-master' change queue, the '*_4.1_build-artifacts-*' jobs go
into the 'ovirt-4.1' change queue etc.
Over the course of the oVirt 4.2 development, most project used their
'master' branch, which is typically mapped to '*_master_*' jobs, for
developing 4.2 code. So the 'ovirt-master' CQ provided good indication
of the state of 4.2 code.
As projects started addeing 4.2 branches, we have created an
'ovirt-4.2' CQ to gather them. We did so under the assumption that
most projects will branch soon after. The assumption turned up to be
wrong as most projects did not yet fork and may not do so in the near
future.
As some projects did fork, the end result is that currently:
___there is no accurate representation of oVirt 4.2 in CI___
'ovirt-master' CQ no longer represents oVirt 4.2 as some projects
already have some 4.3 code in their 'master' branches.
'ovirt-4.2' CQ does not represent oVirt 4.2 as most projects do not
push artifacts into it.
To get any benefit from CI, we need to have it represent what we are
going to release. This means that at this point we need all projects
to have '*_4.2_build-artifacts-*' jobs that map to the code that is
intended to be included in oVirt 4.2. Projects can either:
1. Create 4.2 branches and map the new jobs to them.
2. Keep 4.2 development in 'master' and create '4.2' jobs that map to it.
Taking route #2 means a commitment to not adding any 4.3 code to the
'master' branch. Please keep it, as rolling back "too new" builds from
the various repos and caches we have is very difficult.
--
Barak Korren
RHV DevOps team , RHCE, RHCi
Red Hat EMEA
redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted