June 2018 - Infra - oVirt List Archives

[JIRA] (OVIRT-2025) Document STDCI "V1.5" poll upstream sources jobs
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2025?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-2025: -------------------------------- Component/s: Documentation > Document STDCI "V1.5" poll upstream sources jobs > ------------------------------------------------ > > Key: OVIRT-2025 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2025 > Project: oVirt - virtualization made easy > Issue Type: Task > Components: Documentation, Standard CI (Pipelines), STDCI DSL > Reporter: Daniel Belenky > Assignee: infra > > Since we're about to introduce pipeline based poll-upstream-sources jobs, we need to have documentation for the process. Docs should include: > # How to create such job for a given project: implement a JJB temlpate > # How to configure STDCI configuration file so poll-upstream-sources will work. > If anything else is needed to be documented regarding this feature, please add it as a comment. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-2029) Add cache pre-seed functionality to JJB
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2029?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-2029: -------------------------------- Epic Link: (was: OVIRT-400) > Add cache pre-seed functionality to JJB > --------------------------------------- > > Key: OVIRT-2029 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2029 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: JJB > Reporter: Barak Korren > Assignee: infra > Labels: upstream-contribution > > Since we run JJB from STDCI, we cannot have it rely on the existence of a persistent cache from its previous operation. Since JJB is most efficient when it has such a cache, our STDCI script generates such a cache for it from the contents of the previous commit. > To do that we essentially had to implement parts of the JJB internals (The cache handling) on our own. It desirable to have an option in JJB that would do that instead. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-2029) Add cache pre-seed functionality to JJB
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2029?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-2029: -------------------------------- Epic Link: (was: OVIRT-400) > Add cache pre-seed functionality to JJB > --------------------------------------- > > Key: OVIRT-2029 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2029 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: JJB > Reporter: Barak Korren > Assignee: infra > Labels: upstream-contribution > > Since we run JJB from STDCI, we cannot have it rely on the existence of a persistent cache from its previous operation. Since JJB is most efficient when it has such a cache, our STDCI script generates such a cache for it from the contents of the previous commit. > To do that we essentially had to implement parts of the JJB internals (The cache handling) on our own. It desirable to have an option in JJB that would do that instead. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-2030) Add cache-based deletion option to JJB
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2030?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-2030: -------------------------------- Epic Link: (was: OVIRT-400) > Add cache-based deletion option to JJB > -------------------------------------- > > Key: OVIRT-2030 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2030 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: JJB > Reporter: Barak Korren > Assignee: infra > Labels: upstream-contribution > > JJB currently supports two ways to delete jobs: > # The {{delete}} command which deletes specific jobs that are specified on the command line > # The {{--delete-old}] option to the {{update}} command which delete all jobs in Jenkins that are not included in the current update. > Both thes options do not do what we want whic is to delete all jobs not included in the current update that were previously manage by JJB. > To get this functionality we've made our scripts check the difference between to current and previous commits to find out which jobs were deleted. Instead we would like JJB to have the option for the {{update}} command to inspect the job cache from previous run (Or generated as explained in OVIRT-2029), and delete jobs found there that are not included in current update. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-2030) Add cache-based deletion option to JJB
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2030?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-2030: -------------------------------- Epic Link: (was: OVIRT-400) > Add cache-based deletion option to JJB > -------------------------------------- > > Key: OVIRT-2030 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2030 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: JJB > Reporter: Barak Korren > Assignee: infra > Labels: upstream-contribution > > JJB currently supports two ways to delete jobs: > # The {{delete}} command which deletes specific jobs that are specified on the command line > # The {{--delete-old}] option to the {{update}} command which delete all jobs in Jenkins that are not included in the current update. > Both thes options do not do what we want whic is to delete all jobs not included in the current update that were previously manage by JJB. > To get this functionality we've made our scripts check the difference between to current and previous commits to find out which jobs were deleted. Instead we would like JJB to have the option for the {{update}} command to inspect the job cache from previous run (Or generated as explained in OVIRT-2029), and delete jobs found there that are not included in current update. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-2033) Provide a "tagging" mecahnism for transactional mirrors.
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2033?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-2033: -------------------------------- Epic Link: OVIRT-2184 (was: OVIRT-400) > Provide a "tagging" mecahnism for transactional mirrors. > -------------------------------------------------------- > > Key: OVIRT-2033 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2033 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: CI Mirrors > Reporter: Barak Korren > Assignee: infra > > Right now when using the CI mirrors, one can either: > # Use the latest snapshots from all mirrors as mock_runner and all the jobs do. > # Use a specific snapshot by using the direct URL to it as we do on slaves. > It is desirable to be able to mark or tag specific mirror snapshots for various uses. The primary use for this is to track which mirror snapshots have been tested successfully by the change queue in a similar fashion to the way we track passing packages by storing them in the 'tested' repo. The motivation behind doing this is described in OVIRT-1444 -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-2033) Provide a "tagging" mecahnism for transactional mirrors.
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2033?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-2033: -------------------------------- Epic Link: OVIRT-2184 (was: OVIRT-400) > Provide a "tagging" mecahnism for transactional mirrors. > -------------------------------------------------------- > > Key: OVIRT-2033 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2033 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: CI Mirrors > Reporter: Barak Korren > Assignee: infra > > Right now when using the CI mirrors, one can either: > # Use the latest snapshots from all mirrors as mock_runner and all the jobs do. > # Use a specific snapshot by using the direct URL to it as we do on slaves. > It is desirable to be able to mark or tag specific mirror snapshots for various uses. The primary use for this is to track which mirror snapshots have been tested successfully by the change queue in a similar fashion to the way we track passing packages by storing them in the 'tested' repo. The motivation behind doing this is described in OVIRT-1444 -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-2036) Pre-merged patchsets can run on post-merged jobs in STDCI V2
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2036?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-2036: -------------------------------- Epic Link: (was: OVIRT-400) > Pre-merged patchsets can run on post-merged jobs in STDCI V2 > ------------------------------------------------------------ > > Key: OVIRT-2036 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2036 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: Standard CI (Pipelines) > Reporter: Daniel Belenky > Assignee: infra > > Currently, if one comments 'ci re-merge please' on a pre-merged patch, STDCI V2 will run post-merge jobs hence bypassing our whitelist filtering. > We need to fix it by checking if the event matches the actual state of the patch before running any user code. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-2036) Pre-merged patchsets can run on post-merged jobs in STDCI V2
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2036?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-2036: -------------------------------- Epic Link: (was: OVIRT-400) > Pre-merged patchsets can run on post-merged jobs in STDCI V2 > ------------------------------------------------------------ > > Key: OVIRT-2036 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2036 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: Standard CI (Pipelines) > Reporter: Daniel Belenky > Assignee: infra > > Currently, if one comments 'ci re-merge please' on a pre-merged patch, STDCI V2 will run post-merge jobs hence bypassing our whitelist filtering. > We need to fix it by checking if the event matches the actual state of the patch before running any user code. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-2037) Patchsets from non-whitelisted users can't run post-merge tasks
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2037?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-2037: -------------------------------- Epic Link: (was: OVIRT-400) > Patchsets from non-whitelisted users can't run post-merge tasks > --------------------------------------------------------------- > > Key: OVIRT-2037 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2037 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: Standard CI (Freestyle) > Reporter: Daniel Belenky > Assignee: infra > > In some cases, even if a patch was created by a non-whitelisted user, project maintainer can decide to merge > the patch. Currently, STDCI (V1) will block the patch from running any post-merge jobs due to whitelist check. > We need to allow project maintainers to bypass the whitelist check or disable whitelist checking on post-merge jobs. > Note: If we decide to disable whitelist check on post-merge jobs, we need to make sure we run post-merge jobs only on *merged* patchsets. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0