I do understand the semantics mostly, I am just not sure why we repeat the distro excludes for almost every job and project. Don't we have an oVirt global list for that somewhere (base-params)? Because I am never sure which distros are supported for which versions. Especially now after Sandro said Fedora bits are no longer released. Martin On Wed, Jan 24, 2018 at 9:46 AM, Michal Skrivanek <michal.skrivanek@redhat.com> wrote:
On 24 Jan 2018, at 09:23, Michal Skrivanek <michal.skrivanek@redhat.com> wrote:
On 24 Jan 2018, at 08:52, Dan Kenigsberg <danken@redhat.com> wrote:
On Wed, Jan 24, 2018 at 8:35 AM, Barak Korren <bkorren@redhat.com> wrote:
On 23 January 2018 at 18:44, Martin Sivak <msivak@redhat.com> wrote:
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.
See below.
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?
Yep. technically this should amount to a single change to a single file (See below). The important part is making the right decision for each project, understanding its consequences, and realizing the actions that would be needed for changing that decision in the future.
[1] https://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;f=jobs/confs/projects;h...
There is only one file** you need to maintain that is (currently) not in your own project's repo***. Each project has such a file at [1].
Documentation for the contents of that file can be found here: [2].
There is no need to copy-paste much - the existing file should contain a mapping of project branches to oVirt versions. Typically what would be needed is just to add a single entry to the map. For example, for engine it would be****:
version: - master: branch: master - 4.2: branch: master ...
If project maintainers opt for this "Route 2", it is their personal responsibility to change the above "master" to "ovirt-4.2" branch *BEFORE* they create their stable branch ovirt-4.2. If they fail to do so, CI would get "dirty" with 4.3 packages. Barak hinted to this a bit too mildly.
well, I still do not get the hint at all Why exactly?
apologies for stupid questions, but TBH I do not get most of these things….I tried to take a look at projects I’m familiar with and I still don’t quite understand what is getting to what repo. I guess the syntax is described, that’s fine, but I’m really not sure about semantics. Why do we need each of those things? I see stuff like f24 everywhere…is that just outdated? And what’s the relation to https://github.com/oVirt/releng-tools ?
Thanks, michal
** Bigger projects can spread configuration across multiple files, but this is rarely needed. *** This applies only to Gerrit projects. GitHub projects have everything configured in their own repo. See [3]. **** Specifically for engine, the map appears twice in the file, this should probably be re-factored.
[1]: https://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;f=jobs/confs/projects;h... [2]: http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Using_STDCI_with_Gerrit/... [3]: http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Using_STDCI_with_GitHub/...
-- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel