Re: RFC: docker for CI

[Jonas Hahnfeld]

Am Samstag, den 08.02.2020, 13:51 +0100 schrieb David Kastrup:
> Jonas Hahnfeld via Discussions on LilyPond development
> <
> address@hidden
> > writes:
> 
> > Am Freitag, den 07.02.2020, 13:21 +0100 schrieb Han-Wen Nienhuys:
> > > Considerations
> > > ==============
> > > 
> > > * Because the build happens inside a container, we can test multiple
> > >   builds. We could build against guile 1.8 and 2.2 at the same time,
> > >   for example
> > 
> > I don't agree that we need containers for this, you can easily set
> > environment variables to make configure pick up the version you want to
> > use.
> 
> I use stuff like
> 
> ./configure GUILE_CONFIG=/usr/local/tmp/guile-1.8/bin/guile-config 
> GUILE=/usr/bin/guile
> 
> all the time.

Exactly.

> > > * Because the "build binary" step reuses CCache results, it can
> > >   complete quickly.
> > 
> > Maybe I don't fully understand the proposal, but:
> >  * if we only build the release image for every "official" tag, it will
> > not provide quicker builds - especially towards the end of a cycle when
> > many changes have accumulated.
> >  * if instead we build images for every commit, then incremental
> > building of a provided patch will be fast(er) (_if_ it doesn't touch
> > any header file). But what's then the point of using ccache, we can
> > just trigger a full build?
> 
> Full builds are slower.

True, but my point is that it doesn't matter: You have to do a full
build to populate ccache; or you just build with the changes already
applied, what's the difference?

Jonas

> But I really don't trust our dependencies all
> too much, and for example Clang builds don't get a working set of
> dependencies anyway (which is sort of curious since it is the modular
> Clang that should be able to parse for them easily).

signature.asc
Description: This is a digitally signed message part