- Infra - oVirt List Archives

[JIRA] (OVIRT-2232) Move SDK projects to STDCI V2
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

Barak Korren created OVIRT-2232: ----------------------------------- Summary: Move SDK projects to STDCI V2 Key: OVIRT-2232 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2232 Project: oVirt - virtualization made easy Issue Type: New Feature Components: CI client projects Reporter: Barak Korren Assignee: infra We have a strong incentive to do this since the SDK V1 jobs have their own messy job templates the require special maintenance... -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1248) Make SDK Standard-CI jobs show "friendly" output when blocked by whitelist
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1248?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1248: -------------------------------- Resolution: Won't Fix Status: Done (was: To Do) This issue is relevant only for the STDCI V1 jobs. SInce we're going to switch the project to STDCI V2, closing with WONTFIX. > Make SDK Standard-CI jobs show "friendly" output when blocked by whitelist > -------------------------------------------------------------------------- > > Key: OVIRT-1248 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1248 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: CI client projects > Reporter: Barak Korren > Assignee: infra > > Most Standard-CI jobs, when blocked by whitelist yield a "NOTRUN" result and a message explaining what happened. > The SDK jobs set CI -1 instead. > It seems that it is because they are missing the Groovy post-build script that sets up the specialized whitelist output. > This is probably because the YAML of the SDK jobs is different from all other jobs (see OVIRT-1247) , so they got overlooked when some if the whitelist changes were introduced. > We need to fix this unless OVIRT-1247 gets fixed sooner. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1248) Make SDK Standard-CI jobs show "friendly" output when blocked by whitelist
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1248?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1248: -------------------------------- Epic Link: (was: OVIRT-400) > Make SDK Standard-CI jobs show "friendly" output when blocked by whitelist > -------------------------------------------------------------------------- > > Key: OVIRT-1248 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1248 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: CI client projects > Reporter: Barak Korren > Assignee: infra > > Most Standard-CI jobs, when blocked by whitelist yield a "NOTRUN" result and a message explaining what happened. > The SDK jobs set CI -1 instead. > It seems that it is because they are missing the Groovy post-build script that sets up the specialized whitelist output. > This is probably because the YAML of the SDK jobs is different from all other jobs (see OVIRT-1247) , so they got overlooked when some if the whitelist changes were introduced. > We need to fix this unless OVIRT-1247 gets fixed sooner. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1248) Make SDK Standard-CI jobs show "friendly" output when blocked by whitelist
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1248?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1248: -------------------------------- Epic Link: (was: OVIRT-400) > Make SDK Standard-CI jobs show "friendly" output when blocked by whitelist > -------------------------------------------------------------------------- > > Key: OVIRT-1248 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1248 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: CI client projects > Reporter: Barak Korren > Assignee: infra > > Most Standard-CI jobs, when blocked by whitelist yield a "NOTRUN" result and a message explaining what happened. > The SDK jobs set CI -1 instead. > It seems that it is because they are missing the Groovy post-build script that sets up the specialized whitelist output. > This is probably because the YAML of the SDK jobs is different from all other jobs (see OVIRT-1247) , so they got overlooked when some if the whitelist changes were introduced. > We need to fix this unless OVIRT-1247 gets fixed sooner. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1248) Make SDK Standard-CI jobs show "friendly" output when blocked by whitelist
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1248?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1248: -------------------------------- Component/s: (was: oVirt CI) CI client projects > Make SDK Standard-CI jobs show "friendly" output when blocked by whitelist > -------------------------------------------------------------------------- > > Key: OVIRT-1248 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1248 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: CI client projects > Reporter: Barak Korren > Assignee: infra > > Most Standard-CI jobs, when blocked by whitelist yield a "NOTRUN" result and a message explaining what happened. > The SDK jobs set CI -1 instead. > It seems that it is because they are missing the Groovy post-build script that sets up the specialized whitelist output. > This is probably because the YAML of the SDK jobs is different from all other jobs (see OVIRT-1247) , so they got overlooked when some if the whitelist changes were introduced. > We need to fix this unless OVIRT-1247 gets fixed sooner. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1252) post-merge build-artifacts jobs can run out of order
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1252?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1252: -------------------------------- Resolution: Won't Fix Status: Done (was: To Do) This issue is not relevant for STDCI V2 as all post-merge actions happen within the same job. So closing Wontfix > post-merge build-artifacts jobs can run out of order > ---------------------------------------------------- > > Key: OVIRT-1252 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1252 > Project: oVirt - virtualization made easy > Issue Type: Bug > Reporter: Barak Korren > Assignee: infra > Labels: standard-ci > > Right now build-artifacts jobs that run post merge get run on every patch and are allowed to run in parallel. > The end result of this is that they do not always finish in the same order in which the patches were merged. This ends up causing the latest build link in Jenkins to not always point to the real latest build. It may also means that packages get pushed to OST not in the right order. > To fix this we need to make sure the build-artifacts jobs do not run in parallel. Alternatively we could split the build artifacts job into a trigger job and a builder job where the trigger job gets run on every patch in parallel and the builder job only runs where resources are available. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-2231) QEMU can't access "/home/jenkins/*" on FC28 slaves.
by Gal Ben Haim (oVirt JIRA) 24 Jun '18

24 Jun '18

Gal Ben Haim created OVIRT-2231: ----------------------------------- Summary: QEMU can't access "/home/jenkins/*" on FC28 slaves. Key: OVIRT-2231 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2231 Project: oVirt - virtualization made easy Issue Type: Bug Components: Lago Reporter: Gal Ben Haim Assignee: infra Priority: Highest Lago creates VM images under "/home/jenkins", QEMU process fails to access those images because of missing permissions. The solution is to set the "execute/search" bit on "/home/jenkins". -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1252) post-merge build-artifacts jobs can run out of order
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1252?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1252: -------------------------------- Epic Link: (was: OVIRT-400) > post-merge build-artifacts jobs can run out of order > ---------------------------------------------------- > > Key: OVIRT-1252 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1252 > Project: oVirt - virtualization made easy > Issue Type: Bug > Reporter: Barak Korren > Assignee: infra > Labels: standard-ci > > Right now build-artifacts jobs that run post merge get run on every patch and are allowed to run in parallel. > The end result of this is that they do not always finish in the same order in which the patches were merged. This ends up causing the latest build link in Jenkins to not always point to the real latest build. It may also means that packages get pushed to OST not in the right order. > To fix this we need to make sure the build-artifacts jobs do not run in parallel. Alternatively we could split the build artifacts job into a trigger job and a builder job where the trigger job gets run on every patch in parallel and the builder job only runs where resources are available. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1252) post-merge build-artifacts jobs can run out of order
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1252?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1252: -------------------------------- Epic Link: (was: OVIRT-400) > post-merge build-artifacts jobs can run out of order > ---------------------------------------------------- > > Key: OVIRT-1252 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1252 > Project: oVirt - virtualization made easy > Issue Type: Bug > Reporter: Barak Korren > Assignee: infra > Labels: standard-ci > > Right now build-artifacts jobs that run post merge get run on every patch and are allowed to run in parallel. > The end result of this is that they do not always finish in the same order in which the patches were merged. This ends up causing the latest build link in Jenkins to not always point to the real latest build. It may also means that packages get pushed to OST not in the right order. > To fix this we need to make sure the build-artifacts jobs do not run in parallel. Alternatively we could split the build artifacts job into a trigger job and a builder job where the trigger job gets run on every patch in parallel and the builder job only runs where resources are available. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1276) generate a link to OST automation job
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1276?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1276: -------------------------------- Resolution: Duplicate Status: Done (was: To Do) > generate a link to OST automation job > ------------------------------------- > > Key: OVIRT-1276 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1276 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: OST Manual job > Reporter: Roy Golan > Assignee: infra > > When activating the 'ci please help' robo verb, please generate a link with > job parameters for the ost job: > Say I told the robot to build my 4.1 patch, than asside from the aftifact > link, create a a link to trigger the ost job with refs/to/spec. pick 4.1 as > a release and so on. In that way a user is a click away from firing a job. > This could be then continued with 'ci please build and ost' kinda of thing > \R -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1276) generate a link to OST automation job
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1276?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1276: -------------------------------- Component/s: OST Manual job > generate a link to OST automation job > ------------------------------------- > > Key: OVIRT-1276 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1276 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: OST Manual job > Reporter: Roy Golan > Assignee: infra > > When activating the 'ci please help' robo verb, please generate a link with > job parameters for the ost job: > Say I told the robot to build my 4.1 patch, than asside from the aftifact > link, create a a link to trigger the ost job with refs/to/spec. pick 4.1 as > a release and so on. In that way a user is a click away from firing a job. > This could be then continued with 'ci please build and ost' kinda of thing > \R -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1276) generate a link to OST automation job
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1276?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1276: -------------------------------- Epic Link: (was: OVIRT-400) > generate a link to OST automation job > ------------------------------------- > > Key: OVIRT-1276 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1276 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Reporter: Roy Golan > Assignee: infra > > When activating the 'ci please help' robo verb, please generate a link with > job parameters for the ost job: > Say I told the robot to build my 4.1 patch, than asside from the aftifact > link, create a a link to trigger the ost job with refs/to/spec. pick 4.1 as > a release and so on. In that way a user is a click away from firing a job. > This could be then continued with 'ci please build and ost' kinda of thing > \R -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1276) generate a link to OST automation job
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1276?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1276: -------------------------------- Epic Link: (was: OVIRT-400) > generate a link to OST automation job > ------------------------------------- > > Key: OVIRT-1276 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1276 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Reporter: Roy Golan > Assignee: infra > > When activating the 'ci please help' robo verb, please generate a link with > job parameters for the ost job: > Say I told the robot to build my 4.1 patch, than asside from the aftifact > link, create a a link to trigger the ost job with refs/to/spec. pick 4.1 as > a release and so on. In that way a user is a click away from firing a job. > This could be then continued with 'ci please build and ost' kinda of thing > \R -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-2221) Reposync builder will not work with DNF
by Gal Ben Haim (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2221?page=com.atlassian.jira.… ] Gal Ben Haim updated OVIRT-2221: -------------------------------- Summary: Reposync builder will not work with DNF (was: Reposync builder will no work with DNF ) > Reposync builder will not work with DNF > ---------------------------------------- > > Key: OVIRT-2221 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2221 > Project: oVirt - virtualization made easy > Issue Type: Task > Components: OST > Reporter: Gal Ben Haim > Assignee: infra > > Part of the reposync builder tool is a Yum plugin which auto-generates the reposync-config with "includepkgs" field. > DNF doesn't support Yum plugins, so we will have to rewrite the plugin for DNF, -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-2207) Collect findbugs results in pipeline jobs
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2207?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-2207: -------------------------------- Epic Link: (was: OVIRT-400) > Collect findbugs results in pipeline jobs > ----------------------------------------- > > Key: OVIRT-2207 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2207 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: Standard CI (Pipelines) > Reporter: Daniel Belenky > Assignee: infra > > As an STDCI user, I want to be able to view "findbugs" results in a convenient way such as the Jenkins "findbugs" plugin provides so that I can analyze the results. > Currently, this feature is supported in STDCI V1 jobs only and we need to have the same support in STDCI V2 jobs. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-2207) Collect findbugs results in pipeline jobs
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2207?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-2207: -------------------------------- Epic Link: (was: OVIRT-400) > Collect findbugs results in pipeline jobs > ----------------------------------------- > > Key: OVIRT-2207 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2207 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: Standard CI (Pipelines) > Reporter: Daniel Belenky > Assignee: infra > > As an STDCI user, I want to be able to view "findbugs" results in a convenient way such as the Jenkins "findbugs" plugin provides so that I can analyze the results. > Currently, this feature is supported in STDCI V1 jobs only and we need to have the same support in STDCI V2 jobs. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1290) Re-factor OST jobs YAML to reduce duplication
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1290?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1290: -------------------------------- Component/s: (was: oVirt CI) OST scheduled jobs OST Manual job > Re-factor OST jobs YAML to reduce duplication > --------------------------------------------- > > Key: OVIRT-1290 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1290 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: OST Manual job, OST scheduled jobs > Reporter: Barak Korren > Assignee: infra > Labels: ost, yaml > > Besides the experimental flow jobs, and the manual OST job, we also have a few more jobs that run specific OST suits on a scheduled basis. > Historically theses suits were written by different people and different job templates in YAML were also written for each suit. > At some point we have normalized all the suit names in OST to be of the following structure: > {code} > <suit_type>-suit-<ovirt version> > {code} > This was initially done to allow the mirror injection process to find the '{{reposync-config.repo}}' file but also facilitated the creation of the generic manual OST job. > Since all suites now follow the same naming convention there is no more reason to have separate YAML job templates per suit. This separation may even cause subtle issues. > All the YAML OST job templates should be unified so that we'll have just one job template that is parametrized by the suite type and oVirt version. Furthermore we can probably have just one YAML project entry to create all scheduled OST jobs. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1290) Re-factor OST jobs YAML to reduce duplication
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1290?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1290: -------------------------------- Epic Link: (was: OVIRT-400) > Re-factor OST jobs YAML to reduce duplication > --------------------------------------------- > > Key: OVIRT-1290 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1290 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: oVirt CI > Reporter: Barak Korren > Assignee: infra > Labels: ost, yaml > > Besides the experimental flow jobs, and the manual OST job, we also have a few more jobs that run specific OST suits on a scheduled basis. > Historically theses suits were written by different people and different job templates in YAML were also written for each suit. > At some point we have normalized all the suit names in OST to be of the following structure: > {code} > <suit_type>-suit-<ovirt version> > {code} > This was initially done to allow the mirror injection process to find the '{{reposync-config.repo}}' file but also facilitated the creation of the generic manual OST job. > Since all suites now follow the same naming convention there is no more reason to have separate YAML job templates per suit. This separation may even cause subtle issues. > All the YAML OST job templates should be unified so that we'll have just one job template that is parametrized by the suite type and oVirt version. Furthermore we can probably have just one YAML project entry to create all scheduled OST jobs. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1290) Re-factor OST jobs YAML to reduce duplication
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1290?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1290: -------------------------------- Epic Link: (was: OVIRT-400) > Re-factor OST jobs YAML to reduce duplication > --------------------------------------------- > > Key: OVIRT-1290 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1290 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: oVirt CI > Reporter: Barak Korren > Assignee: infra > Labels: ost, yaml > > Besides the experimental flow jobs, and the manual OST job, we also have a few more jobs that run specific OST suits on a scheduled basis. > Historically theses suits were written by different people and different job templates in YAML were also written for each suit. > At some point we have normalized all the suit names in OST to be of the following structure: > {code} > <suit_type>-suit-<ovirt version> > {code} > This was initially done to allow the mirror injection process to find the '{{reposync-config.repo}}' file but also facilitated the creation of the generic manual OST job. > Since all suites now follow the same naming convention there is no more reason to have separate YAML job templates per suit. This separation may even cause subtle issues. > All the YAML OST job templates should be unified so that we'll have just one job template that is parametrized by the suite type and oVirt version. Furthermore we can probably have just one YAML project entry to create all scheduled OST jobs. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1311) Nightliy publisher 'move_jenkins_nightly' cron job failes when the *.ready dir is empty
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1311?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1311: -------------------------------- Component/s: Repositories Mgmt > Nightliy publisher 'move_jenkins_nightly' cron job failes when the *.ready dir is empty > --------------------------------------------------------------------------------------- > > Key: OVIRT-1311 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1311 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: Repositories Mgmt > Reporter: Barak Korren > Assignee: infra > > If The '{{*.ready}}' directory does not contain any RPMs, the cron job fails. This failure causes all repos not to get published until the failure is fixed. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1311) Nightliy publisher 'move_jenkins_nightly' cron job failes when the *.ready dir is empty
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1311?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1311: -------------------------------- Epic Link: (was: OVIRT-400) > Nightliy publisher 'move_jenkins_nightly' cron job failes when the *.ready dir is empty > --------------------------------------------------------------------------------------- > > Key: OVIRT-1311 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1311 > Project: oVirt - virtualization made easy > Issue Type: Bug > Reporter: Barak Korren > Assignee: infra > > If The '{{*.ready}}' directory does not contain any RPMs, the cron job fails. This failure causes all repos not to get published until the failure is fixed. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1311) Nightliy publisher 'move_jenkins_nightly' cron job failes when the *.ready dir is empty
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1311?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1311: -------------------------------- Epic Link: (was: OVIRT-400) > Nightliy publisher 'move_jenkins_nightly' cron job failes when the *.ready dir is empty > --------------------------------------------------------------------------------------- > > Key: OVIRT-1311 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1311 > Project: oVirt - virtualization made easy > Issue Type: Bug > Reporter: Barak Korren > Assignee: infra > > If The '{{*.ready}}' directory does not contain any RPMs, the cron job fails. This failure causes all repos not to get published until the failure is fixed. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1312) Make 'scan_for_artifacts.sh' publish repos separately
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1312?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1312: -------------------------------- Epic Link: (was: OVIRT-400) > Make 'scan_for_artifacts.sh' publish repos separately > ----------------------------------------------------- > > Key: OVIRT-1312 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1312 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Repositories Mgmt > Reporter: Barak Korren > Assignee: infra > > The '{{scan_for_artifacts.sh}}' cron job runs on the resources server and syncs packages into the nightly snapshot repos. It tries to serially sync all repos for all oVirt versions. > The issue is that if one of the repos fails to sync, the rest do not get synced either. > We need to make the cron job sync each repo separately so failure mfor one repo will not affect the others. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1312) Make 'scan_for_artifacts.sh' publish repos separately
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1312?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1312: -------------------------------- Epic Link: (was: OVIRT-400) > Make 'scan_for_artifacts.sh' publish repos separately > ----------------------------------------------------- > > Key: OVIRT-1312 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1312 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Repositories Mgmt > Reporter: Barak Korren > Assignee: infra > > The '{{scan_for_artifacts.sh}}' cron job runs on the resources server and syncs packages into the nightly snapshot repos. It tries to serially sync all repos for all oVirt versions. > The issue is that if one of the repos fails to sync, the rest do not get synced either. > We need to make the cron job sync each repo separately so failure mfor one repo will not affect the others. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1330) Make proxied mockrunner conf for fc26 use sepcific mirrors
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1330?page=com.atlassian.jira.… ] 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)

1 0

[JIRA] (OVIRT-1366) ovirt-engine maven caching configuration in CI prevents using mock_runner locally
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1366?page=com.atlassian.jira.… ] 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)

1 0

[JIRA] (OVIRT-1366) ovirt-engine maven caching configuration in CI prevents using mock_runner locally
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1366?page=com.atlassian.jira.… ] 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)

1 0

[JIRA] (OVIRT-1366) ovirt-engine maven caching configuration in CI prevents using mock_runner locally
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1366?page=com.atlassian.jira.… ] 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)

1 0

[JIRA] (OVIRT-1374) Provide a mechanism to obtain an ever increasing build number
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1374?page=com.atlassian.jira.… ] 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)

1 0

[JIRA] (OVIRT-1374) Provide a mechanism to obtain an ever increasing build number
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1374?page=com.atlassian.jira.… ] 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)

1 0

[JIRA] (OVIRT-1374) Provide a mechanism to obtain an ever increasing build number
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1374?page=com.atlassian.jira.… ] 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)

1 0

[JIRA] (OVIRT-1374) Provide a mechanism to obtain an ever increasing build number
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1374?page=com.atlassian.jira.… ] 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)

1 0

[JIRA] (OVIRT-1377) Make change-queue changes look like SCM changes in Jenkins
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1377?page=com.atlassian.jira.… ] 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#Plugin…] as well as [specific documentation|https://wiki.jenkins-ci.org/display/JENKINS/Writing+an+SCM+pl…] about SCM plugins. > [Here|https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/huds…] 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)

1 0

[JIRA] (OVIRT-1377) Make change-queue changes look like SCM changes in Jenkins
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1377?page=com.atlassian.jira.… ] 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#Plugin…] as well as [specific documentation|https://wiki.jenkins-ci.org/display/JENKINS/Writing+an+SCM+pl…] about SCM plugins. > [Here|https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/huds…] 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)

1 0

[JIRA] (OVIRT-1377) Make change-queue changes look like SCM changes in Jenkins
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1377?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1377: -------------------------------- Component/s: (was: oVirt CI) Change Queue > 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#Plugin…] as well as [specific documentation|https://wiki.jenkins-ci.org/display/JENKINS/Writing+an+SCM+pl…] about SCM plugins. > [Here|https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/huds…] 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)

1 0

[JIRA] (OVIRT-1393) Make mirror injection process remove “skip_if_unavailable” settings
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1393?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1393: -------------------------------- Component/s: (was: oVirt CI) CI Mirrors > Make mirror injection process remove “skip_if_unavailable” settings > ------------------------------------------------------------------- > > Key: OVIRT-1393 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1393 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: CI Mirrors > Reporter: Barak Korren > Assignee: infra > Labels: containers, mirrors, mock_runner.sh > > This is a part of [containers CI/CD|https://docs.google.com/a/redhat.com/document/d/1mEo3E0kRvlUWT9VaSPKD…] flow implementation process. > In order to allow having stub repository configuration files as specified in OVIRT-1391, we need to be able to use the "{{skip_if_unavailable}}" yum setting. But we don't want this setting to still be in affect once mirror injection happens and the repo configuration points to a real repo. Therefore we need to make the mirror injection process remove this setting for repo configurations into which mirror URLs are injected. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1393) Make mirror injection process remove “skip_if_unavailable” settings
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1393?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1393: -------------------------------- Epic Link: (was: OVIRT-400) > Make mirror injection process remove “skip_if_unavailable” settings > ------------------------------------------------------------------- > > Key: OVIRT-1393 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1393 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: oVirt CI > Reporter: Barak Korren > Assignee: infra > Labels: containers, mirrors, mock_runner.sh > > This is a part of [containers CI/CD|https://docs.google.com/a/redhat.com/document/d/1mEo3E0kRvlUWT9VaSPKD…] flow implementation process. > In order to allow having stub repository configuration files as specified in OVIRT-1391, we need to be able to use the "{{skip_if_unavailable}}" yum setting. But we don't want this setting to still be in affect once mirror injection happens and the repo configuration points to a real repo. Therefore we need to make the mirror injection process remove this setting for repo configurations into which mirror URLs are injected. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1393) Make mirror injection process remove “skip_if_unavailable” settings
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1393?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1393: -------------------------------- Epic Link: (was: OVIRT-400) > Make mirror injection process remove “skip_if_unavailable” settings > ------------------------------------------------------------------- > > Key: OVIRT-1393 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1393 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: oVirt CI > Reporter: Barak Korren > Assignee: infra > Labels: containers, mirrors, mock_runner.sh > > This is a part of [containers CI/CD|https://docs.google.com/a/redhat.com/document/d/1mEo3E0kRvlUWT9VaSPKD…] flow implementation process. > In order to allow having stub repository configuration files as specified in OVIRT-1391, we need to be able to use the "{{skip_if_unavailable}}" yum setting. But we don't want this setting to still be in affect once mirror injection happens and the repo configuration points to a real repo. Therefore we need to make the mirror injection process remove this setting for repo configurations into which mirror URLs are injected. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1394) Remove STD-CI cleanup function cleanup_var
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1394?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1394: -------------------------------- Component/s: Jenkins Slaves > Remove STD-CI cleanup function cleanup_var > ------------------------------------------ > > Key: OVIRT-1394 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1394 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Jenkins Slaves > Reporter: Gil Shinar > Assignee: infra > > We do not remember why /var/tmp is being cleaned on each STD-CI job. > /var/tmp is good place for caching stuff (maven for example). > I'll remove the /var/tmp cleanup function and will monitor /var/tmp on slaves to make sure it does not use too much disk space. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1394) Remove STD-CI cleanup function cleanup_var
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1394?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1394: -------------------------------- Issue Type: Improvement (was: Task) > Remove STD-CI cleanup function cleanup_var > ------------------------------------------ > > Key: OVIRT-1394 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1394 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Reporter: Gil Shinar > Assignee: infra > > We do not remember why /var/tmp is being cleaned on each STD-CI job. > /var/tmp is good place for caching stuff (maven for example). > I'll remove the /var/tmp cleanup function and will monitor /var/tmp on slaves to make sure it does not use too much disk space. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1394) Remove STD-CI cleanup function cleanup_var
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1394?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1394: -------------------------------- Epic Link: (was: OVIRT-400) > Remove STD-CI cleanup function cleanup_var > ------------------------------------------ > > Key: OVIRT-1394 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1394 > Project: oVirt - virtualization made easy > Issue Type: Task > Reporter: Gil Shinar > Assignee: infra > > We do not remember why /var/tmp is being cleaned on each STD-CI job. > /var/tmp is good place for caching stuff (maven for example). > I'll remove the /var/tmp cleanup function and will monitor /var/tmp on slaves to make sure it does not use too much disk space. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1394) Remove STD-CI cleanup function cleanup_var
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1394?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1394: -------------------------------- Epic Link: (was: OVIRT-400) > Remove STD-CI cleanup function cleanup_var > ------------------------------------------ > > Key: OVIRT-1394 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1394 > Project: oVirt - virtualization made easy > Issue Type: Task > Reporter: Gil Shinar > Assignee: infra > > We do not remember why /var/tmp is being cleaned on each STD-CI job. > /var/tmp is good place for caching stuff (maven for example). > I'll remove the /var/tmp cleanup function and will monitor /var/tmp on slaves to make sure it does not use too much disk space. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1396) Add a new 'test-system-artifacts' Standard-CI stage
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1396?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1396: -------------------------------- Component/s: (was: oVirt CI) Standard CI (Pipelines) > Add a new 'test-system-artifacts' Standard-CI stage > --------------------------------------------------- > > Key: OVIRT-1396 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1396 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: Standard CI (Pipelines) > Reporter: Barak Korren > Assignee: infra > > This is a part of [containers CI/CD|https://docs.google.com/a/redhat.com/document/d/1mEo3E0kRvlUWT9VaSPKD…] flow implementation process. > An order to allow building and testing processes for containers to be triggered after package that are needed for them are built, we will introduce the "{{test-system-artifacts}}" standard-CI stage. > This stage will be invoked from the 'experimental' or 'change-queue-tester' pipelines jost like the existing OST-based flows. > In order to provide package and repo information to the std-CI script invoked by this stage we well need to implement OVIRT-1391 -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1396) Add a new 'test-system-artifacts' Standard-CI stage
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1396?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1396: -------------------------------- Epic Link: (was: OVIRT-400) > Add a new 'test-system-artifacts' Standard-CI stage > --------------------------------------------------- > > Key: OVIRT-1396 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1396 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: oVirt CI > Reporter: Barak Korren > Assignee: infra > > This is a part of [containers CI/CD|https://docs.google.com/a/redhat.com/document/d/1mEo3E0kRvlUWT9VaSPKD…] flow implementation process. > An order to allow building and testing processes for containers to be triggered after package that are needed for them are built, we will introduce the "{{test-system-artifacts}}" standard-CI stage. > This stage will be invoked from the 'experimental' or 'change-queue-tester' pipelines jost like the existing OST-based flows. > In order to provide package and repo information to the std-CI script invoked by this stage we well need to implement OVIRT-1391 -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1396) Add a new 'test-system-artifacts' Standard-CI stage
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1396?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1396: -------------------------------- Epic Link: (was: OVIRT-400) > Add a new 'test-system-artifacts' Standard-CI stage > --------------------------------------------------- > > Key: OVIRT-1396 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1396 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: oVirt CI > Reporter: Barak Korren > Assignee: infra > > This is a part of [containers CI/CD|https://docs.google.com/a/redhat.com/document/d/1mEo3E0kRvlUWT9VaSPKD…] flow implementation process. > An order to allow building and testing processes for containers to be triggered after package that are needed for them are built, we will introduce the "{{test-system-artifacts}}" standard-CI stage. > This stage will be invoked from the 'experimental' or 'change-queue-tester' pipelines jost like the existing OST-based flows. > In order to provide package and repo information to the std-CI script invoked by this stage we well need to implement OVIRT-1391 -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1508) create command line out of upstream_source_collector.py script
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1508?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1508: -------------------------------- Status: Done (was: To Do) upstream source collector code had been re-factored into two tools command-line - usrc.py and pusher.py > create command line out of upstream_source_collector.py script > -------------------------------------------------------------- > > Key: OVIRT-1508 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1508 > Project: oVirt - virtualization made easy > Issue Type: Task > Reporter: Gil Shinar > Assignee: infra > > The benefits we will have by moving it into a a separate script are: > 1) Not embedding the script inside Jenkins - We want to move to pipeline jobs in the future and in that matter we want to embed code in yamls as little as possible. > The way to do it is to move the upstream_source_collector.py to a seperate script that'll be called from a jenkins step. > The only embedded code will be a very short and simple code that'll get the script from upstream before actually calling it. > 2) use the script as command line tool - When developers wants to run it locally on their cloned D/S projects. > 3) Use hash as U/S projects folders - When using as command line tool, avoid looking for a way to match D/S to its U/S corresponding. > Hashing means, hash the URL of the U/S repo and name the folder you are going to clone into with the hash code. > That way, U/S folder name will be by the hash of the rep URL in the upstream_sources.yaml file. > Another benefit will be the fact that we will never use two copies of U/S clone to two different D/S repos that their U/S repo is the same -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1508) create command line out of upstream_source_collector.py script
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1508?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1508: -------------------------------- Epic Link: (was: OVIRT-400) > create command line out of upstream_source_collector.py script > -------------------------------------------------------------- > > Key: OVIRT-1508 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1508 > Project: oVirt - virtualization made easy > Issue Type: Task > Reporter: Gil Shinar > Assignee: infra > > The benefits we will have by moving it into a a separate script are: > 1) Not embedding the script inside Jenkins - We want to move to pipeline jobs in the future and in that matter we want to embed code in yamls as little as possible. > The way to do it is to move the upstream_source_collector.py to a seperate script that'll be called from a jenkins step. > The only embedded code will be a very short and simple code that'll get the script from upstream before actually calling it. > 2) use the script as command line tool - When developers wants to run it locally on their cloned D/S projects. > 3) Use hash as U/S projects folders - When using as command line tool, avoid looking for a way to match D/S to its U/S corresponding. > Hashing means, hash the URL of the U/S repo and name the folder you are going to clone into with the hash code. > That way, U/S folder name will be by the hash of the rep URL in the upstream_sources.yaml file. > Another benefit will be the fact that we will never use two copies of U/S clone to two different D/S repos that their U/S repo is the same -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1508) create command line out of upstream_source_collector.py script
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1508?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1508: -------------------------------- Epic Link: (was: OVIRT-400) > create command line out of upstream_source_collector.py script > -------------------------------------------------------------- > > Key: OVIRT-1508 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1508 > Project: oVirt - virtualization made easy > Issue Type: Task > Reporter: Gil Shinar > Assignee: infra > > The benefits we will have by moving it into a a separate script are: > 1) Not embedding the script inside Jenkins - We want to move to pipeline jobs in the future and in that matter we want to embed code in yamls as little as possible. > The way to do it is to move the upstream_source_collector.py to a seperate script that'll be called from a jenkins step. > The only embedded code will be a very short and simple code that'll get the script from upstream before actually calling it. > 2) use the script as command line tool - When developers wants to run it locally on their cloned D/S projects. > 3) Use hash as U/S projects folders - When using as command line tool, avoid looking for a way to match D/S to its U/S corresponding. > Hashing means, hash the URL of the U/S repo and name the folder you are going to clone into with the hash code. > That way, U/S folder name will be by the hash of the rep URL in the upstream_sources.yaml file. > Another benefit will be the fact that we will never use two copies of U/S clone to two different D/S repos that their U/S repo is the same -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1536) Documentation about the change-queue flow
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1536?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1536: -------------------------------- Component/s: (was: oVirt CI) Documentation Change Queue > Documentation about the change-queue flow > ----------------------------------------- > > Key: OVIRT-1536 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1536 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Change Queue, Documentation > Reporter: Barak Korren > Assignee: infra > Labels: change-queue > > Add some reference documentation about the change-queue flow. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1536) Documentation about the change-queue flow
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1536?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1536: -------------------------------- Epic Link: (was: OVIRT-400) > Documentation about the change-queue flow > ----------------------------------------- > > Key: OVIRT-1536 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1536 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: oVirt CI > Reporter: Barak Korren > Assignee: infra > Labels: change-queue > > Add some reference documentation about the change-queue flow. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0