[ACTION-REQUIRED] Making accurate CI for oVirt 4.2
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
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... Best regards Martin Sivak On Tue, Jan 23, 2018 at 1:52 PM, Barak Korren <bkorren@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
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 ... ** 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
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.
** 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
--Apple-Mail=_0BC00364-3869-4932-9C43-2C39D9DB1B26 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii
On 24 Jan 2018, at 08:52, Dan Kenigsberg <danken@redhat.com> wrote: =20 On Wed, Jan 24, 2018 at 8:35 AM, Barak Korren <bkorren@redhat.com = <mailto:bkorren@redhat.com>> wrote:
On 23 January 2018 at 18:44, Martin Sivak <msivak@redhat.com> wrote:
Hi Barak, =20 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. =20 See below. =20 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? =20 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. =20 [1] = https://gerrit.ovirt.org/gitweb?p=3Djenkins.git;a=3Dtree;f=3Djobs/confs/pr= ojects;h=3D5a59dfea545da98e252eb6c8d95a92d08708a22d;hb=3Dcd75bb9eb33536523= 84ed89777fc15d71d1f9e36 =20 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]. =20 Documentation for the contents of that file can be found here: [2]. =20 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****: =20 version: - master: branch: master - 4.2: branch: master ... =20 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?
=20
=20 ** 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. =20 [1]: = https://gerrit.ovirt.org/gitweb?p=3Djenkins.git;a=3Dtree;f=3Djobs/confs/pr= ojects;hb=3Drefs/heads/master [2]: = http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Using_STDCI_with_Gerri= t/index.html [3]: = http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Using_STDCI_with_GitHu= b/index.html =20 =20 =20 -- 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 =20 =20
Devel mailing list Devel@ovirt.org <mailto:Devel@ovirt.org> http://lists.ovirt.org/mailman/listinfo/devel = <http://lists.ovirt.org/mailman/listinfo/devel>
--Apple-Mail=_0BC00364-3869-4932-9C43-2C39D9DB1B26 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; = charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><br = class=3D""><div><br class=3D""><blockquote type=3D"cite" class=3D""><div = class=3D"">On 24 Jan 2018, at 08:52, Dan Kenigsberg <<a = href=3D"mailto:danken@redhat.com" class=3D"">danken@redhat.com</a>> = wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><span = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: normal; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; = display: inline !important;" class=3D"">On Wed, Jan 24, 2018 at 8:35 AM, = Barak Korren <</span><a href=3D"mailto:bkorren@redhat.com" = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: normal; letter-spacing: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" = class=3D"">bkorren@redhat.com</a><span style=3D"font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant-caps: normal; = font-weight: normal; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: = inline !important;" class=3D"">> wrote:</span><br style=3D"font-family:= Helvetica; font-size: 12px; font-style: normal; font-variant-caps: = normal; font-weight: normal; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><blockquote= type=3D"cite" style=3D"font-family: Helvetica; font-size: 12px; = font-style: normal; font-variant-caps: normal; font-weight: normal; = letter-spacing: normal; orphans: auto; text-align: start; text-indent: = 0px; text-transform: none; white-space: normal; widows: auto; = word-spacing: 0px; -webkit-text-size-adjust: auto; = -webkit-text-stroke-width: 0px;" class=3D"">On 23 January 2018 at 18:44, = Martin Sivak <<a href=3D"mailto:msivak@redhat.com" = class=3D"">msivak@redhat.com</a>> wrote:<br class=3D""><blockquote = type=3D"cite" class=3D"">Hi Barak,<br class=3D""><br class=3D"">can you = please please add links to the proper repositories and/or<br = class=3D"">directories when you send something like this? I really helps = us when<br class=3D"">we do not have to search through all the jenkins = and other infra<br class=3D"">repositories for which is the correct one. = Because I really do not<br class=3D"">remember all the places that need = to change out of my head.<br class=3D""></blockquote><br class=3D"">See = below.<br class=3D""><br class=3D""><blockquote type=3D"cite" = class=3D"">So what you are asking for here is basically that we edit the = files<br class=3D"">here [1] and create a 4.2_build-artifacts job using = copy and paste,<br class=3D"">right? Or is there some other place that = needs to change as well?<br class=3D""></blockquote><br class=3D"">Yep. = technically this should amount to a single change to a single<br = class=3D"">file (See below). The important part is making the right = decision for<br class=3D"">each project, understanding its consequences, = and realizing the<br class=3D"">actions that would be needed for = changing that decision in the future.<br class=3D""><br = class=3D""><blockquote type=3D"cite" class=3D"">[1] <a = href=3D"https://gerrit.ovirt.org/gitweb?p=3Djenkins.git;a=3Dtree;f=3Djobs/= confs/projects;h=3D5a59dfea545da98e252eb6c8d95a92d08708a22d;hb=3Dcd75bb9eb= 3353652384ed89777fc15d71d1f9e36" = class=3D"">https://gerrit.ovirt.org/gitweb?p=3Djenkins.git;a=3Dtree;f=3Djo= bs/confs/projects;h=3D5a59dfea545da98e252eb6c8d95a92d08708a22d;hb=3Dcd75bb= 9eb3353652384ed89777fc15d71d1f9e36</a><br class=3D""></blockquote><br = class=3D"">There is only one file** you need to maintain that is = (currently) not<br class=3D"">in your own project's repo***.<br = class=3D"">Each project has such a file at [1].<br class=3D""><br = class=3D"">Documentation for the contents of that file can be found = here: [2].<br class=3D""><br class=3D"">There is no need to copy-paste = much - the existing file should contain<br class=3D"">a mapping of = project branches to oVirt versions. Typically what would<br class=3D"">be = needed is just to add a single entry to the map. For example, for<br = class=3D"">engine it would be****:<br class=3D""><br = class=3D""> version:<br = class=3D""> - master:<br = class=3D""> &nb= sp;branch: master<br = class=3D""> - 4.2:<br = class=3D""> &nb= sp;branch: master<br = class=3D""> ...= <br class=3D""></blockquote><br style=3D"font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant-caps: normal; = font-weight: normal; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: normal; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; = display: inline !important;" class=3D"">If project maintainers opt for = this "Route 2", it is their personal</span><br style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant-caps: = normal; font-weight: normal; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: normal; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; = display: inline !important;" class=3D"">responsibility to change the = above "master" to "ovirt-4.2" branch</span><br style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant-caps: = normal; font-weight: normal; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: normal; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; = display: inline !important;" class=3D"">*BEFORE* they create their = stable branch ovirt-4.2. If they fail to do</span><br = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: normal; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" = class=3D""><span style=3D"font-family: Helvetica; font-size: 12px; = font-style: normal; font-variant-caps: normal; font-weight: normal; = letter-spacing: normal; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px; float: none; display: inline = !important;" class=3D"">so, CI would get "dirty" with 4.3 packages. = Barak hinted to this a</span><br style=3D"font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant-caps: normal; = font-weight: normal; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: normal; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; = display: inline !important;" class=3D"">bit too mildly.</span><br = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: normal; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" = class=3D""></div></blockquote><div><br class=3D""></div>well, I still do = not get the hint at all</div><div>Why exactly?</div><div><br = class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><br = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: normal; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" = class=3D""><blockquote type=3D"cite" style=3D"font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant-caps: normal; = font-weight: normal; letter-spacing: normal; orphans: auto; text-align: = start; text-indent: 0px; text-transform: none; white-space: normal; = widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; = -webkit-text-stroke-width: 0px;" class=3D""><br class=3D"">** Bigger = projects can spread configuration across multiple files, but<br = class=3D"">this is rarely needed.<br class=3D"">*** This applies only to = Gerrit projects. GitHub projects have<br class=3D"">everything = configured in their own repo. See [3].<br class=3D"">**** Specifically = for engine, the map appears twice in the file, this<br class=3D"">should = probably be re-factored.<br class=3D""><br class=3D"">[1]: <a = href=3D"https://gerrit.ovirt.org/gitweb?p=3Djenkins.git;a=3Dtree;f=3Djobs/= confs/projects;hb=3Drefs/heads/master" = class=3D"">https://gerrit.ovirt.org/gitweb?p=3Djenkins.git;a=3Dtree;f=3Djo= bs/confs/projects;hb=3Drefs/heads/master</a><br class=3D"">[2]: <a = href=3D"http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Using_STDCI_wi= th_Gerrit/index.html" = class=3D"">http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Using_STDCI= _with_Gerrit/index.html</a><br class=3D"">[3]: <a = href=3D"http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Using_STDCI_wi= th_GitHub/index.html" = class=3D"">http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Using_STDCI= _with_GitHub/index.html</a><br class=3D""><br class=3D""><br = class=3D""><br class=3D"">--<br class=3D"">Barak Korren<br class=3D"">RHV = DevOps team , RHCE, RHCi<br class=3D"">Red Hat EMEA<br class=3D""><a = href=3D"http://redhat.com" class=3D"">redhat.com</a> | TRIED. TESTED. = TRUSTED. | <a href=3D"http://redhat.com/trusted" = class=3D"">redhat.com/trusted</a><br = class=3D"">_______________________________________________<br = class=3D"">Devel mailing list<br class=3D""><a = href=3D"mailto:Devel@ovirt.org" class=3D"">Devel@ovirt.org</a><br = class=3D"">http://lists.ovirt.org/mailman/listinfo/devel<br class=3D""><br= class=3D""><br class=3D""></blockquote><span style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant-caps: = normal; font-weight: normal; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: = inline !important;" = class=3D"">_______________________________________________</span><br = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: normal; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" = class=3D""><span style=3D"font-family: Helvetica; font-size: 12px; = font-style: normal; font-variant-caps: normal; font-weight: normal; = letter-spacing: normal; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px; float: none; display: inline = !important;" class=3D"">Devel mailing list</span><br style=3D"font-family:= Helvetica; font-size: 12px; font-style: normal; font-variant-caps: = normal; font-weight: normal; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><a = href=3D"mailto:Devel@ovirt.org" style=3D"font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant-caps: normal; = font-weight: normal; letter-spacing: normal; orphans: auto; text-align: = start; text-indent: 0px; text-transform: none; white-space: normal; = widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; = -webkit-text-stroke-width: 0px;" class=3D"">Devel@ovirt.org</a><br = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: normal; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><a = href=3D"http://lists.ovirt.org/mailman/listinfo/devel" = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: normal; letter-spacing: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" = class=3D"">http://lists.ovirt.org/mailman/listinfo/devel</a></div></blockq= uote></div><br class=3D""></body></html>= --Apple-Mail=_0BC00364-3869-4932-9C43-2C39D9DB1B26--
--Apple-Mail=_FE8AFCC6-240E-4305-A287-D83B0F5DAEBA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8
On 24 Jan 2018, at 09:23, Michal Skrivanek = <michal.skrivanek@redhat.com> wrote: =20 =20 =20
On 24 Jan 2018, at 08:52, Dan Kenigsberg <danken@redhat.com = <mailto:danken@redhat.com>> wrote: =20 On Wed, Jan 24, 2018 at 8:35 AM, Barak Korren <bkorren@redhat.com = <mailto:bkorren@redhat.com>> wrote:
On 23 January 2018 at 18:44, Martin Sivak <msivak@redhat.com = <mailto:msivak@redhat.com>> wrote:
Hi Barak, =20 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. =20 See below. =20 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? =20 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. =20 [1] = https://gerrit.ovirt.org/gitweb?p=3Djenkins.git;a=3Dtree;f=3Djobs/confs/pr= ojects;h=3D5a59dfea545da98e252eb6c8d95a92d08708a22d;hb=3Dcd75bb9eb33536523= 84ed89777fc15d71d1f9e36 = <https://gerrit.ovirt.org/gitweb?p=3Djenkins.git;a=3Dtree;f=3Djobs/confs/p= rojects;h=3D5a59dfea545da98e252eb6c8d95a92d08708a22d;hb=3Dcd75bb9eb3353652= 384ed89777fc15d71d1f9e36> =20 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]. =20 Documentation for the contents of that file can be found here: [2]. =20 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****: =20 version: - master: branch: master - 4.2: branch: master ... =20 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. =20 well, I still do not get the hint at all Why exactly?
=20
=20
=20 ** 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, =
apologies for stupid questions, but TBH I do not get most of these = things=E2=80=A6.I tried to take a look at projects I=E2=80=99m familiar = with and I still don=E2=80=99t quite understand what is getting to what = repo. I guess the syntax is described, that=E2=80=99s fine, but I=E2=80=99m = really not sure about semantics. Why do we need each of those things?=20 I see stuff like f24 everywhere=E2=80=A6is that just outdated? And what=E2=80=99s the relation to https://github.com/oVirt/releng-tools = ? Thanks, michal this
should probably be re-factored. =20 [1]: = https://gerrit.ovirt.org/gitweb?p=3Djenkins.git;a=3Dtree;f=3Djobs/confs/pr= ojects;hb=3Drefs/heads/master = <https://gerrit.ovirt.org/gitweb?p=3Djenkins.git;a=3Dtree;f=3Djobs/confs/p= rojects;hb=3Drefs/heads/master> [2]: = http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Using_STDCI_with_Gerri= t/index.html = <http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Using_STDCI_with_Gerr= it/index.html> [3]: = http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Using_STDCI_with_GitHu= b/index.html = <http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Using_STDCI_with_GitH= ub/index.html> =20 =20 =20 -- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com <http://redhat.com/> | TRIED. TESTED. TRUSTED. | = redhat.com/trusted <http://redhat.com/trusted> _______________________________________________ Devel mailing list Devel@ovirt.org <mailto:Devel@ovirt.org> http://lists.ovirt.org/mailman/listinfo/devel =20 =20
Devel mailing list Devel@ovirt.org <mailto:Devel@ovirt.org> http://lists.ovirt.org/mailman/listinfo/devel = <http://lists.ovirt.org/mailman/listinfo/devel>
--Apple-Mail=_FE8AFCC6-240E-4305-A287-D83B0F5DAEBA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><br = class=3D""><div><br class=3D""><blockquote type=3D"cite" class=3D""><div = class=3D"">On 24 Jan 2018, at 09:23, Michal Skrivanek <<a = href=3D"mailto:michal.skrivanek@redhat.com" = class=3D"">michal.skrivanek@redhat.com</a>> wrote:</div><br = class=3D"Apple-interchange-newline"><div class=3D""><div = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: normal; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><br= class=3D"Apple-interchange-newline"><br class=3D""><blockquote = type=3D"cite" class=3D""><div class=3D"">On 24 Jan 2018, at 08:52, Dan = Kenigsberg <<a href=3D"mailto:danken@redhat.com" = class=3D"">danken@redhat.com</a>> wrote:</div><br = class=3D"Apple-interchange-newline"><div class=3D""><span class=3D"" = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: normal; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; = display: inline !important;">On Wed, Jan 24, 2018 at 8:35 AM, Barak = Korren <</span><a href=3D"mailto:bkorren@redhat.com" class=3D"" = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: normal; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: = 0px;">bkorren@redhat.com</a><span class=3D"" style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant-caps: = normal; font-weight: normal; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: = inline !important;">> wrote:</span><br class=3D"" style=3D"font-family:= Helvetica; font-size: 12px; font-style: normal; font-variant-caps: = normal; font-weight: normal; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote = type=3D"cite" class=3D"" style=3D"font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: = normal; letter-spacing: normal; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px;">On 23 January 2018 at 18:44, Martin = Sivak <<a href=3D"mailto:msivak@redhat.com" = class=3D"">msivak@redhat.com</a>> wrote:<br class=3D""><blockquote = type=3D"cite" class=3D"">Hi Barak,<br class=3D""><br class=3D"">can you = please please add links to the proper repositories and/or<br = class=3D"">directories when you send something like this? I really helps = us when<br class=3D"">we do not have to search through all the jenkins = and other infra<br class=3D"">repositories for which is the correct one. = Because I really do not<br class=3D"">remember all the places that need = to change out of my head.<br class=3D""></blockquote><br class=3D"">See = below.<br class=3D""><br class=3D""><blockquote type=3D"cite" = class=3D"">So what you are asking for here is basically that we edit the = files<br class=3D"">here [1] and create a 4.2_build-artifacts job using = copy and paste,<br class=3D"">right? Or is there some other place that = needs to change as well?<br class=3D""></blockquote><br class=3D"">Yep. = technically this should amount to a single change to a single<br = class=3D"">file (See below). The important part is making the right = decision for<br class=3D"">each project, understanding its consequences, = and realizing the<br class=3D"">actions that would be needed for = changing that decision in the future.<br class=3D""><br = class=3D""><blockquote type=3D"cite" class=3D"">[1]<span = class=3D"Apple-converted-space"> </span><a = href=3D"https://gerrit.ovirt.org/gitweb?p=3Djenkins.git;a=3Dtree;f=3Djobs/= confs/projects;h=3D5a59dfea545da98e252eb6c8d95a92d08708a22d;hb=3Dcd75bb9eb= 3353652384ed89777fc15d71d1f9e36" = class=3D"">https://gerrit.ovirt.org/gitweb?p=3Djenkins.git;a=3Dtree;f=3Djo= bs/confs/projects;h=3D5a59dfea545da98e252eb6c8d95a92d08708a22d;hb=3Dcd75bb= 9eb3353652384ed89777fc15d71d1f9e36</a><br class=3D""></blockquote><br = class=3D"">There is only one file** you need to maintain that is = (currently) not<br class=3D"">in your own project's repo***.<br = class=3D"">Each project has such a file at [1].<br class=3D""><br = class=3D"">Documentation for the contents of that file can be found = here: [2].<br class=3D""><br class=3D"">There is no need to copy-paste = much - the existing file should contain<br class=3D"">a mapping of = project branches to oVirt versions. Typically what would<br class=3D"">be = needed is just to add a single entry to the map. For example, for<br = class=3D"">engine it would be****:<br class=3D""><br = class=3D""> version:<br = class=3D""> - master:<br = class=3D""> &nb= sp;branch: master<br = class=3D""> - 4.2:<br = class=3D""> &nb= sp;branch: master<br = class=3D""> ...= <br class=3D""></blockquote><br class=3D"" style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant-caps: = normal; font-weight: normal; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class=3D"" = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: normal; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; = display: inline !important;">If project maintainers opt for this "Route = 2", it is their personal</span><br class=3D"" style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant-caps: = normal; font-weight: normal; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class=3D"" = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: normal; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; = display: inline !important;">responsibility to change the above "master" = to "ovirt-4.2" branch</span><br class=3D"" style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant-caps: = normal; font-weight: normal; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class=3D"" = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: normal; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; = display: inline !important;">*BEFORE* they create their stable branch = ovirt-4.2. If they fail to do</span><br class=3D"" style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant-caps: = normal; font-weight: normal; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class=3D"" = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: normal; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; = display: inline !important;">so, CI would get "dirty" with 4.3 packages. = Barak hinted to this a</span><br class=3D"" style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant-caps: = normal; font-weight: normal; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class=3D"" = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: normal; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; = display: inline !important;">bit too mildly.</span><br class=3D"" = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: normal; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: = 0px;"></div></blockquote><div class=3D""><br class=3D""></div>well, I = still do not get the hint at all</div><div style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant-caps: = normal; font-weight: normal; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D"">Why = exactly?</div></div></blockquote><div><br class=3D""></div>apologies for = stupid questions, but TBH I do not get most of these things=E2=80=A6.I = tried to take a look at projects I=E2=80=99m familiar with and I still = don=E2=80=99t quite understand what is getting to what repo.</div><div>I = guess the syntax is described, that=E2=80=99s fine, but I=E2=80=99m = really not sure about semantics. Why do we need each of those = things? </div><div>I see stuff like f24 everywhere=E2=80=A6is that = just outdated?</div><div>And what=E2=80=99s the relation to <a = href=3D"https://github.com/oVirt/releng-tools" = class=3D"">https://github.com/oVirt/releng-tools</a> ?</div><div><br = class=3D""></div><div>Thanks,</div><div>michal</div><div><blockquote = type=3D"cite" class=3D""><div class=3D""><div style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant-caps: = normal; font-weight: normal; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><br = class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><br = class=3D"" style=3D"font-family: Helvetica; font-size: 12px; font-style: = normal; font-variant-caps: normal; font-weight: normal; letter-spacing: = normal; text-align: start; text-indent: 0px; text-transform: none; = white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: = 0px;"><blockquote type=3D"cite" class=3D"" style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant-caps: = normal; font-weight: normal; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=3D"">** = Bigger projects can spread configuration across multiple files, but<br = class=3D"">this is rarely needed.<br class=3D"">*** This applies only to = Gerrit projects. GitHub projects have<br class=3D"">everything = configured in their own repo. See [3].<br class=3D"">**** Specifically = for engine, the map appears twice in the file, this<br class=3D"">should = probably be re-factored.<br class=3D""><br class=3D"">[1]:<span = class=3D"Apple-converted-space"> </span><a = href=3D"https://gerrit.ovirt.org/gitweb?p=3Djenkins.git;a=3Dtree;f=3Djobs/= confs/projects;hb=3Drefs/heads/master" = class=3D"">https://gerrit.ovirt.org/gitweb?p=3Djenkins.git;a=3Dtree;f=3Djo= bs/confs/projects;hb=3Drefs/heads/master</a><br class=3D"">[2]:<span = class=3D"Apple-converted-space"> </span><a = href=3D"http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Using_STDCI_wi= th_Gerrit/index.html" = class=3D"">http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Using_STDCI= _with_Gerrit/index.html</a><br class=3D"">[3]:<span = class=3D"Apple-converted-space"> </span><a = href=3D"http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Using_STDCI_wi= th_GitHub/index.html" = class=3D"">http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Using_STDCI= _with_GitHub/index.html</a><br class=3D""><br class=3D""><br = class=3D""><br class=3D"">--<br class=3D"">Barak Korren<br class=3D"">RHV = DevOps team , RHCE, RHCi<br class=3D"">Red Hat EMEA<br class=3D""><a = href=3D"http://redhat.com/" class=3D"">redhat.com</a><span = class=3D"Apple-converted-space"> </span>| TRIED. TESTED. TRUSTED. = |<span class=3D"Apple-converted-space"> </span><a = href=3D"http://redhat.com/trusted" class=3D"">redhat.com/trusted</a><br = class=3D"">_______________________________________________<br = class=3D"">Devel mailing list<br class=3D""><a = href=3D"mailto:Devel@ovirt.org" class=3D"">Devel@ovirt.org</a><br = class=3D""><a href=3D"http://lists.ovirt.org/mailman/listinfo/devel" = class=3D"">http://lists.ovirt.org/mailman/listinfo/devel</a><br = class=3D""><br class=3D""><br class=3D""></blockquote><span class=3D"" = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: normal; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; = display: inline = !important;">_______________________________________________</span><br = class=3D"" style=3D"font-family: Helvetica; font-size: 12px; font-style: = normal; font-variant-caps: normal; font-weight: normal; letter-spacing: = normal; text-align: start; text-indent: 0px; text-transform: none; = white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: = 0px;"><span class=3D"" style=3D"font-family: Helvetica; font-size: 12px; = font-style: normal; font-variant-caps: normal; font-weight: normal; = letter-spacing: normal; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px; float: none; display: inline = !important;">Devel mailing list</span><br class=3D"" style=3D"font-family:= Helvetica; font-size: 12px; font-style: normal; font-variant-caps: = normal; font-weight: normal; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px;"><a = href=3D"mailto:Devel@ovirt.org" class=3D"" style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant-caps: = normal; font-weight: normal; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: = 0px;">Devel@ovirt.org</a><br class=3D"" style=3D"font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant-caps: normal; = font-weight: normal; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px;"><a = href=3D"http://lists.ovirt.org/mailman/listinfo/devel" class=3D"" = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: normal; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: = 0px;">http://lists.ovirt.org/mailman/listinfo/devel</a></div></blockquote>= </div></div></blockquote></div><br class=3D""></body></html>= --Apple-Mail=_FE8AFCC6-240E-4305-A287-D83B0F5DAEBA--
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
On 24 January 2018 at 11:00, Martin Sivak <msivak@redhat.com> wrote:
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)?
Currently not, And current tooling unfortunately does not allow for easily making such a file.
Because I am never sure which distros are supported for which versions. Especially now after Sandro said Fedora bits are no longer released.
You`re asking a bigger question here - Who decides which distros/archs each project targets. The CI system currently places the burden of this decision on the shoulders of individual maintainers. We could have done things differently and placed the decision solely in the hands of the integration team. The reason to placing the power (and responsibility) in the hands of maintainers we simple - we wanted to reduce the chances of having maintainers be surprised. Suppose we made it so that target distros change globally for everyone - you would have had patches failing CI at arbitrary times as new target distros or architectures were added... Decisions like this can be changed, the CI system can be re-architectured, but to do that we would like to see: 1. The integration team agreeing the shoulder the responsibility of choosing target distros and platforms for everyone 2. Maintainers agreeing to fix issues in new distros/archs as soon as the integration team adds them. Personally I prefer that decisions remain distributed, this seems to me to map better to the open source development model, but if the community comes together and decides differently, I will make sure the CI system does what the community wants it to do. -- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
Hi,
You`re asking a bigger question here - Who decides which distros/archs each project targets. The CI system currently places the burden of this decision on the shoulders of individual maintainers. We could have done things differently and placed the decision solely in the hands of the integration team.
Actually, I believe it should be a global decision of the project leadership. But I believe the word global to be important here. We should decide together and then a common version to platform map should be prepared by the integration team. Single projects could still add additional overrides if needed though.
The reason to placing the power (and responsibility) in the hands of maintainers we simple - we wanted to reduce the chances of having maintainers be surprised.
This actually means we get surprised and confused indeed. Please note that nobody really told us that Fedora bits are not going to be released anymore (see 4.2 release notes [1]) and whether we should update the job specifications or not.
Suppose we made it so that target distros change globally for everyone - you would have had patches failing CI at arbitrary times as new target distros or architectures were added...
Right. But we have something very similar now: spreadsheets with lists of packages that are missing from a new version compose. I do not see too much difference actually..
Personally I prefer that decisions remain distributed
I agree with who decides things (all of us). But the decision needs to be documented. Do we have any (easy to find) list of expected platforms for given a release? The decision then might be compiled into a file we could include and stay current without manual edits. [1] https://www.ovirt.org/release/4.2.0/#no-fedora-support Martin
Before commenting on specific things, let me say that I mostly agree with everything you wrote. On 24 January 2018 at 12:11, Martin Sivak <msivak@redhat.com> wrote:
Hi,
You`re asking a bigger question here - Who decides which distros/archs each project targets. The CI system currently places the burden of this decision on the shoulders of individual maintainers. We could have done things differently and placed the decision solely in the hands of the integration team.
Actually, I believe it should be a global decision of the project leadership. But I believe the word global to be important here. We should decide together and then a common version to platform map should be prepared by the integration team.
One thing here - I'm not sure who that leadership might actually be. As Red Hat employees we have managers that can make decisions, but I doubt we could refer to the as "The oVirt leadership". Red Hat managers can make decisions that are relevant to RHV, but not necessarily oVirt. Knowing some of those managers, most of them are not likely to make any cutting decisions. Furthermore, I do not think there is a community-based decision making process in place at this time. It seems that mostly decisions are taken based on what exists, and what could be done with reasonable effort.
Single projects could still add additional overrides if needed though.
The reason to placing the power (and responsibility) in the hands of maintainers we simple - we wanted to reduce the chances of having maintainers be surprised.
This actually means we get surprised and confused indeed. Please note that nobody really told us that Fedora bits are not going to be released anymore (see 4.2 release notes [1]) and whether we should update the job specifications or not.
WRT Fedora - I think the decisions to no longer release for Fedora was made because it stopped working and nobody stepped up to fix it. It was essentially made to ensure that the release documentation matched what existed in the code. WRT job specification - that one is on me, I guess that as the CI system maintainers we should communicate our expectations of maintainers better. The general rule is that we prefer to be concerned with _how_ the CI system does what it does and let maintainers decide the _what_. The is a grey area in the middle though, where we cooperate (For e.g we do some maintenance of OST test suits).
Suppose we made it so that target distros change globally for everyone - you would have had patches failing CI at arbitrary times as new target distros or architectures were added...
Right. But we have something very similar now: spreadsheets with lists of packages that are missing from a new version compose. I do not see too much difference actually..
Personally I prefer that decisions remain distributed
I agree with who decides things (all of us). But the decision needs to be documented. Do we have any (easy to find) list of expected platforms for given a release?
Nope. No central or consensus-based decision making process is in place ATM AFAIK, so no central file either. -- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
2018-01-24 11:11 GMT+01:00 Martin Sivak <msivak@redhat.com>:
Hi,
You`re asking a bigger question here - Who decides which distros/archs each project targets. The CI system currently places the burden of this decision on the shoulders of individual maintainers. We could have done things differently and placed the decision solely in the hands of the integration team.
Actually, I believe it should be a global decision of the project leadership. But I believe the word global to be important here. We should decide together and then a common version to platform map should be prepared by the integration team.
Single projects could still add additional overrides if needed though.
The reason to placing the power (and responsibility) in the hands of maintainers we simple - we wanted to reduce the chances of having maintainers be surprised.
This actually means we get surprised and confused indeed. Please note that nobody really told us that Fedora bits are not going to be released anymore (see 4.2 release notes [1]) and whether we should update the job specifications or not.
Integration team reported to the developers community that Fedora support was broken starting with Fedora 26 back on August 2017[1]. We also reported during the beta process that oVirt 4.2 would have not supported Fedora to user list in November 2017 [2] since nobody fixed Fedora support in the meanwhile. No request or direction about what to do with Jenkins fedora jobs has been issued since we (integration team at least) want Fedora support back in 4.3 but since we don't have yet a schedule for 4.3 we don't know yet which fedora version we'll target. In integration team we are now slowly enabling jobs on master for fc27 and fcraw (rawhide). [1] https://lists.ovirt.org/pipermail/devel/2017-August/030990.html [2] https://lists.ovirt.org/pipermail/users/2017-November/085006.html
Suppose we made it so that target distros change globally for everyone - you would have had patches failing CI at arbitrary times as new target distros or architectures were added...
Right. But we have something very similar now: spreadsheets with lists of packages that are missing from a new version compose. I do not see too much difference actually..
Personally I prefer that decisions remain distributed
I agree with who decides things (all of us). But the decision needs to be documented. Do we have any (easy to find) list of expected platforms for given a release?
The decision then might be compiled into a file we could include and stay current without manual edits.
[1] https://www.ovirt.org/release/4.2.0/#no-fedora-support
Martin _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
On Fri, Jan 26, 2018 at 3:45 PM, Sandro Bonazzola <sbonazzo@redhat.com> wrote:
2018-01-24 11:11 GMT+01:00 Martin Sivak <msivak@redhat.com>:
Hi,
You`re asking a bigger question here - Who decides which distros/archs each project targets. The CI system currently places the burden of this decision on the shoulders of individual maintainers. We could have done things differently and placed the decision solely in the hands of the integration team.
Actually, I believe it should be a global decision of the project leadership. But I believe the word global to be important here. We should decide together and then a common version to platform map should be prepared by the integration team.
Single projects could still add additional overrides if needed though.
The reason to placing the power (and responsibility) in the hands of maintainers we simple - we wanted to reduce the chances of having maintainers be surprised.
This actually means we get surprised and confused indeed. Please note that nobody really told us that Fedora bits are not going to be released anymore (see 4.2 release notes [1]) and whether we should update the job specifications or not.
Integration team reported to the developers community that Fedora support was broken starting with Fedora 26 back on August 2017[1]. We also reported during the beta process that oVirt 4.2 would have not supported Fedora to user list in November 2017 [2] since nobody fixed Fedora support in the meanwhile. No request or direction about what to do with Jenkins fedora jobs has been issued since we (integration team at least) want Fedora support back in 4.3 but since we don't have yet a schedule for 4.3 we don't know yet which fedora version we'll target. In integration team we are now slowly enabling jobs on master for fc27 and fcraw (rawhide).
[1] https://lists.ovirt.org/pipermail/devel/2017-August/030990.html [2] https://lists.ovirt.org/pipermail/users/2017-November/085006.html
I'd like to clarify my own understanding re what should be done with jenkins jobs. 1. You can still, and are very welcome to, have and maintain fedora builds/jobs for your projects. 2. Not officially publishing builds does not mean you can't build them, and if you do, they are still published in the -snapshot repos, so users that do want them, can have them. 3. If building for fedora will make the job(s) for your projects fail constantly, either because you have bugs there, or because you rely on some infrastructure packages (otopi, ovirt-setup-lib, etc) to work on fedora (and with python3), then it probably does not make sense to build yet for fedora - this will simply add noise. 4. If OTOH your project is independent, and works just fine on fedora, you are more than welcome to build (and then publish in -snapshot). Doing this will very likely make the eventual transition to "fedora is supported" much smoother. 5. This is really a per-project decision, so unless we start having cross-project discussions about this, you should decide for yourself. Just keep in mind that eventually we'll have EL8, which is very likely to be more similar to current fedora than to current EL7, so better prepare... (saying this also mainly to myself!). Best regards,
Suppose we made it so that target distros change globally for everyone - you would have had patches failing CI at arbitrary times as new target distros or architectures were added...
Right. But we have something very similar now: spreadsheets with lists of packages that are missing from a new version compose. I do not see too much difference actually..
Personally I prefer that decisions remain distributed
I agree with who decides things (all of us). But the decision needs to be documented. Do we have any (easy to find) list of expected platforms for given a release?
The decision then might be compiled into a file we could include and stay current without manual edits.
[1] https://www.ovirt.org/release/4.2.0/#no-fedora-support
Martin _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
--
SANDRO BONAZZOLA
ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Didi
On 28 January 2018 at 09:32, Yedidyah Bar David <didi@redhat.com> wrote:
On Fri, Jan 26, 2018 at 3:45 PM, Sandro Bonazzola <sbonazzo@redhat.com> wrote:
2018-01-24 11:11 GMT+01:00 Martin Sivak <msivak@redhat.com>:
Hi,
You`re asking a bigger question here - Who decides which distros/archs each project targets. The CI system currently places the burden of this decision on the shoulders of individual maintainers. We could have done things differently and placed the decision solely in the hands of the integration team.
Actually, I believe it should be a global decision of the project leadership. But I believe the word global to be important here. We should decide together and then a common version to platform map should be prepared by the integration team.
Single projects could still add additional overrides if needed though.
The reason to placing the power (and responsibility) in the hands of maintainers we simple - we wanted to reduce the chances of having maintainers be surprised.
This actually means we get surprised and confused indeed. Please note that nobody really told us that Fedora bits are not going to be released anymore (see 4.2 release notes [1]) and whether we should update the job specifications or not.
Integration team reported to the developers community that Fedora support was broken starting with Fedora 26 back on August 2017[1]. We also reported during the beta process that oVirt 4.2 would have not supported Fedora to user list in November 2017 [2] since nobody fixed Fedora support in the meanwhile. No request or direction about what to do with Jenkins fedora jobs has been issued since we (integration team at least) want Fedora support back in 4.3 but since we don't have yet a schedule for 4.3 we don't know yet which fedora version we'll target. In integration team we are now slowly enabling jobs on master for fc27 and fcraw (rawhide).
[1] https://lists.ovirt.org/pipermail/devel/2017-August/030990.html [2] https://lists.ovirt.org/pipermail/users/2017-November/085006.html
I'd like to clarify my own understanding re what should be done with jenkins jobs.
1. You can still, and are very welcome to, have and maintain fedora builds/jobs for your projects.
2. Not officially publishing builds does not mean you can't build them, and if you do, they are still published in the -snapshot repos, so users that do want them, can have them.
3. If building for fedora will make the job(s) for your projects fail constantly, either because you have bugs there, or because you rely on some infrastructure packages (otopi, ovirt-setup-lib, etc) to work on fedora (and with python3), then it probably does not make sense to build yet for fedora - this will simply add noise.
This will cause more then just noise - if a project fails to build on any platform it explicitly targets - builds from all plaforms are blocked and do not get released to the '*-snapshot' repo. If you tell CI you want to support platfrom X, it holds you to it... I'm a little frustrated that this OT discussion derailed the original discussion of getting proper testing for 4.2.
4. If OTOH your project is independent, and works just fine on fedora, you are more than welcome to build (and then publish in -snapshot). Doing this will very likely make the eventual transition to "fedora is supported" much smoother.
5. This is really a per-project decision, so unless we start having cross-project discussions about this, you should decide for yourself. Just keep in mind that eventually we'll have EL8, which is very likely to be more similar to current fedora than to current EL7, so better prepare... (saying this also mainly to myself!).
Best regards,
Suppose we made it so that target distros change globally for everyone - you would have had patches failing CI at arbitrary times as new target distros or architectures were added...
Right. But we have something very similar now: spreadsheets with lists of packages that are missing from a new version compose. I do not see too much difference actually..
Personally I prefer that decisions remain distributed
I agree with who decides things (all of us). But the decision needs to be documented. Do we have any (easy to find) list of expected platforms for given a release?
The decision then might be compiled into a file we could include and stay current without manual edits.
[1] https://www.ovirt.org/release/4.2.0/#no-fedora-support
Martin _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
--
SANDRO BONAZZOLA
ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Didi
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
On 24 January 2018 at 10:46, 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….
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
On 01/24/2018 08:52 AM, Dan Kenigsberg 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.
OK, so let's get ready. I want to take "route 1", so I want to create the branches and map the new jobs to them, so I posted https://gerrit.ovirt.org/#/c/87159/ Rationale: I want the master branch and the ovirt-4.2 branch to be fully independent, like ovirt-4.1 is. Please let me know if I got it right. Bests, -- Francesco Romani Senior SW Eng., Virtualization R&D Red Hat IRC: fromani github: @fromanirh
On 5 February 2018 at 15:13, Francesco Romani <fromani@redhat.com> wrote:
On 01/24/2018 08:52 AM, Dan Kenigsberg 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.
OK, so let's get ready. I want to take "route 1", so I want to create the branches and map the new jobs to them, so I posted https://gerrit.ovirt.org/#/c/87159/
Rationale: I want the master branch and the ovirt-4.2 branch to be fully independent, like ovirt-4.1 is.
Please let me know if I got it right.
Generally looks ok, but see comments on patch. -- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
participants (7)
-
Barak Korren -
Dan Kenigsberg -
Francesco Romani -
Martin Sivak -
Michal Skrivanek -
Sandro Bonazzola -
Yedidyah Bar David