qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Daniel P . Berrangé
Subject: Re: [PATCH v2 0/2] QEMU Gating CI
Date: Tue, 28 Jul 2020 17:15:17 +0100
User-agent: Mutt/1.14.5 (2020-06-23)

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.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]