qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Cornelia Huck <cohuck@redhat.com>
Cc: "Thomas Huth" <thuth@redhat.com>,
	qemu-devel@nongnu.org,
	"Wainer dos Santos Moschetta" <wainersm@redhat.com>,
	"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
	"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 14:23:47 +0100	[thread overview]
Message-ID: <YRpm495McORAAycn@redhat.com> (raw)
In-Reply-To: <87sfz9ttlo.fsf@redhat.com>

On Mon, Aug 16, 2021 at 03:19:31PM +0200, Cornelia Huck wrote:
> On Mon, Aug 16 2021, Daniel P. Berrangé <berrange@redhat.com> wrote:
> 
> > On Mon, Aug 16, 2021 at 01:47:08PM +0200, Cornelia Huck wrote:
> >> On Mon, Aug 16 2021, Daniel P. Berrangé <berrange@redhat.com> wrote:
> >> 
> >> > When I'm working on changing gitlab CI rules, then I burn loads of
> >> > minutes which is especially troubling - limited CI minutes will make
> >> > it very hard for me to debug future CI rule changes :-(
> >> 
> >> I hope that will not make gitlab CI a complete non-starter -- if you
> >> cannot easily debug a test case that is failing, it's mostly
> >> useless. We've seen too many cases where a failure could not be
> >> reproduced when the test case was running locally.
> >
> > One of the best things about GitLab compared to what we had with
> > Travis is that the build environment is 100% container based (until
> > Cleber's custom runners arrived).  This meant that when something
> > does fail in GitLab, you can pull the container image down from
> > the gitlab registry and run the build locally. You still have
> > differences due to hardware or CPUs resources, but its a hell of
> > alot easier to reproduce than before. This is good enough for most
> > contributors in general, but not for the CI maintainers, who need
> > to debug especially the CI system as it exists on GitLab.
> 
> Correct me if I'm wrong, but I remember that some of the more
> aggravating failures in particular could not be reproduced outside of
> the gitlab environment, even while using the same image.

There will always be some like that for sure. Some problems are very
sensitive to timing issues that are affected by load or CPUs parallism,
etc.


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 13:27 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é
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é [this message]
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=YRpm495McORAAycn@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).