Deprecating direct RPM downloads from Jenkins
Hi there, TL;DR: Is your build/CI/other process consuming RPMs directly from Jenkins? Could it be changed to consume from other available places? In STDCI V1 we supported obtaining of the latest CI build for a particular project in a particular branch on a particular platform directly from Jenkins, by using the "latestSuccessfulBuild" dynamic link that Jenkins generates. This was possible in STDCI V1 because we had one-to-one correlation between jenkins jobs and project/branch/platform combinations. That is no longer the case in STDCI V2 where each project gets just two fixed jobs that adjust themselves automatically to run needed functionality. We could implement some equivalent functionality in STDCI V2 by for e.g. uploading builds to some predictable locations on an artifact server, but that will take some non-trivial amount of work, so it leads us to the question if this functionality is really needed. There are a couple of alternatives locations to get recently built packages from: - The 'tested' repo which contains all the packages that passed CQ/OST - The 'snapshot' repo which contains a nightly snapshot of 'tested'. So given the options above, if you have a build/CI/other process that currently consumes builds from Jenkins, could it be changed to consume from the other available locations? -- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
On Tue, Jun 19, 2018 at 1:25 AM Barak Korren <bkorren@redhat.com> wrote:
Hi there,
TL;DR: Is your build/CI/other process consuming RPMs directly from Jenkins? Could it be changed to consume from other available places?
In STDCI V1 we supported obtaining of the latest CI build for a particular project in a particular branch on a particular platform directly from Jenkins, by using the "latestSuccessfulBuild" dynamic link that Jenkins generates.
This was possible in STDCI V1 because we had one-to-one correlation between jenkins jobs and project/branch/platform combinations. That is no longer the case in STDCI V2 where each project gets just two fixed jobs that adjust themselves automatically to run needed functionality.
We could implement some equivalent functionality in STDCI V2 by for e.g. uploading builds to some predictable locations on an artifact server, but that will take some non-trivial amount of work, so it leads us to the question if this functionality is really needed.
There are a couple of alternatives locations to get recently built packages from: - The 'tested' repo which contains all the packages that passed CQ/OST - The 'snapshot' repo which contains a nightly snapshot of 'tested'.
So given the options above, if you have a build/CI/other process that currently consumes builds from Jenkins, could it be changed to consume from the other available locations?
Hi Barak, We had some caching and timing issues with ovirt-engine-nodejs-modules. Our node-based projects are using nodejs-modules to collectively store all node modules. When we are developing, say we add some dependencies to nodejs-modules for a new feature. We need to build nodejs-modules and have it available via 'official' repos (accessible to jenkins and mock_runner) immediately so we can iterate / develop. So we use a 'build.packages.force' file [1], add the repo [2], and 'yum|dnf install ovirt-engine-nodejs-modules'. This means we do not have to wait for tested repo, and caches (mock cache, maybe another?) get invalidated. I'm happy to change this process in any way that allows us to 'install' a new nodejs-modules and make it live immediately to all the projects that need it. [1] https://github.com/oVirt/ovirt-engine-dashboard/blob/master/automation/build... [2] ovirt-engine-nodejs-modules_master, http://jenkins.ovirt.org/job/ovirt-engine-nodejs-modules_master_build-artifa... Greg
-- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted _______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/A5LFDPPFWXTEEZ...
-- GREG SHEREMETA SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX Red Hat NA <https://www.redhat.com/> gshereme@redhat.com IRC: gshereme <https://red.ht/sig>
On 19 Jun 2018, at 07:16, Barak Korren <bkorren@redhat.com> wrote:
Hi there,
TL;DR: Is your build/CI/other process consuming RPMs directly from Jenkins? Could it be changed to consume from other available places?
In STDCI V1 we supported obtaining of the latest CI build for a particular project in a particular branch on a particular platform directly from Jenkins, by using the "latestSuccessfulBuild" dynamic link that Jenkins generates.
This was possible in STDCI V1 because we had one-to-one correlation between jenkins jobs and project/branch/platform combinations. That is no longer the case in STDCI V2 where each project gets just two fixed jobs that adjust themselves automatically to run needed functionality.
We could implement some equivalent functionality in STDCI V2 by for e.g. uploading builds to some predictable locations on an artifact server, but that will take some non-trivial amount of work, so it leads us to the question if this functionality is really needed.
does this affect the repo/rpms created as part of a “ci please build” run in any way?
There are a couple of alternatives locations to get recently built packages from: - The 'tested' repo which contains all the packages that passed CQ/OST - The 'snapshot' repo which contains a nightly snapshot of 'tested'.
So given the options above, if you have a build/CI/other process that currently consumes builds from Jenkins, could it be changed to consume from the other available locations?
-- 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 To unsubscribe send an email to devel-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/A5LFDPPFWXTEEZ...
On 19 June 2018 at 17:37, Michal Skrivanek <michal.skrivanek@redhat.com> wrote:
On 19 Jun 2018, at 07:16, Barak Korren <bkorren@redhat.com> wrote:
Hi there,
TL;DR: Is your build/CI/other process consuming RPMs directly from Jenkins? Could it be changed to consume from other available places?
In STDCI V1 we supported obtaining of the latest CI build for a particular project in a particular branch on a particular platform directly from Jenkins, by using the "latestSuccessfulBuild" dynamic link that Jenkins generates.
This was possible in STDCI V1 because we had one-to-one correlation between jenkins jobs and project/branch/platform combinations. That is no longer the case in STDCI V2 where each project gets just two fixed jobs that adjust themselves automatically to run needed functionality.
We could implement some equivalent functionality in STDCI V2 by for e.g. uploading builds to some predictable locations on an artifact server, but that will take some non-trivial amount of work, so it leads us to the question if this functionality is really needed.
does this affect the repo/rpms created as part of a “ci please build” run in any way?
The URL for the RPM will be different but as long as you use the full job/build URL it will work. In short, no. This only affects you if you need some kind of a 'meta' URL to find the build from the lastest _merged_ commit.
There are a couple of alternatives locations to get recently built packages from: - The 'tested' repo which contains all the packages that passed CQ/OST - The 'snapshot' repo which contains a nightly snapshot of 'tested'.
So given the options above, if you have a build/CI/other process that currently consumes builds from Jenkins, could it be changed to consume from the other available locations?
-- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted _______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community- guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/ message/A5LFDPPFWXTEEZLZFSBGZVJNEIP3H7HC/
-- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
On Tue, 19 Jun 2018 at 17:53 Barak Korren <bkorren@redhat.com> wrote:
On 19 June 2018 at 17:37, Michal Skrivanek <michal.skrivanek@redhat.com> wrote:
On 19 Jun 2018, at 07:16, Barak Korren <bkorren@redhat.com> wrote:
Hi there,
TL;DR: Is your build/CI/other process consuming RPMs directly from Jenkins? Could it be changed to consume from other available places?
+Gal Ben Haim <gbenhaim@redhat.com> fyi the lago doc page points to jenkins for latest rpm downloads https://lago.readthedocs.io/en/0.20/README.html
In STDCI V1 we supported obtaining of the latest CI build for a particular project in a particular branch on a particular platform directly from Jenkins, by using the "latestSuccessfulBuild" dynamic link that Jenkins generates.
This was possible in STDCI V1 because we had one-to-one correlation between jenkins jobs and project/branch/platform combinations. That is no longer the case in STDCI V2 where each project gets just two fixed jobs that adjust themselves automatically to run needed functionality.
We could implement some equivalent functionality in STDCI V2 by for e.g. uploading builds to some predictable locations on an artifact server, but that will take some non-trivial amount of work, so it leads us to the question if this functionality is really needed.
does this affect the repo/rpms created as part of a “ci please build” run in any way?
The URL for the RPM will be different but as long as you use the full job/build URL it will work. In short, no.
This only affects you if you need some kind of a 'meta' URL to find the build from the lastest _merged_ commit.
There are a couple of alternatives locations to get recently built packages from: - The 'tested' repo which contains all the packages that passed CQ/OST - The 'snapshot' repo which contains a nightly snapshot of 'tested'.
So given the options above, if you have a build/CI/other process that currently consumes builds from Jenkins, could it be changed to consume from the other available locations?
-- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted _______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/A5LFDPPFWXTEEZ...
-- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted _______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/GX6GRYIVJ2WE4W...
participants (4)
-
Barak Korren -
Greg Sheremeta -
Michal Skrivanek -
Roy Golan