June 2018 - Infra - Ovirt List Archives

[JIRA] (OVIRT-1330) Make proxied mockrunner conf for fc26 use sepcific mirrors

by Barak Korren (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1330?page=com.atlassian.jir... ] Barak Korren updated OVIRT-1330: -------------------------------- Resolution: Won't Fix Status: Done (was: To Do) wontfix - FC26 is EOLed, this was already fixed for FC27 and FC28. > Make proxied mockrunner conf for fc26 use sepcific mirrors > ---------------------------------------------------------- > > Key: OVIRT-1330 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1330 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: oVirt CI > Reporter: Barak Korren > Assignee: infra > > Since there are no fc26 mirrors yet, the proxied mockrunner configuration for fc26 user the metalink file, as opposed to specific fc mirrors like the rest of the proxied configuration files. > This needs to be fixed once fc26 is released. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

6 years

1
0
0 / 0

[JIRA] (OVIRT-1366) ovirt-engine maven caching configuration in CI prevents using mock_runner locally

by Barak Korren (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1366?page=com.atlassian.jir... ] Barak Korren updated OVIRT-1366: -------------------------------- Component/s: (was: oVirt CI) CI client projects > ovirt-engine maven caching configuration in CI prevents using mock_runner locally > --------------------------------------------------------------------------------- > > Key: OVIRT-1366 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1366 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: CI client projects > Reporter: Barak Korren > Assignee: infra > Labels: ovirt-engine, standard-ci > > The engine STD-CI is configured currently to store the maven cache on the slave in '{{/home/jenkins/maven_cache}}'. This works well in CI but effectively renders that STD-CI scripts unusable for people trying to run '{{mock_runner.sh}}' locally with the engine repo. > We need to move the cache somewhere else that would be writeable on any machine. '{{/var/tmp}}' seems like a good candidate. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

6 years

1
0
0 / 0

[JIRA] (OVIRT-1366) ovirt-engine maven caching configuration in CI prevents using mock_runner locally

by Barak Korren (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1366?page=com.atlassian.jir... ] Barak Korren updated OVIRT-1366: -------------------------------- Epic Link: (was: OVIRT-400) > ovirt-engine maven caching configuration in CI prevents using mock_runner locally > --------------------------------------------------------------------------------- > > Key: OVIRT-1366 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1366 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: oVirt CI > Reporter: Barak Korren > Assignee: infra > Labels: ovirt-engine, standard-ci > > The engine STD-CI is configured currently to store the maven cache on the slave in '{{/home/jenkins/maven_cache}}'. This works well in CI but effectively renders that STD-CI scripts unusable for people trying to run '{{mock_runner.sh}}' locally with the engine repo. > We need to move the cache somewhere else that would be writeable on any machine. '{{/var/tmp}}' seems like a good candidate. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

6 years

1
0
0 / 0

[JIRA] (OVIRT-1366) ovirt-engine maven caching configuration in CI prevents using mock_runner locally

by Barak Korren (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1366?page=com.atlassian.jir... ] Barak Korren updated OVIRT-1366: -------------------------------- Epic Link: (was: OVIRT-400) > ovirt-engine maven caching configuration in CI prevents using mock_runner locally > --------------------------------------------------------------------------------- > > Key: OVIRT-1366 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1366 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: oVirt CI > Reporter: Barak Korren > Assignee: infra > Labels: ovirt-engine, standard-ci > > The engine STD-CI is configured currently to store the maven cache on the slave in '{{/home/jenkins/maven_cache}}'. This works well in CI but effectively renders that STD-CI scripts unusable for people trying to run '{{mock_runner.sh}}' locally with the engine repo. > We need to move the cache somewhere else that would be writeable on any machine. '{{/var/tmp}}' seems like a good candidate. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

6 years

1
0
0 / 0

[JIRA] (OVIRT-1374) Provide a mechanism to obtain an ever increasing build number

by Barak Korren (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1374?page=com.atlassian.jir... ] Barak Korren updated OVIRT-1374: -------------------------------- Resolution: Won't Fix Status: Done (was: To Do) Not going to add this - implementing this would require storing state in the CI system, and would be prone to failure if that state is corrupted or lost. This would also make the build version not reproducible. {{git describe}} provides a better mechanism to achieve what is needed in a stateless and reproducible manner. > Provide a mechanism to obtain an ever increasing build number > ------------------------------------------------------------- > > Key: OVIRT-1374 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1374 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: Standard CI (Pipelines), STDCI DSL > Reporter: Juan Hernández > Assignee: infra > > Currently when a project needs to generate unique names for artifacts, they have to use mechanisms like embedding the date and/or the git hash into the artifact name. For example, when a new build of the Ruby SDK is generated, the name of the RPM is like this: > rubygem-ovirt-engine-sdk4-4.2.0-1.alpha0.20170505gita6de891.el7.centos.ppc64le.rpm > That information is useful, and usually unique. But can be repeated if the same jobs is manually triggered the same day, as the date and the git hash will be the same. > In addition the date may be misleading, because a build performed later but using an old commit, will look newer than an older build that uses a newer commit. > A possible solution is to count the number of commits since certain well known commit. But this isn't reliable if the repository isn't completely cloned, for example if it is cloned with '--depth 1', as that well known commit may not be in the cloned repository. That cloning out of the control of the automation scripts. > So my suggestion/request is to add to the CI/CD environment a mechanism to provide that sequence to the jobs explicitly. I'd suggest to use the count of commits since the initial commit of the repository. The CI/CD environment performs the clone, so it can make sure it has all the relevant commits. > This information could be passed to the build-artifacts.sh script in an environment variable, or in the command line, or in a file in a known location. > With that each project could (optionally) modify its automation scripts to include that number. for example, in the Ruby SDK I'd like to generate RPMs like this: > rubygem-ovirt-engine-sdk4-4.2.0-1.alpha0.<that-number>.rpm -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

6 years

1
0
0 / 0

[JIRA] (OVIRT-1374) Provide a mechanism to obtain an ever increasing build number

by Barak Korren (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1374?page=com.atlassian.jir... ] Barak Korren updated OVIRT-1374: -------------------------------- Component/s: (was: oVirt CI) STDCI DSL Standard CI (Pipelines) > Provide a mechanism to obtain an ever increasing build number > ------------------------------------------------------------- > > Key: OVIRT-1374 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1374 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: Standard CI (Pipelines), STDCI DSL > Reporter: Juan Hernández > Assignee: infra > > Currently when a project needs to generate unique names for artifacts, they have to use mechanisms like embedding the date and/or the git hash into the artifact name. For example, when a new build of the Ruby SDK is generated, the name of the RPM is like this: > rubygem-ovirt-engine-sdk4-4.2.0-1.alpha0.20170505gita6de891.el7.centos.ppc64le.rpm > That information is useful, and usually unique. But can be repeated if the same jobs is manually triggered the same day, as the date and the git hash will be the same. > In addition the date may be misleading, because a build performed later but using an old commit, will look newer than an older build that uses a newer commit. > A possible solution is to count the number of commits since certain well known commit. But this isn't reliable if the repository isn't completely cloned, for example if it is cloned with '--depth 1', as that well known commit may not be in the cloned repository. That cloning out of the control of the automation scripts. > So my suggestion/request is to add to the CI/CD environment a mechanism to provide that sequence to the jobs explicitly. I'd suggest to use the count of commits since the initial commit of the repository. The CI/CD environment performs the clone, so it can make sure it has all the relevant commits. > This information could be passed to the build-artifacts.sh script in an environment variable, or in the command line, or in a file in a known location. > With that each project could (optionally) modify its automation scripts to include that number. for example, in the Ruby SDK I'd like to generate RPMs like this: > rubygem-ovirt-engine-sdk4-4.2.0-1.alpha0.<that-number>.rpm -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

6 years

1
0
0 / 0

[JIRA] (OVIRT-1374) Provide a mechanism to obtain an ever increasing build number

by Barak Korren (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1374?page=com.atlassian.jir... ] Barak Korren updated OVIRT-1374: -------------------------------- Epic Link: (was: OVIRT-400) > Provide a mechanism to obtain an ever increasing build number > ------------------------------------------------------------- > > Key: OVIRT-1374 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1374 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: oVirt CI > Reporter: Juan Hernández > Assignee: infra > > Currently when a project needs to generate unique names for artifacts, they have to use mechanisms like embedding the date and/or the git hash into the artifact name. For example, when a new build of the Ruby SDK is generated, the name of the RPM is like this: > rubygem-ovirt-engine-sdk4-4.2.0-1.alpha0.20170505gita6de891.el7.centos.ppc64le.rpm > That information is useful, and usually unique. But can be repeated if the same jobs is manually triggered the same day, as the date and the git hash will be the same. > In addition the date may be misleading, because a build performed later but using an old commit, will look newer than an older build that uses a newer commit. > A possible solution is to count the number of commits since certain well known commit. But this isn't reliable if the repository isn't completely cloned, for example if it is cloned with '--depth 1', as that well known commit may not be in the cloned repository. That cloning out of the control of the automation scripts. > So my suggestion/request is to add to the CI/CD environment a mechanism to provide that sequence to the jobs explicitly. I'd suggest to use the count of commits since the initial commit of the repository. The CI/CD environment performs the clone, so it can make sure it has all the relevant commits. > This information could be passed to the build-artifacts.sh script in an environment variable, or in the command line, or in a file in a known location. > With that each project could (optionally) modify its automation scripts to include that number. for example, in the Ruby SDK I'd like to generate RPMs like this: > rubygem-ovirt-engine-sdk4-4.2.0-1.alpha0.<that-number>.rpm -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

6 years

1
0
0 / 0

[JIRA] (OVIRT-1374) Provide a mechanism to obtain an ever increasing build number

by Barak Korren (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1374?page=com.atlassian.jir... ] Barak Korren updated OVIRT-1374: -------------------------------- Epic Link: (was: OVIRT-400) > Provide a mechanism to obtain an ever increasing build number > ------------------------------------------------------------- > > Key: OVIRT-1374 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1374 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: oVirt CI > Reporter: Juan Hernández > Assignee: infra > > Currently when a project needs to generate unique names for artifacts, they have to use mechanisms like embedding the date and/or the git hash into the artifact name. For example, when a new build of the Ruby SDK is generated, the name of the RPM is like this: > rubygem-ovirt-engine-sdk4-4.2.0-1.alpha0.20170505gita6de891.el7.centos.ppc64le.rpm > That information is useful, and usually unique. But can be repeated if the same jobs is manually triggered the same day, as the date and the git hash will be the same. > In addition the date may be misleading, because a build performed later but using an old commit, will look newer than an older build that uses a newer commit. > A possible solution is to count the number of commits since certain well known commit. But this isn't reliable if the repository isn't completely cloned, for example if it is cloned with '--depth 1', as that well known commit may not be in the cloned repository. That cloning out of the control of the automation scripts. > So my suggestion/request is to add to the CI/CD environment a mechanism to provide that sequence to the jobs explicitly. I'd suggest to use the count of commits since the initial commit of the repository. The CI/CD environment performs the clone, so it can make sure it has all the relevant commits. > This information could be passed to the build-artifacts.sh script in an environment variable, or in the command line, or in a file in a known location. > With that each project could (optionally) modify its automation scripts to include that number. for example, in the Ruby SDK I'd like to generate RPMs like this: > rubygem-ovirt-engine-sdk4-4.2.0-1.alpha0.<that-number>.rpm -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

6 years

1
0
0 / 0

[JIRA] (OVIRT-1377) Make change-queue changes look like SCM changes in Jenkins

by Barak Korren (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1377?page=com.atlassian.jir... ] Barak Korren updated OVIRT-1377: -------------------------------- Epic Link: (was: OVIRT-400) > Make change-queue changes look like SCM changes in Jenkins > ---------------------------------------------------------- > > Key: OVIRT-1377 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1377 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: Change Queue > Reporter: Barak Korren > Assignee: infra > > Jenkins has special UI for showing changes. Since the change-queue is all about changes, it'll be great if Jenkins will "understand" that change-queue changes are also changes. > It looks like Jenkins does not provide an API the manipulate the list of changes included in a particular build. Instead, change lists come from the SCM plugins, so the way to do this is write a special SCM plugin. > [Here|https://wiki.jenkins-ci.org/display/JENKINS/Extend+Jenkins] is the Jenkins plugin documentation. It includes [a tutorial|https://wiki.jenkins-ci.org/display/JENKINS/Plugin+tutorial#Plug...] as well as [specific documentation|https://wiki.jenkins-ci.org/display/JENKINS/Writing+an+SCM+...] about SCM plugins. > [Here|https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hu...] is the source of the Git SCM plugin, as and example of how to write an SCM plugin. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

6 years

1
0
0 / 0

[JIRA] (OVIRT-1377) Make change-queue changes look like SCM changes in Jenkins

by Barak Korren (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1377?page=com.atlassian.jir... ] Barak Korren updated OVIRT-1377: -------------------------------- Epic Link: (was: OVIRT-400) > Make change-queue changes look like SCM changes in Jenkins > ---------------------------------------------------------- > > Key: OVIRT-1377 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1377 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: Change Queue > Reporter: Barak Korren > Assignee: infra > > Jenkins has special UI for showing changes. Since the change-queue is all about changes, it'll be great if Jenkins will "understand" that change-queue changes are also changes. > It looks like Jenkins does not provide an API the manipulate the list of changes included in a particular build. Instead, change lists come from the SCM plugins, so the way to do this is write a special SCM plugin. > [Here|https://wiki.jenkins-ci.org/display/JENKINS/Extend+Jenkins] is the Jenkins plugin documentation. It includes [a tutorial|https://wiki.jenkins-ci.org/display/JENKINS/Plugin+tutorial#Plug...] as well as [specific documentation|https://wiki.jenkins-ci.org/display/JENKINS/Writing+an+SCM+...] about SCM plugins. > [Here|https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hu...] is the source of the Git SCM plugin, as and example of how to write an SCM plugin. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

6 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Infra June 2018