Re: RFC: docker for CI

[Jonas Hahnfeld]

Am Freitag, den 07.02.2020, 13:21 +0100 schrieb Han-Wen Nienhuys:
> Proposal: rather than using the patchy scripts for validating
> LilyPond, we use docker images.
> 
> General idea
> ============
> 
> There is a script ("driver") that drives docker running on a dedicated
> build machine ("host").
> 
> There are several images:
> 
> * The base dev image.
> 
> The base image is based on some stripped Linux distribution, with all
> the devtools necessary for compiling LilyPond. In addition, it
> contains a copy of ccache, and a git clone of the LilyPond sourcecode
> 
> * The base release image for a specific git commit.
> 
> The procedure to build it is as follows:
> 
>   * take the base dev image
>   * fetch the git commit
>   * runs (make ; make test-baseline)
>   * runs (make dist-clean)
> 
> This saves the result as a docker image. The Docker image now contains
> a clean lilypond tree, the C++ compilation results (in ccache), and a
> test baseline.
> 
> The base release image is made at official LilyPond releases, or at
> any release that has a new graphical regtest result
> 
> 
> CI: build binary
> ================
> 
> Given a proposed change (as git commit):
> 
>  * take base release image
>  * run (make; make doc) >& log-file
> 
> On success, the driver saves the result as a docker image, tagged with the
> commit sha1.
> 
> On failure, the driver uploads the last bit of the log-file to our code
> review system.
> 
> 
> CI: regtest
> ===========
> 
> Given a proposed change (as git commit)
> 
>   * take CI build image
>   * run (make check >& log-file)
>   * use a headless browser to take a image snapshot of the top of regtest
> result page.
> 
> 
> On success, the driver uploads the image snapshot to code review.
> 
> On failure, the driver uploads the last bit of the log-file to code review.
> 
> 
> 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.

> * 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?

Jonas

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