.gitlab-ci.d/custom-runners.yml | 20 ++++++++------------ 1 file changed, 8 insertions(+), 12 deletions(-)
Currently we define a lot of jobs for our custom runners:
for both aarch64 and s390x we have
- all-linux-static
- all
- alldbg
- clang (manual)
- tci
- notcg (manual)
This is overkill. The main reason to run on these hosts is to get
coverage for the host architecture; we can leave the handling of
differences like debug vs non-debug to the x86 CI jobs.
The jobs are also generally running OK; they occasionally fail due to
timeouts, which is likely because we're overloading the machine by
asking it to run 4 CI jobs at once plus the ad-hoc CI.
Remove the 'allow_failure' tag from all these jobs, and switch the
s390x-alldbg, aarch64-all, s390x-tci and aarch64-tci jobs to manual.
This will let us make the switch for s390x and aarch64 hosts from
the ad-hoc CI to gitlab.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
.gitlab-ci.d/custom-runners.yml | 20 ++++++++------------
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/.gitlab-ci.d/custom-runners.yml b/.gitlab-ci.d/custom-runners.yml
index 0d3e4a7b4b9..bcd22ca293c 100644
--- a/.gitlab-ci.d/custom-runners.yml
+++ b/.gitlab-ci.d/custom-runners.yml
@@ -17,7 +17,6 @@ variables:
# setup by the scripts/ci/setup/build-environment.yml task
# "Install basic packages to build QEMU on Ubuntu 18.04/20.04"
ubuntu-18.04-s390x-all-linux-static:
- allow_failure: true
needs: []
stage: build
tags:
@@ -37,7 +36,6 @@ ubuntu-18.04-s390x-all-linux-static:
- make --output-sync -j`nproc` check-tcg V=1
ubuntu-18.04-s390x-all:
- allow_failure: true
needs: []
stage: build
tags:
@@ -54,7 +52,6 @@ ubuntu-18.04-s390x-all:
- make --output-sync -j`nproc` check V=1
ubuntu-18.04-s390x-alldbg:
- allow_failure: true
needs: []
stage: build
tags:
@@ -62,7 +59,9 @@ ubuntu-18.04-s390x-alldbg:
- s390x
rules:
- if: '$CI_PROJECT_NAMESPACE == "qemu-project" && $CI_COMMIT_BRANCH =~ /^staging/'
+ when: manual
- if: "$S390X_RUNNER_AVAILABLE"
+ when: manual
script:
- mkdir build
- cd build
@@ -72,7 +71,6 @@ ubuntu-18.04-s390x-alldbg:
- make --output-sync -j`nproc` check V=1
ubuntu-18.04-s390x-clang:
- allow_failure: true
needs: []
stage: build
tags:
@@ -91,7 +89,6 @@ ubuntu-18.04-s390x-clang:
- make --output-sync -j`nproc` check V=1
ubuntu-18.04-s390x-tci:
- allow_failure: true
needs: []
stage: build
tags:
@@ -99,7 +96,9 @@ ubuntu-18.04-s390x-tci:
- s390x
rules:
- if: '$CI_PROJECT_NAMESPACE == "qemu-project" && $CI_COMMIT_BRANCH =~ /^staging/'
+ when: manual
- if: "$S390X_RUNNER_AVAILABLE"
+ when: manual
script:
- mkdir build
- cd build
@@ -107,7 +106,6 @@ ubuntu-18.04-s390x-tci:
- make --output-sync -j`nproc`
ubuntu-18.04-s390x-notcg:
- allow_failure: true
needs: []
stage: build
tags:
@@ -129,7 +127,6 @@ ubuntu-18.04-s390x-notcg:
# setup by the scripts/ci/setup/qemu/build-environment.yml task
# "Install basic packages to build QEMU on Ubuntu 18.04/20.04"
ubuntu-20.04-aarch64-all-linux-static:
- allow_failure: true
needs: []
stage: build
tags:
@@ -149,7 +146,6 @@ ubuntu-20.04-aarch64-all-linux-static:
- make --output-sync -j`nproc` check-tcg V=1
ubuntu-20.04-aarch64-all:
- allow_failure: true
needs: []
stage: build
tags:
@@ -157,7 +153,9 @@ ubuntu-20.04-aarch64-all:
- aarch64
rules:
- if: '$CI_PROJECT_NAMESPACE == "qemu-project" && $CI_COMMIT_BRANCH =~ /^staging/'
+ when: manual
- if: "$AARCH64_RUNNER_AVAILABLE"
+ when: manual
script:
- mkdir build
- cd build
@@ -166,7 +164,6 @@ ubuntu-20.04-aarch64-all:
- make --output-sync -j`nproc` check V=1
ubuntu-20.04-aarch64-alldbg:
- allow_failure: true
needs: []
stage: build
tags:
@@ -184,7 +181,6 @@ ubuntu-20.04-aarch64-alldbg:
- make --output-sync -j`nproc` check V=1
ubuntu-20.04-aarch64-clang:
- allow_failure: true
needs: []
stage: build
tags:
@@ -203,7 +199,6 @@ ubuntu-20.04-aarch64-clang:
- make --output-sync -j`nproc` check V=1
ubuntu-20.04-aarch64-tci:
- allow_failure: true
needs: []
stage: build
tags:
@@ -211,7 +206,9 @@ ubuntu-20.04-aarch64-tci:
- aarch64
rules:
- if: '$CI_PROJECT_NAMESPACE == "qemu-project" && $CI_COMMIT_BRANCH =~ /^staging/'
+ when: manual
- if: "$AARCH64_RUNNER_AVAILABLE"
+ when: manual
script:
- mkdir build
- cd build
@@ -219,7 +216,6 @@ ubuntu-20.04-aarch64-tci:
- make --output-sync -j`nproc`
ubuntu-20.04-aarch64-notcg:
- allow_failure: true
needs: []
stage: build
tags:
--
2.20.1
On Mon, Sep 13, 2021 at 11:19:48AM +0100, Peter Maydell wrote: > Currently we define a lot of jobs for our custom runners: > for both aarch64 and s390x we have > - all-linux-static > - all > - alldbg > - clang (manual) > - tci > - notcg (manual) > > This is overkill. The main reason to run on these hosts is to get > coverage for the host architecture; we can leave the handling of > differences like debug vs non-debug to the x86 CI jobs. > > The jobs are also generally running OK; they occasionally fail due to > timeouts, which is likely because we're overloading the machine by > asking it to run 4 CI jobs at once plus the ad-hoc CI. > > Remove the 'allow_failure' tag from all these jobs, and switch the > s390x-alldbg, aarch64-all, s390x-tci and aarch64-tci jobs to manual. Why the difference in skipping 'alldbg' vs 'all' ? Was that just to get diverse coverage of debug vs non-debug ? > This will let us make the switch for s390x and aarch64 hosts from > the ad-hoc CI to gitlab. > > Signed-off-by: Peter Maydell <peter.maydell@linaro.org> > --- > .gitlab-ci.d/custom-runners.yml | 20 ++++++++------------ > 1 file changed, 8 insertions(+), 12 deletions(-) Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Mon, 13 Sept 2021 at 11:32, Daniel P. Berrangé <berrange@redhat.com> wrote: > > On Mon, Sep 13, 2021 at 11:19:48AM +0100, Peter Maydell wrote: > > Currently we define a lot of jobs for our custom runners: > > for both aarch64 and s390x we have > > - all-linux-static > > - all > > - alldbg > > - clang (manual) > > - tci > > - notcg (manual) > > > > This is overkill. The main reason to run on these hosts is to get > > coverage for the host architecture; we can leave the handling of > > differences like debug vs non-debug to the x86 CI jobs. > > > > The jobs are also generally running OK; they occasionally fail due to > > timeouts, which is likely because we're overloading the machine by > > asking it to run 4 CI jobs at once plus the ad-hoc CI. > > > > Remove the 'allow_failure' tag from all these jobs, and switch the > > s390x-alldbg, aarch64-all, s390x-tci and aarch64-tci jobs to manual. > > Why the difference in skipping 'alldbg' vs 'all' ? Was that just > to get diverse coverage of debug vs non-debug ? Yeah, I figured we might as well run one on each. thanks -- PMM
On Mon, Sep 13, 2021 at 7:22 AM Peter Maydell <peter.maydell@linaro.org> wrote: > > Currently we define a lot of jobs for our custom runners: > for both aarch64 and s390x we have > - all-linux-static > - all > - alldbg > - clang (manual) > - tci > - notcg (manual) > > This is overkill. The main reason to run on these hosts is to get > coverage for the host architecture; we can leave the handling of > differences like debug vs non-debug to the x86 CI jobs. > > The jobs are also generally running OK; they occasionally fail due to > timeouts, which is likely because we're overloading the machine by > asking it to run 4 CI jobs at once plus the ad-hoc CI. > > Remove the 'allow_failure' tag from all these jobs, and switch the > s390x-alldbg, aarch64-all, s390x-tci and aarch64-tci jobs to manual. > This will let us make the switch for s390x and aarch64 hosts from > the ad-hoc CI to gitlab. > > Signed-off-by: Peter Maydell <peter.maydell@linaro.org> > --- > .gitlab-ci.d/custom-runners.yml | 20 ++++++++------------ > 1 file changed, 8 insertions(+), 12 deletions(-) > Reviewed-by: Willian Rampazzo <willianr@redhat.com>
On 13/09/2021 12.19, Peter Maydell wrote: > Currently we define a lot of jobs for our custom runners: > for both aarch64 and s390x we have > - all-linux-static > - all > - alldbg > - clang (manual) > - tci > - notcg (manual) > > This is overkill. The main reason to run on these hosts is to get > coverage for the host architecture; we can leave the handling of > differences like debug vs non-debug to the x86 CI jobs. > > The jobs are also generally running OK; they occasionally fail due to > timeouts, which is likely because we're overloading the machine by > asking it to run 4 CI jobs at once plus the ad-hoc CI. > > Remove the 'allow_failure' tag from all these jobs, and switch the > s390x-alldbg, aarch64-all, s390x-tci and aarch64-tci jobs to manual. > This will let us make the switch for s390x and aarch64 hosts from > the ad-hoc CI to gitlab. > > Signed-off-by: Peter Maydell <peter.maydell@linaro.org> > --- > .gitlab-ci.d/custom-runners.yml | 20 ++++++++------------ > 1 file changed, 8 insertions(+), 12 deletions(-) Acked-by: Thomas Huth <thuth@redhat.com>
On Mon, 13 Sept 2021 at 11:19, Peter Maydell <peter.maydell@linaro.org> wrote: > > Currently we define a lot of jobs for our custom runners: > for both aarch64 and s390x we have > - all-linux-static > - all > - alldbg > - clang (manual) > - tci > - notcg (manual) > > This is overkill. The main reason to run on these hosts is to get > coverage for the host architecture; we can leave the handling of > differences like debug vs non-debug to the x86 CI jobs. > > The jobs are also generally running OK; they occasionally fail due to > timeouts, which is likely because we're overloading the machine by > asking it to run 4 CI jobs at once plus the ad-hoc CI. > > Remove the 'allow_failure' tag from all these jobs, and switch the > s390x-alldbg, aarch64-all, s390x-tci and aarch64-tci jobs to manual. > This will let us make the switch for s390x and aarch64 hosts from > the ad-hoc CI to gitlab. > > Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Pushed to master so I can turn off my ad-hoc CI for this. thanks -- PMM
On Mon, 13 Sept 2021 at 11:19, Peter Maydell <peter.maydell@linaro.org> wrote: > > Currently we define a lot of jobs for our custom runners: > for both aarch64 and s390x we have > - all-linux-static > - all > - alldbg > - clang (manual) > - tci > - notcg (manual) > > This is overkill. The main reason to run on these hosts is to get > coverage for the host architecture; we can leave the handling of > differences like debug vs non-debug to the x86 CI jobs. > > The jobs are also generally running OK; they occasionally fail due to > timeouts, which is likely because we're overloading the machine by > asking it to run 4 CI jobs at once plus the ad-hoc CI. > > Remove the 'allow_failure' tag from all these jobs, and switch the > s390x-alldbg, aarch64-all, s390x-tci and aarch64-tci jobs to manual. > This will let us make the switch for s390x and aarch64 hosts from > the ad-hoc CI to gitlab. > > Signed-off-by: Peter Maydell <peter.maydell@linaro.org> It looks like this change has resulted in pipelines ending up in a "blocked" state: https://gitlab.com/qemu-project/qemu/-/pipelines I'm not sure why this is -- is it perhaps because there were other jobs that depended on the now-manual-only jobs ? Can somebody suggest a fix ? thanks -- PMM
On Tue, Sep 14, 2021 at 4:18 PM Peter Maydell <peter.maydell@linaro.org> wrote: > > On Mon, 13 Sept 2021 at 11:19, Peter Maydell <peter.maydell@linaro.org> wrote: > > > > Currently we define a lot of jobs for our custom runners: > > for both aarch64 and s390x we have > > - all-linux-static > > - all > > - alldbg > > - clang (manual) > > - tci > > - notcg (manual) > > > > This is overkill. The main reason to run on these hosts is to get > > coverage for the host architecture; we can leave the handling of > > differences like debug vs non-debug to the x86 CI jobs. > > > > The jobs are also generally running OK; they occasionally fail due to > > timeouts, which is likely because we're overloading the machine by > > asking it to run 4 CI jobs at once plus the ad-hoc CI. > > > > Remove the 'allow_failure' tag from all these jobs, and switch the > > s390x-alldbg, aarch64-all, s390x-tci and aarch64-tci jobs to manual. > > This will let us make the switch for s390x and aarch64 hosts from > > the ad-hoc CI to gitlab. > > > > Signed-off-by: Peter Maydell <peter.maydell@linaro.org> > > It looks like this change has resulted in pipelines ending > up in a "blocked" state: > > https://gitlab.com/qemu-project/qemu/-/pipelines > > I'm not sure why this is -- is it perhaps because there were > other jobs that depended on the now-manual-only jobs ? > Can somebody suggest a fix ? There are a couple of issues listed on GitLab main repository reporting the same behavior. When you remove the allow_failure: true, it is set to the default, false. As other stages may depend on that job and it is now set to not allow failure, the pipeline is marked as blocked. Some people reported setting the jobs to allow_failure: true "solved" the problem. References: https://gitlab.com/gitlab-org/gitlab/-/issues/39534 https://gitlab.com/gitlab-org/gitlab/-/issues/31415 https://gitlab.com/gitlab-org/gitlab-foss/-/issues/66602 > > thanks > -- PMM >
On Tue, Sep 14, 2021 at 08:17:19PM +0100, Peter Maydell wrote: > On Mon, 13 Sept 2021 at 11:19, Peter Maydell <peter.maydell@linaro.org> wrote: > > > > Currently we define a lot of jobs for our custom runners: > > for both aarch64 and s390x we have > > - all-linux-static > > - all > > - alldbg > > - clang (manual) > > - tci > > - notcg (manual) > > > > This is overkill. The main reason to run on these hosts is to get > > coverage for the host architecture; we can leave the handling of > > differences like debug vs non-debug to the x86 CI jobs. > > > > The jobs are also generally running OK; they occasionally fail due to > > timeouts, which is likely because we're overloading the machine by > > asking it to run 4 CI jobs at once plus the ad-hoc CI. > > > > Remove the 'allow_failure' tag from all these jobs, and switch the > > s390x-alldbg, aarch64-all, s390x-tci and aarch64-tci jobs to manual. > > This will let us make the switch for s390x and aarch64 hosts from > > the ad-hoc CI to gitlab. > > > > Signed-off-by: Peter Maydell <peter.maydell@linaro.org> > > It looks like this change has resulted in pipelines ending > up in a "blocked" state: > > https://gitlab.com/qemu-project/qemu/-/pipelines > > I'm not sure why this is -- is it perhaps because there were > other jobs that depended on the now-manual-only jobs ? > Can somebody suggest a fix ? Urgh, my bad, I completely forget this behaviour when reviewing. When we only have when: manual then the job has to be manually started, and it still contributes to pipeline status, so it /must/ triggered manually. If we want it to be manually started and not contribute to the pipeline status we need: rules: ... when: manual allow_failure: true Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On 9/15/21 10:29 AM, Daniel P. Berrangé wrote: > On Tue, Sep 14, 2021 at 08:17:19PM +0100, Peter Maydell wrote: >> On Mon, 13 Sept 2021 at 11:19, Peter Maydell <peter.maydell@linaro.org> wrote: >>> >>> Currently we define a lot of jobs for our custom runners: >>> for both aarch64 and s390x we have >>> - all-linux-static >>> - all >>> - alldbg >>> - clang (manual) >>> - tci >>> - notcg (manual) >>> >>> This is overkill. The main reason to run on these hosts is to get >>> coverage for the host architecture; we can leave the handling of >>> differences like debug vs non-debug to the x86 CI jobs. >>> >>> The jobs are also generally running OK; they occasionally fail due to >>> timeouts, which is likely because we're overloading the machine by >>> asking it to run 4 CI jobs at once plus the ad-hoc CI. >>> >>> Remove the 'allow_failure' tag from all these jobs, and switch the >>> s390x-alldbg, aarch64-all, s390x-tci and aarch64-tci jobs to manual. >>> This will let us make the switch for s390x and aarch64 hosts from >>> the ad-hoc CI to gitlab. >>> >>> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> >> >> It looks like this change has resulted in pipelines ending >> up in a "blocked" state: >> >> https://gitlab.com/qemu-project/qemu/-/pipelines >> >> I'm not sure why this is -- is it perhaps because there were >> other jobs that depended on the now-manual-only jobs ? >> Can somebody suggest a fix ? > > Urgh, my bad, I completely forget this behaviour when reviewing. > When we only have > > when: manual > > then the job has to be manually started, and it still contributes > to pipeline status, so it /must/ triggered manually. > > If we want it to be manually started and not contribute to the > pipeline status we need: > > rules: > ... > when: manual > allow_failure: true Reminds me of the following commits: - d3a4e41da25 ("gitlab-ci: Fix 'when:' condition in acceptance...") - 59e8b62b220 ("gitlab-ci: Fix 'when:' condition in EDK2 jobs") - c217fd8e36a ("gitlab-ci: Fix 'when:' condition in OpenSBI jobs")
On Wed, 15 Sept 2021 at 09:29, Daniel P. Berrangé <berrange@redhat.com> wrote: > Urgh, my bad, I completely forget this behaviour when reviewing. > When we only have > > when: manual > > then the job has to be manually started, and it still contributes > to pipeline status, so it /must/ triggered manually. > > If we want it to be manually started and not contribute to the > pipeline status we need: > > rules: > ... > when: manual > allow_failure: true So there's no way to say "if it is triggered, then it must not fail, but if it is not triggered, that's OK" ? I guess it's not a big deal either way though. So the fix is to add back the allow_failure tag to those jobs which are manual. I'll send a patch... -- PMM
On Wed, Sep 15, 2021 at 01:12:23PM +0100, Peter Maydell wrote: > On Wed, 15 Sept 2021 at 09:29, Daniel P. Berrangé <berrange@redhat.com> wrote: > > Urgh, my bad, I completely forget this behaviour when reviewing. > > When we only have > > > > when: manual > > > > then the job has to be manually started, and it still contributes > > to pipeline status, so it /must/ triggered manually. > > > > If we want it to be manually started and not contribute to the > > pipeline status we need: > > > > rules: > > ... > > when: manual > > allow_failure: true > > So there's no way to say "if it is triggered, then it must > not fail, but if it is not triggered, that's OK" ? Not that I've found. > I guess it's not a big deal either way though. > So the fix is to add back the allow_failure tag to those jobs > which are manual. I'll send a patch... Note "allow_failure" is allowed both at the top level of the job and inside the "rules:". I find it clearer if we put it against the "rules:" section as shown above. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Wed, 15 Sept 2021 at 13:16, Daniel P. Berrangé <berrange@redhat.com> wrote: > > On Wed, Sep 15, 2021 at 01:12:23PM +0100, Peter Maydell wrote: > > On Wed, 15 Sept 2021 at 09:29, Daniel P. Berrangé <berrange@redhat.com> wrote: > > > Urgh, my bad, I completely forget this behaviour when reviewing. > > > When we only have > > > > > > when: manual > > > > > > then the job has to be manually started, and it still contributes > > > to pipeline status, so it /must/ triggered manually. > > > > > > If we want it to be manually started and not contribute to the > > > pipeline status we need: > > > > > > rules: > > > ... > > > when: manual > > > allow_failure: true > > > > So there's no way to say "if it is triggered, then it must > > not fail, but if it is not triggered, that's OK" ? > > Not that I've found. > > > I guess it's not a big deal either way though. > > So the fix is to add back the allow_failure tag to those jobs > > which are manual. I'll send a patch... > > Note "allow_failure" is allowed both at the top level of the job > and inside the "rules:". I find it clearer if we put it against > the "rules:" section as shown above. OK, I guess. That does mean that we end up with two allow_failure lines for each of these jobs, though, beacuse they have two separate if clauses in their rules. -- PMM
© 2016 - 2024 Red Hat, Inc.