qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] gitlab-ci.d/custom-runners: Improve rules for the staging br


From: Thomas Huth
Subject: Re: [PATCH] gitlab-ci.d/custom-runners: Improve rules for the staging branch
Date: Thu, 29 Jul 2021 08:02:48 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0

On 28/07/2021 20.26, Philippe Mathieu-Daudé wrote:
On 7/28/21 7:38 PM, Thomas Huth wrote:
If maintainers are currently pushing to a branch called "staging"
in their repository, they are ending up with some stuck jobs - unless
they have a s390x CI runner machine available. That's ugly, we should
make sure that the related jobs are really only started if such a
runner is available. So let's only run these jobs if it's the
"staging" branch of the main repository of the QEMU project (where
we can be sure that the s390x runner is available), or if the user
explicitly set a S390X_RUNNER_AVAILABLE variable in their CI configs
to declare that they have such a runner available, too.

Fixes: 4799c21023 ("Jobs based on custom runners: add job definitions ...")
Signed-off-by: Thomas Huth <thuth@redhat.com>
---
  .gitlab-ci.d/custom-runners.yml | 40 +++++++++++++++++++++++----------
  1 file changed, 28 insertions(+), 12 deletions(-)

diff --git a/.gitlab-ci.d/custom-runners.yml b/.gitlab-ci.d/custom-runners.yml
index 061d3cdfed..564b94565d 100644
--- a/.gitlab-ci.d/custom-runners.yml
+++ b/.gitlab-ci.d/custom-runners.yml
@@ -24,7 +24,8 @@ ubuntu-18.04-s390x-all-linux-static:
   - ubuntu_18.04
   - s390x
   rules:
- - if: '$CI_COMMIT_BRANCH =~ /^staging/'
+ - if: '$CI_PROJECT_NAMESPACE == "qemu-project" && $CI_COMMIT_BRANCH =~ 
/^staging/'
+ - if: "$S390X_RUNNER_AVAILABLE"

If you base this patch on top of "docs: Document GitLab
custom CI/CD variables" that you already queued, you can
directly add a description for S390X_RUNNER_AVAILABLE in
docs/devel/ci.rst, but this can be done later too.

Good idea! But I really want to get this out of the door to finally get a usable gitlab-CI again, so I'll rather send a patch for this later.

 Thanks,
  Thomas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]