[ovirt-devel] [ACTION-REQUIRED] Making accurate CI for oVirt 4.2

[Martin Sivak]

Hi Barak,

can you please please add links to the proper repositories and/or
directories when you send something like this? I really helps us when
we do not have to search through all the jenkins and other infra
repositories for which is the correct one. Because I really do not
remember all the places that need to change out of my head.

So what you are asking for here is basically that we edit the files
here [1] and create a 4.2_build-artifacts job using copy and paste,
right? Or is there some other place that needs to change as well?

[1] https://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;f=jobs/confs/projects;h=5a59dfea545da98e252eb6c8d95a92d08708a22d;hb=cd75bb9eb3353652384ed89777fc15d71d1f9e36


Best regards

Martin Sivak

On Tue, Jan 23, 2018 at 1:52 PM, Barak Korren <bkorren at redhat.com> wrote:
> 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
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel