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