qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: "Philippe Mathieu-Daudé" <f4bug@amsat.org>
Cc: "Thomas Huth" <thuth@redhat.com>,
	"Cornelia Huck" <cohuck@redhat.com>,
	qemu-devel@nongnu.org,
	"Wainer dos Santos Moschetta" <wainersm@redhat.com>,
	"Willian Rampazzo" <willianr@redhat.com>,
	"Alex Bennée" <alex.bennee@linaro.org>
Subject: Re: [PATCH 2/2] gitlab: don't run CI jobs by default on push to user forks
Date: Mon, 16 Aug 2021 12:35:15 +0100	[thread overview]
Message-ID: <YRpNUE7722YPIYjq@redhat.com> (raw)
In-Reply-To: <3062c8e9-b7f1-30ef-ddfa-006f4ea4f7e7@amsat.org>

On Mon, Aug 16, 2021 at 01:20:14PM +0200, Philippe Mathieu-Daudé wrote:
> On 8/16/21 1:03 PM, Daniel P. Berrangé wrote:
> >> (c) a subsystem maintainer is preparing a pull request
> >>
> >> Ideally, that should run the 'gating' set, to eliminate needless bounces
> >> of the pull request; plus some subsystem-specific manual testing on
> >> top. In practice, the 'full' set might be good enough.
> > 
> > Yeah, the full/gating set is what I would thing subsys maintainers
> > would want to use, to minimize risk that Peter's tests throw back
> > the merge due to failure. The only difference of gating vs full
> > is whether the acceptance tests run.
> 
> "run" or "pass"?

In 'full' set the acceptance test jobs are marked to allow to be
triggered manually and won't affect pipeline status if they fail

In 'gating' set the acceptance test jobs always run and are
required to pass.


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	other threads:[~2021-08-16 11:36 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-12 18:04 [PATCH 0/2] gitlab: prepare for limited CI minutes by not running by default Daniel P. Berrangé
2021-08-12 18:04 ` [PATCH 1/2] docs: split the CI docs into two files Daniel P. Berrangé
2021-08-16 11:02   ` Philippe Mathieu-Daudé
2021-08-24 16:29   ` Willian Rampazzo
2021-08-12 18:04 ` [PATCH 2/2] gitlab: don't run CI jobs by default on push to user forks Daniel P. Berrangé
2021-08-16 10:44   ` Cornelia Huck
2021-08-16 11:03     ` Daniel P. Berrangé
2021-08-16 11:20       ` Philippe Mathieu-Daudé
2021-08-16 11:35         ` Daniel P. Berrangé [this message]
2021-08-16 11:45           ` Philippe Mathieu-Daudé
2021-08-16 11:47       ` Cornelia Huck
2021-08-16 12:01         ` Daniel P. Berrangé
2021-08-16 13:19           ` Cornelia Huck
2021-08-16 13:23             ` Daniel P. Berrangé
2021-08-16 15:16           ` Philippe Mathieu-Daudé
2021-08-25 10:42   ` Thomas Huth
2021-09-15 14:45     ` Daniel P. Berrangé
2022-05-10  8:51   ` Thomas Huth
2022-05-10  9:13     ` Daniel P. Berrangé

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YRpNUE7722YPIYjq@redhat.com \
    --to=berrange@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=cohuck@redhat.com \
    --cc=f4bug@amsat.org \
    --cc=qemu-devel@nongnu.org \
    --cc=thuth@redhat.com \
    --cc=wainersm@redhat.com \
    --cc=willianr@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).