| Message ID | 20211116112757.1909176-1-berrange@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | gitlab: skip cirrus jobs on master and stable branches | expand |
On 11/16/21 12:27 PM, Daniel P. Berrangé wrote: > On the primary QEMU repository we want the CI jobs to run on the staging > branch as a gating CI test. > > Cirrus CI has very limited job concurrency, so if there are too many > jobs triggered they'll queue up and hit the GitLab CI job timeout before > they complete on Cirrus. > > If we let Cirrus jobs run again on the master branch immediately after > merging from staging, that just increases the chances jobs will get > queued and subsequently timeout. > > The same applies for merges to the stable branches. > > User forks meanwhile should be allowed to run Cirrus CI jobs freely. > > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> r~
On Tue, Nov 16, 2021 at 8:28 AM Daniel P. Berrangé <berrange@redhat.com> wrote: > > On the primary QEMU repository we want the CI jobs to run on the staging > branch as a gating CI test. > > Cirrus CI has very limited job concurrency, so if there are too many > jobs triggered they'll queue up and hit the GitLab CI job timeout before > they complete on Cirrus. > > If we let Cirrus jobs run again on the master branch immediately after > merging from staging, that just increases the chances jobs will get > queued and subsequently timeout. > > The same applies for merges to the stable branches. > > User forks meanwhile should be allowed to run Cirrus CI jobs freely. > > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> > --- > .gitlab-ci.d/cirrus.yml | 3 +++ > 1 file changed, 3 insertions(+) > Reviewed-by: Willian Rampazzo <willianr@redhat.com>
On 11/16/21 12:27, Daniel P. Berrangé wrote: > On the primary QEMU repository we want the CI jobs to run on the staging > branch as a gating CI test. > > Cirrus CI has very limited job concurrency, so if there are too many > jobs triggered they'll queue up and hit the GitLab CI job timeout before > they complete on Cirrus. > > If we let Cirrus jobs run again on the master branch immediately after > merging from staging, that just increases the chances jobs will get > queued and subsequently timeout. > > The same applies for merges to the stable branches. > > User forks meanwhile should be allowed to run Cirrus CI jobs freely. > > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> > --- > .gitlab-ci.d/cirrus.yml | 3 +++ > 1 file changed, 3 insertions(+) Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
On 16/11/2021 12.27, Daniel P. Berrangé wrote: > On the primary QEMU repository we want the CI jobs to run on the staging > branch as a gating CI test. > > Cirrus CI has very limited job concurrency, so if there are too many > jobs triggered they'll queue up and hit the GitLab CI job timeout before > they complete on Cirrus. > > If we let Cirrus jobs run again on the master branch immediately after > merging from staging, that just increases the chances jobs will get > queued and subsequently timeout. > > The same applies for merges to the stable branches. > > User forks meanwhile should be allowed to run Cirrus CI jobs freely. > > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> > --- > .gitlab-ci.d/cirrus.yml | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/.gitlab-ci.d/cirrus.yml b/.gitlab-ci.d/cirrus.yml > index e7b25e7427..cc2f2e8906 100644 > --- a/.gitlab-ci.d/cirrus.yml > +++ b/.gitlab-ci.d/cirrus.yml > @@ -40,6 +40,9 @@ > - cat .gitlab-ci.d/cirrus/$NAME.yml > - cirrus-run -v --show-build-log always .gitlab-ci.d/cirrus/$NAME.yml > rules: > + # Allow on 'staging' branch and 'stable-X.Y-staging' branches only > + - if: '$CI_PROJECT_NAMESPACE == "qemu-project" && $CI_COMMIT_BRANCH !~ /staging/' > + when: never > - if: "$CIRRUS_GITHUB_REPO && $CIRRUS_API_TOKEN" > > x64-freebsd-12-build: > Reviewed-by: Thomas Huth <thuth@redhat.com>
Daniel P. Berrangé <berrange@redhat.com> writes: > On the primary QEMU repository we want the CI jobs to run on the staging > branch as a gating CI test. > > Cirrus CI has very limited job concurrency, so if there are too many > jobs triggered they'll queue up and hit the GitLab CI job timeout before > they complete on Cirrus. > > If we let Cirrus jobs run again on the master branch immediately after > merging from staging, that just increases the chances jobs will get > queued and subsequently timeout. > > The same applies for merges to the stable branches. > > User forks meanwhile should be allowed to run Cirrus CI jobs freely. > > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Queued to pr/161121-for-6.2-1, thanks.
diff --git a/.gitlab-ci.d/cirrus.yml b/.gitlab-ci.d/cirrus.yml index e7b25e7427..cc2f2e8906 100644 --- a/.gitlab-ci.d/cirrus.yml +++ b/.gitlab-ci.d/cirrus.yml @@ -40,6 +40,9 @@ - cat .gitlab-ci.d/cirrus/$NAME.yml - cirrus-run -v --show-build-log always .gitlab-ci.d/cirrus/$NAME.yml rules: + # Allow on 'staging' branch and 'stable-X.Y-staging' branches only + - if: '$CI_PROJECT_NAMESPACE == "qemu-project" && $CI_COMMIT_BRANCH !~ /staging/' + when: never - if: "$CIRRUS_GITHUB_REPO && $CIRRUS_API_TOKEN" x64-freebsd-12-build:
On the primary QEMU repository we want the CI jobs to run on the staging branch as a gating CI test. Cirrus CI has very limited job concurrency, so if there are too many jobs triggered they'll queue up and hit the GitLab CI job timeout before they complete on Cirrus. If we let Cirrus jobs run again on the master branch immediately after merging from staging, that just increases the chances jobs will get queued and subsequently timeout. The same applies for merges to the stable branches. User forks meanwhile should be allowed to run Cirrus CI jobs freely. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> --- .gitlab-ci.d/cirrus.yml | 3 +++ 1 file changed, 3 insertions(+)