4:13 a.m.
On 24 January 2018 at 10:46, Michal Skrivanek
<michal.skrivanek(a)redhat.com> wrote:
On 24 Jan 2018, at 09:23, Michal Skrivanek <michal.skrivanek(a)redhat.com>
wrote:
On 24 Jan 2018, at 08:52, Dan Kenigsberg <danken(a)redhat.com> wrote:
On Wed, Jan 24, 2018 at 8:35 AM, Barak Korren <bkorren(a)redhat.com> wrote:
On 23 January 2018 at 18:44, Martin Sivak <msivak(a)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/project...
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….
No need to apologise, there is no such thing as a "Stupid question"
only a stupid answer...
I'm sorry if my explanations or the documentation I provide is not
clear, I have the common problem where its hard for me to see that
things that I'm familiar with are not as clear to others.
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?
Those files describes 3 pieces of information for each project:
1. What versions of oVirt a project targets (And which branch goes to
which version)
2. Which distros and architectures a project targets (Can differ by version)
3. Which jobs (stdci stages) the the project requires to be enabled for it.
The format is a bit convoluted for technical reasons that has to do
with the tooling that parses it. Additionally some files were written
at times where things needed to be specified in more complex ways then
they do now, so the files appear more complex then they need to be.
Please point me to a particular file of interest if you want me to use
it as an example and explain what it does.
I see stuff like f24 everywhere…is that just outdated?
Yep...
We needed to support fc24 up until 4.1 was released, so not as
outdated as you think. But I guess most people did not remove the
4.1/fc24 jobs yet.
And what’s the relation to https://github.com/oVirt/releng-tools ?
No relation. releng-tools is used by Sandro's team when they compose
official releases. That process is still manual. We hope to finally be
able to change that soon.
--
Barak Korren
RHV DevOps team , RHCE, RHCi
Red Hat EMEA
redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted