qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Thomas Huth <thuth@redhat.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	"Andrew Jones" <drjones@redhat.com>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	qemu-devel <qemu-devel@nongnu.org>,
	"Wainer dos Santos Moschetta" <wainersm@redhat.com>,
	"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
	"Stefan Hajnoczi" <stefanha@redhat.com>,
	"Cleber Rosa" <crosa@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Alex Bennée" <alex.bennee@linaro.org>
Subject: Re: Serious doubts about Gitlab CI
Date: Tue, 30 Mar 2021 14:19:03 +0100	[thread overview]
Message-ID: <YGMlR9gXwPqLdhr0@redhat.com> (raw)
In-Reply-To: <04e5e251-7a09-dcf6-82ad-31bf696bc248@redhat.com>

On Tue, Mar 30, 2021 at 01:55:48PM +0200, Thomas Huth wrote:
> On 30/03/2021 13.19, Daniel P. Berrangé wrote:

> > Another example, is that we test builds on centos7 with
> > three different combos of crypto backend settings. This was
> > to exercise bugs we've seen in old crypto packages in RHEL-7
> > but in reality, it is probably overkill, because downstream
> > RHEL-7 only cares about one specific combination.
> 
> Care to send a patch? Or shall we just wait one more months and then remove
> these jobs (since we won't support RHEL7 after QEMU 6.0 anymore)?

Yeah, we'll be able to cull this entirely very soon, including
both the C backcompat code and CI jobs at the same time, so I'll
just wait.


> > Our docker containers install ccache already and I could have sworn
> > that we use that in gitlab, but now I'm not so sure. We're only
> > saving the "build/" directory as an artifact between jobs, and I'm
> > not sure that directory holds the ccache cache.
> 
> AFAIK we never really enabled ccache in the gitlab-CI, only in Travis.
> 
> > > This is as far as I've gotten with thinking about CI efficiency. Do you
> > > think these optimizations are worth investigating or should we keep it
> > > simple and just disable many builds by default?
> > 
> > ccache is a no-brainer and assuming it isn't already working with
> > our gitlab jobs, we must fix that asap.
> 
> I've found some nice instructions here:
> 
> https://gould.cx/ted/blog/2017/06/10/ccache-for-Gitlab-CI/
> 
> ... and just kicked off a build with these modifications, let's see how it
> goes...

Yep, that looks similar to what we do in libvirt, though we don't override
the compiler at the job level. Instead we just ensure the dir containing
ccache symlinks appears first in $PATH.

So in containers we have this:

https://gitlab.com/libvirt/libvirt/-/blob/master/ci/containers/centos-8.Dockerfile

and in gitlab-ci.yml we have env vars set

  export CCACHE_BASEDIR="$(pwd)"
  export CCACHE_DIR="$CCACHE_BASEDIR/ccache"
  export CCACHE_MAXSIZE="500M"
  export PATH="$CCACHE_WRAPPERSDIR:$PATH"

And per-job caches:

  cache:
    paths:
      - ccache/
    key: "$CI_JOB_NAME"

note the "key" is important to avoid clashing caches from different
envs.

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



  parent reply	other threads:[~2021-03-30 13:21 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-17 20:29 Serious doubts about Gitlab CI Philippe Mathieu-Daudé
2021-03-18  1:28 ` Bin Meng
2021-03-18  8:55   ` Philippe Mathieu-Daudé
2021-03-18  9:33 ` Daniel P. Berrangé
2021-03-18  9:50   ` Philippe Mathieu-Daudé
2021-03-18 10:28     ` Philippe Mathieu-Daudé
2021-03-19  5:34       ` Thomas Huth
2021-03-18 19:46 ` Stefan Hajnoczi
2021-03-18 19:52   ` John Snow
2021-03-18 20:53     ` Philippe Mathieu-Daudé
2021-03-18 20:30   ` Paolo Bonzini
2021-03-19  9:33     ` Stefan Hajnoczi
2021-03-19  9:41       ` Paolo Bonzini
2021-03-19 11:44         ` Philippe Mathieu-Daudé
2021-03-19 10:18       ` Andrew Jones
2021-03-19 10:59         ` Paolo Bonzini
2021-03-19 11:34           ` Philippe Mathieu-Daudé
2021-03-19 15:27             ` Wainer dos Santos Moschetta
2021-03-29 14:10               ` Stefan Hajnoczi
2021-03-30 11:19                 ` Daniel P. Berrangé
2021-03-30 11:55                   ` Thomas Huth
2021-03-30 12:09                     ` Paolo Bonzini
2021-03-30 12:23                       ` Philippe Mathieu-Daudé
2021-03-30 12:45                         ` Paolo Bonzini
2021-03-30 13:12                           ` Daniel P. Berrangé
2021-03-30 13:19                             ` Paolo Bonzini
2021-03-30 13:27                               ` Daniel P. Berrangé
2021-03-30 15:59                                 ` Warner Losh
2021-03-30 16:11                                   ` Peter Maydell
2021-03-30 16:24                                     ` Warner Losh
2021-03-30 16:10                                 ` Thomas Huth
2021-03-30 13:09                       ` Daniel P. Berrangé
2021-03-30 12:09                     ` Paolo Bonzini
2021-03-30 12:19                     ` Peter Maydell
2021-03-30 12:33                     ` Philippe Mathieu-Daudé
2021-03-30 13:19                     ` Daniel P. Berrangé [this message]
2021-03-31  7:54                       ` Thomas Huth
2021-03-31  9:31                         ` Andrea Bolognani
2021-03-30 14:13                     ` Stefan Hajnoczi
2021-03-30 14:23                       ` Paolo Bonzini
2021-03-30 14:30                         ` Daniel P. Berrangé
2021-03-30 14:09                   ` Stefan Hajnoczi
2021-03-19 12:07         ` Markus Armbruster
2021-03-19 13:06           ` Thomas Huth

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=YGMlR9gXwPqLdhr0@redhat.com \
    --to=berrange@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=crosa@redhat.com \
    --cc=drjones@redhat.com \
    --cc=f4bug@amsat.org \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=stefanha@redhat.com \
    --cc=thuth@redhat.com \
    --cc=wainersm@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).