Without a specific volume mount, the Buildah working container will be
stored in the Jenkins pod container filesystem. This not only affects
performance, but limits the size of the working container filesystem and
the final image, as the worker nodes do not have very much space for
container filesystems. Thus, we need to mount an ephemeral Longhorn
volume in the job pod to provide more space to Buildah.
Using a read-only root filesystem helps ensure that no temporary data
get written to container storage. This of course breaks the work-around
we had in place for overriding the broken default `storage.conf` in the
_buildah_ image, so we mount a _tmpfs_ filesystem at `/home/build` as a
different work-around.
The _build/cross_ image no longer contains a Rust toolchain. The
_build/rust-cross_ is layerd on top of _build/cross_ and includes a
cross-compiling toolchain for Rust.
In order to create multiple Jenkins build pipelines for this repository,
I'm splitting it up with branches. There will be a branch for each
image:
* base/main: The base image
* cross/main: The image with a cross-compiler toolchain
* build/main: The final build image
Note _/main_ in each name. The intent here is to be able to have
different "sub-branches" for each image, so e.g. there might be a
_base/dev_.
In addition to the branches for each image, there will be branches for
the shared library code as well, named like _lib/main_. The image
branches will checkout this branch using `git worktree`.
A recent update to the Gentoo repo as introduced a circular dependency
between _m4_ and _gettext_. We can avoid it by setting `USE=-nls`.
This is OK because we don't need i18n in the build environment.
Although Jenkins is supposed to be able to decode ANSI escape sequences
for terminal colors, it doesn't do so in all cases and when it does, it
doesn't seem to produce the right result for output from `emerge`.
Several log files in `/var/log` are owned by users other than root.
From outside the user namespace, these files are inaccessible to the
unprivileged user, so we need to change their ownership before we can
archive them.
During development, we leave a container running and `exec` into it
to run multiple commands. To keep the container running, we need a PID
1 process that never terminates, which we achieved previously with
Python. This technically works, but ultimately leaves a lot of zombie
processes. If we use a "true" init process for PID 1, it will clean
these up.
Although most software can be cross-compiled, there are quite a few edge
cases where executables built for the target system need to be run on
the build host. Notably, `ldconfig` only considers libraries for the
same machine type as the tool itself, so it's impossible to run it in a
cross-compiled root. In order to get passed these situations, we can
use QEMU in user mode to emulate the target architecture, allowing ARM
executables to run on AMD64 machines.
The _build/cross-{target}_ image only includes the crossdev toolchain.
What we really need is the _build/build-{target}_ image, which contains
all the tools necessary to build an Aimee OS project.
* Base
* Crossdev
* Build
The *Base* layer is bootstrapped from a regular Gentoo stage 3
environment. The *Build* layer is the primary artifact, and is
"squashed" into a single layer when built.
