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

[Philippe Mathieu-Daudé]

On 7/28/20 6:33 PM, Cleber Rosa wrote:
> 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:
>>>
...
>>>> 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.

For mainstream, usually one at a time is enough, because if you tests
various and one is merged, then you need to rerun on top of the merged
one, so it is not very useful.

For other users, it is useful. I'd certainly finish a patch, run the
script, switch branch in another console, do some other work, run
another instance of the script concurrently with the 1st one, etc...

> 
> I'll prepare a new version with #1, unless you have a strong feeling
> against it.
> 
> - Cleber.
> 
>> thanks
>> -- PMM
>>