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:
-- 
2.31.1

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 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.

-- 
Alex Bennée

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>