Mail archive

Re: [alpine-devel] rethinking the building infra

From: A. Wilcox <>
Date: Tue, 6 Feb 2018 12:31:22 -0600

Hi there Natanael,

I thought I could go through and say what we (Adélie) would like to see too.

On 02/05/18 18:39, Natanael Copa wrote:
> I'd like to discuss what we need from the build infra and why, before we
> start talk about how to do it and what implementation etc.
> Here are some things I want a new building infra should be able to
> do:
> - automatic build on git push
> There should not be needed to do anything more than do a git push to
> get the package built and uploaded. Like we have today, but with
> better error reporting.

That would be good. One important thing is that it may be desireable to
have a "[build skip]" or such for commits that deal with non-build
things (like git hooks or such) or a series with interdependencies.

> - isolated environment for each build
> each build should set up an isolated enviroment and destroy it when
> build is done. This could be a container but it would be nice to be
> able to set up a disposable build env in a vm in case we want hook it
> into github PRs or similar. It should also kill everything after
> build and test is done so we dont get any remains of test suites that
> does not clean up after themselves (like redis and epmd)

It should not kill everything in cases of error. I can't tell you how
much time abuild has saved me by leaving src/ alone when it fails to
compile or test.

> - support multi architectures
> need to support x86_64, x86, armhf, aarch64, ppc64le and s390x. Would
> be nice it its not too complicated to add new architectures.


> - support parallel building
> would be nice to be able to distribute the workload over available
> build servers. Should be possible and relatively easy to add new
> hardware to the pool or remove or replace old without taking
> everything down.

That would be a very nice thing. It would also be nice for it to track
what builders are idle so it can pick one. I am just thinking of a

Two builders: ppc64-1, ppc64-2
Four packages are modified close together: llvm4, which, unzip, acl

If it just goes in sequence, 'unzip' will be held up on llvm4, when
ppc64-2 could easily build it.

Maybe that is too much of a "implementation detail", but I think it is
an important requirement.

> - support cross compile
> would be nice to cross compile packages that (easily) can be cross
> compiled. For example, we could let a big x86_64 or ppc64le machine
> build linux kernel for armhf instead doing that on the slow armhf
> server. Packages that cannot be cross compiled should be built on
> native hardware.

The APKBUILD format doesn't do very well with cross.

Sure, some packages can cross easily, but many cannot. Please see
coreutils mess in Adélie repo for an example:

I don't really recommend cross to 'speed up' builds, especially since it
isn't possible to run tests then. Much better to wait for real
hardware. Only use it for things in

> - separate out signing process of packages and index
> Would be nice if we could give access to build servers to more
> people without giving those people access to the private signing keys.

Yes, when a builder is done, it should give the built package to an
internal, secure system for signing. I have always agreed with this,
and the fact that the abuild signing key has to be present and readable
by abuild has prevented me from giving people access to our 32-bit x86

> - build infra should be able to be used as CI
> We need do automatic compile checks of contributions, for example via
> github pull requests or something corresponding.

I note here that GitLab has CI too, and Jenkins is open source, so
Alpine doesn't always need to be tied to GitHub to still have CI :)

> - efficient caching
> Would be nice to not need to git clone the entire repo for every
> build for every server. Would be nice if we checkout a shared git
> repo or do something so data does not goes over the wire more than
> necessary. Same goes for source and apk packages.

Well, you could use NFS or such if the build servers are on the same
local network. That is what we did at Galapagos Linux. But I'm not
sure if Alpine's build systems are all located in the same network.

> Anything else we need from the building infra?

Adélie would strongly benefit from having build logs kept in a
centralised place. Something like logrotate could be used to keep it
from overflowing, so log maintenance is not something that needs to be
thought about.

The ability to have hooks (like git) for "build started", "build
success", and "build failure" would be useful. Preferrably it would
allow custom ones written in shell or script, not web hoooks. Then we
could have IRC poking if builds fail, and something like #alpine-commits
for all build statuses.

Best to you and yours,

> -nc

A. Wilcox (awilfox)
Project Lead, Adélie Linux

Received on Tue Feb 06 2018 - 12:31:22 UTC