Subject: Re: [alpine-devel] rethinking the building infra
To: alpine-devel@lists.alpinelinux.org, Natanael Copa <ncopa@alpinelinux.org>
References: <20180206013944.7fa393b6@ncopa-macbook.copa.dup.pw>
From: Oliver Smith <ollieparanoid@bitmessage.ch>
Message-ID: <7676a963-d2b0-bf15-4f51-f5aa0d034e9a@bitmessage.ch>
Date: Wed, 07 Feb 2018 19:58:00 +0000
Precedence: list
MIME-Version: 1.0
In-Reply-To: <20180206013944.7fa393b6@ncopa-macbook.copa.dup.pw>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit

Hey Natanael,

the list sounds good to me, especially the increased security features!

While I agree with A. Wilcox that cross-compiling has the disadvantage of not running tests (or not properly if done through QEMU), I think it *does* make sense at least for kernels (there aren't any tests to execute for them). In my opinion, this is rather a detail, and the important thing would be getting everything else implemented first. With that being said: We have cross-compiling binary packages in the postmarketOS repo since we do lots of cross-compiling: gcc-armhf, binutils-armhf, musl-armhf etc. The aports for these are automatically generated from the upstream ones in Alpine (basically hardcoded variables from the bootstrap script on top). Unless the new build system would approach cross-compiling in a completely different way, you would also need such binary packages to do it, so maybe this feature can be upstreamed properly (that is the long-term plan anyway, if you guys want to have this - maybe with subpackages?).

Regarding caching: Maybe ccache makes sense, if it was separated for each package, and incoming pull-requests could only read from that cache, not write to it.

Finally, I am not sure if the idea is to replace abuild entirely, or just abuild-rootbld. In case abuild should be replaced, I hope to see the following features preserved (since we make use of them in pmbootstrap, which wraps abuild):
- (passing through environment variables)
- abuild -r (install depends with abuild)
- abuild -d (do not install depends with abuild)
- abuild -f (force)
- abuild undeps
- abuild menuconfig
- abuild checksum
- abuild unpack
- abuild prepare

Thanks,
Oliver

Natanael Copa:
> Hi!
> 
> I think we need to rethink the building infrastructure. The current
> build scripts were written as a quick and dirt way to get started and
> have lived longer way longer than originally planned. It simply does
> not scale and is very fragile.
> 
> I guess I don't need to go any deeper into why we need replace it...
> 
> 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.
> 
> - 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)
> 
> - 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.
> 
> - 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.
> 
> - 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.
> 
> - 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.
> 
> - 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.
> 
> Anything else we need from the building infra?
> 
> -nc
> 
> 
> ---
> Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
> Help:         alpine-devel+help@lists.alpinelinux.org
> ---
> 
> 



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---