[PATCH] gitlab-ci: Make more custom runner jobs manual, and don't allow failure

Peter Maydell posted 1 patch 2 years, 6 months ago
Test checkpatch passed
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20210913101948.12600-1-peter.maydell@linaro.org
Maintainers: Willian Rampazzo <willianr@redhat.com>, Wainer dos Santos Moschetta <wainersm@redhat.com>, "Alex Bennée" <alex.bennee@linaro.org>, Thomas Huth <thuth@redhat.com>, "Philippe Mathieu-Daudé" <f4bug@amsat.org>
.gitlab-ci.d/custom-runners.yml | 20 ++++++++------------
1 file changed, 8 insertions(+), 12 deletions(-)
[PATCH] gitlab-ci: Make more custom runner jobs manual, and don't allow failure
Posted by Peter Maydell 2 years, 6 months ago
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


Re: [PATCH] gitlab-ci: Make more custom runner jobs manual, and don't allow failure
Posted by Daniel P. Berrangé 2 years, 6 months ago
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 :|


Re: [PATCH] gitlab-ci: Make more custom runner jobs manual, and don't allow failure
Posted by Peter Maydell 2 years, 6 months ago
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

Re: [PATCH] gitlab-ci: Make more custom runner jobs manual, and don't allow failure
Posted by Willian Rampazzo 2 years, 6 months ago
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>


Re: [PATCH] gitlab-ci: Make more custom runner jobs manual, and don't allow failure
Posted by Thomas Huth 2 years, 6 months ago
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>


Re: [PATCH] gitlab-ci: Make more custom runner jobs manual, and don't allow failure
Posted by Peter Maydell 2 years, 6 months ago
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

Re: [PATCH] gitlab-ci: Make more custom runner jobs manual, and don't allow failure
Posted by Peter Maydell 2 years, 6 months ago
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

Re: [PATCH] gitlab-ci: Make more custom runner jobs manual, and don't allow failure
Posted by Willian Rampazzo 2 years, 6 months ago
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
>


Re: [PATCH] gitlab-ci: Make more custom runner jobs manual, and don't allow failure
Posted by Daniel P. Berrangé 2 years, 6 months ago
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 :|


Re: [PATCH] gitlab-ci: Make more custom runner jobs manual, and don't allow failure
Posted by Philippe Mathieu-Daudé 2 years, 6 months ago
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")


Re: [PATCH] gitlab-ci: Make more custom runner jobs manual, and don't allow failure
Posted by Peter Maydell 2 years, 6 months ago
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

Re: [PATCH] gitlab-ci: Make more custom runner jobs manual, and don't allow failure
Posted by Daniel P. Berrangé 2 years, 6 months ago
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 :|


Re: [PATCH] gitlab-ci: Make more custom runner jobs manual, and don't allow failure
Posted by Peter Maydell 2 years, 6 months ago
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