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 <[email protected]> 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 > [email protected] > http://lists.ovirt.org/mailman/listinfo/devel _______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
