Re: [PATCH v2 0/2] QEMU Gating CI

[Cleber Rosa <crosa@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3964 bytes --]

On Tue, Jul 28, 2020 at 05:08:50PM +0100, Peter Maydell wrote:
> On Tue, 28 Jul 2020 at 16:51, Cleber Rosa <crosa@redhat.com> wrote:
> >
> > On Tue, Jul 28, 2020 at 03:48:38PM +0100, Peter Maydell wrote:
> > > On Mon, 20 Jul 2020 at 18:22, Cleber Rosa <crosa@redhat.com> wrote:
> > > > Sure.  It's important that PATCH 2/2 in this series is included in a
> > > > branch that you need to push to the "staging" branch on the
> > > > https://gitlab.com/qemu-project/qemu repo (it could be just that one
> > > > patch).  Then, you can run:
> > > >
> > > >   ./scripts/ci/gitlab-pipeline-status --verbose -w
> > > >
> > > > And that should be it.  You can drop '--verbose' if you just want the
> > > > final outcome as the result.
> > >
> > > I tried this (local branch named "staging", pushed to gitlab
> > > remote "staging" branch), but it said:
> > >
> > > e104462:bionic:qemu$ ./scripts/ci/gitlab-pipeline-status --verbose -w
> > > ERROR: No pipeline found
> > > failure
> > >
> >
> > Hi Peter,
> >
> > I think this may just have been a timing issue.  GitLab usually does
> > take a few seconds after it receives a branch push to create a
> > pipeline.  Let me know if you'd like to see this within the script, or
> > if you'd rather put a sleep between your push and the
> > "gitlab-pipeline-status" execution.
> 
> Ah, right. I ran the command again and it does (eventually)
> print "running...". I think the ideal behaviour would be for
> the script to have some kind of "waiting for pipeline to start..."
> phase where it sits and polls for the pipeline to appear,
> with a pretty long timeout (minutes?).
>

Fair enough.  I'll send a patch to change the script behavior.

> > > It does seem to have kicked off the pipeline on gitlab though:
> > > https://gitlab.com/qemu-project/qemu/-/pipelines/171671136/builds
> >
> > There's already new content on the staging branch, but supposing my local
> > staging branch contained commit 6e7c2dcb50907aa6be0cbc37f81801d2fa67f7b4
> > (https://gitlab.com/qemu-project/qemu/-/commit/6e7c2dcb50907aa6be0cbc37f81801d2fa67f7b4),
> > the command you ran:
> >
> >   ./scripts/ci/gitlab-pipeline-status --verbose -w
> >
> > Should have behaved as this (output from my machine):
> >
> >   /scripts/ci/gitlab-pipeline-status --verbose -w -c 6e7c2dcb50907aa6be0cbc37f81801d2fa67f7b4
> >   running...
> >
> > > OTOH I can't see anything on that web page that suggests that
> > > it's submitting jobs to the s390 or aarch64 boxes -- is it
> > > intended to?
> > >
> >
> > All the jobs for that pipeline have been created as expected, for
> > instance:
> >
> >    https://gitlab.com/qemu-project/qemu/-/jobs/659874849
> >
> > But given the recent changes to the GitLab YAML adding other phases,
> > it's waiting for the previous phases.
> 
> The page now says "This job has been skipped"...
>

I saw that, and I was very disappointed... I double checked the
machines, the runners status, tag names and they all seem to be OK.

So, I think the reason for the skip (there's an open issue on GitLab
itself about not communicating to users the reason) is that GitLab
does a late evaluation of the job condition.  For those jobs the
condition is:

   rules:
   - if: '$CI_COMMIT_REF_NAME == "staging"'

Which by the time the job was evaluated it was no longer true (there
was new content on the staging branch).  There are multiple ways to
solve the problem, including (and in my order of preference):

 1. using '$CI_COMMIT_BRANCH' instead of '$CI_COMMIT_REF_NAME', given
    that the pushed branch name should be kept stable even if the content
    (thus reference name) changes

 2. not changing anything if you believe that under normal
    circunstances one pipeline for the staging will be running at a
    time.

I'll prepare a new version with #1, unless you have a strong feeling
against it.

- Cleber.

> thanks
> -- PMM
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]