lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Build binaries in CI?


From: Jonas Hahnfeld
Subject: Re: Build binaries in CI?
Date: Tue, 18 Apr 2023 19:24:21 +0200
User-agent: Evolution 3.46.4

On Mon, 2023-04-17 at 22:52 +0200, Jean Abou Samra wrote:
> Hi,
> Just a thought related to
> https://gitlab.com/lilypond/lilypond/-/merge_requests/1950: maybe we
> could add optional CI jobs running on CentOS 7 to compile Linux
> official binaries + MinGW binaries ?

Windows binaries are cross-compiled from Ubuntu.

> I have a faint remembrance that Jonas preferred to keep the build
> environment definitions in the Ansible playbooks rather than creating
> Docker images; however, for something run infrequently, I think the
> overhead of deploying the Ansible playbook during the CI job itself
> would be acceptable, right?

This is only part of the reasoning: For some platforms (macOS and
FreeBSD, if we ever want to have binaries again), we cannot compile
using Docker containers. For that reason, I prefer to focus on one
setup with full VMs / bare metal instead of containers.

Also installing packages during jobs and downloading all packages for
the binaries is quite some data volume. I remember that this wasn't
ideal for Dan's runner, but we would need to evaluate specifics.

> It could help testing proposed changes to the release scripts, and
> also reduce the manual building work during each release to only the
> macOS binaries.

The latter point is not really solid since the manual work right now
amounts to starting a VM, extracting the produced tarball and then
running the scripts and waiting. In fact, it's probably going to take
longer for a CI system to build the binaries than for me locally.

There's also the second disadvantage that it means we're not building
all binaries from the exact same tarball anymore. And even if we're
fine with that, it means I have to push the release preparations to a
remote before I know that it works (if I was to run into a problem
right now, I'd just abandon the release and fix the issue first).

In the longer term, I also want to sign the source tarball and the
official binaries, and I'm only going to do that if I can attest the
whole build chain, not with a company owned source forge and CI system
or community provided runners.

In summary, I see the point of testing proposed changes and potentially
nightly builds at some point (only for some platforms though), but I
don't really see an improvement of the actual release process.

Jonas

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]