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

[Cleber Rosa <crosa@redhat.com>]

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

On Tue, Jul 28, 2020 at 05:15:17PM +0100, Daniel P. Berrangé wrote:
> On Tue, Jul 28, 2020 at 12:13:06PM -0400, Cleber Rosa wrote:
> > On Tue, Jul 28, 2020 at 03:51:34PM +0100, Daniel P. Berrangé 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
> > > > 
> > > > It does seem to have kicked off the pipeline on gitlab though:
> > > > https://gitlab.com/qemu-project/qemu/-/pipelines/171671136/builds
> > > > 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?
> > > 
> > > It looks like those jobs are all in the "test" stage of the pipeline, so
> > > it is waiting for the earlier stages to complete before running the jobs.
> > >
> > 
> > Hi Daniel,
> > 
> > Right.  IIUC the criteria for putting jobs in the test stage at the
> > moment is "if they include running tests (in addition to builds) they
> > should be in test".  Looking at that from this perspective, they're in
> > the right place.
> > 
> > But, these jobs don't depend on anything else, including container
> > builds, so there's no reason to have them wait for so long to run.
> > The solution may be to rename the first stage (containers) to something
> > more generic (and unfortunately less descriptive) so that all of them
> > will run concurrently and earlier.
> 
> Just add 'needs: []'  to any jobs that don't depend on earlier jobs.
>

Great, thanks!

Long version: I remember something like this was possible (which I
mentioned in the other reply), but the documentation about stages
(https://docs.gitlab.com/ee/ci/yaml/#stages) made me loose hope when
writing this reply.  Thanks again!

- Cleber.

> 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 :|

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