[libvirt PATCH v3 10/12] gitlab: introduce use of ccache for speeding up rebuilds

[Daniel P. Berrangé]

On Thu, Mar 26, 2020 at 05:38:47PM +0100, Andrea Bolognani wrote:
> On Thu, 2020-03-26 at 14:05 +0000, Daniel P. Berrangé wrote:
> > On Thu, Mar 26, 2020 at 02:50:48PM +0100, Andrea Bolognani wrote:
> > > On Thu, 2020-03-26 at 12:35 +0000, Daniel P. Berrangé wrote:
> > > >  .native_build_default_job_template: &native_build_default_job_definition
> > > >    stage: native_build
> > > > +  cache:
> > > > +    paths:
> > > > +      - ccache/
> > > > +    key: "$CI_JOB_NAME"
> > > > +  before_script:
> > > > +    - mkdir -p ccache
> > > > +    - export CC="ccache gcc"
> > > > +    - export CCACHE_BASEDIR=${PWD}
> > > > +    - export CCACHE_DIR=${PWD}/ccache
> > > 
> > > Having to set this up at the job level is kinda gross, and
> > > specifically the
> > > 
> > >   export CC="ccache gcc"
> > > 
> > > trick is 1) not going to work for FreeBSD and 2) going to break
> > > Go builds.
> > 
> > That's easy enough to fix for FreeBSD - we just set CC=clang vs CC=gcc
> > variable for the jobs at the top level, and then this code can change
> > to CC="ccache $CC".
> > 
> > We don't have any Go code in libvirt but what's the issue with ccache
> > in that case ?
> 
> Yeah, we were hitting it with libvirt-go{,-xml} so it's not really
> relevant in the immediate, but it's still something that we're going
> to have to deal with at some point.
> 
> The problem, IIRC, was that cgo will just break when $CC contains
> more than a single word, so the link farm approach works fine but
> the CC="ccache $CC" approach doesn't.

Ah yes, I remember that now.

> > > Ultimately I think we need to take a cue from what lcitool does when
> > > configuring VMs and generate a simple environment file that is baked
> > > into images and can be sourced from jobs with a single line.
> > 
> > I much prefer to have the job configuration all in the gitlab config file
> > rather than split between the gitlab config and the images, as it lets you
> > understand the full setup.
> 
> I agree in theory, but 1) that specific ship has sailed when we
> started adding stuff like $LANG, $ABI and $CONFIGURE_OPTS in the
> container image's environment and 2) doing it at the .gitlab-ci.yml
> level will result in duplicating a lot of the logic that we already
> have in lcitool.

Setting $LANG makes sense because the container image build
decides what locales are installed and so knows what $LANG
must be used.

Similarly $ABI makes sense as that again is directly based
off which compiler toolchain packages were installed.

In retrospect $CONFIGURE_OPTS was a mistake, becuase that
only makes sense in the context of autotools usage and
decision about how the application will be built. So I'd
remove this one too.

WRT duplication of logic, we only have that because we
use libvirt-jenkins-ci repo/tools to store the Jenkins
job configuration separately from the application repos.
As we phase out & eventually eliminate Jenkins, we will
no longer have a need to store any build recipes in
the libvirt-jenkins-ci repo/tools - they can focus
exclusively on container/image built mgmt, and all the
logic for actually building apps can live in the repos
of those apps.  This will be good as it eliminates more
areas where we need to lock-step change the stuff in
libvirt-jenkins-ci repo vs the main code repos.

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