tree 02ead12ee79b10abfdd624071802acc771f6bb3e
parent bffdda85d7750c9a9a34289a79281edeae1d73ef
author Leopold <leo@monogon.tech> 1673031457 +0100
committer Leopold Schabel <leo@monogon.tech> 1674155241 +0000

*: bring our own sandbox root

This change removes the build container and replaces it with a
Bazel-built Fedora 37 sysroot which is bind-mounted into the Bazel
sandbox using --sandbox_add_mount_pair. The tools/bazel wrapper script
automatically (re-)generates the sysroot when needed.

Both Bazelisk and Bazel's native wrapper automatically run the
tools/bazel script, which means that our build should now work without
extra steps on any machine with a working Bazelisk setup and unpriv ns.

This fixes all kinds of weirdness caused by the previous podman setup
("bazel run"/container pushes, log access, weird podman bugs,
breaking the IDE plugin for any non-Monogon workspaces...).

Using the sandbox hash as an action var also ensures that the cache
is invalidated whenever the ambient environment changes. Previously,
Bazel did not invalidate build steps when any host dependency changed.
To my knowledge, this was the only remaining cause for stale builds.

It also means we cannot depend on the host toolchain since it
won't be accessible in the sandbox, and anything that inspects the
host during analysis stage will fail. This currently means that
running on a non-Fedora host won't work - we fix this next.

All RPMs are pinned and the sysroot is fully reproducible.

Once we upgrade to Bazel 5.x, we can take it further by enabling
--experimental_use_hermetic_linux_sandbox and fully remove the
remaining host paths from the sandbox for full hermeticity.

In a follow-up, we can clean up the CI image to only contain the
minimum dependencies needed for Bazelisk and the agent.

Existing IntelliJ users need to remove the -Dbazel.bep.path flag
from their VM options.

Handbook/Rust rules are disabled temporarily to keep CI green
(requires a more recent rules_rust version).

Change-Id: I1f17d57d985ff9d749bf3359f259d8ef52247c18
Reviewed-on: https://review.monogon.dev/c/monogon/+/1033
Tested-by: Jenkins CI
Reviewed-by: Lorenz Brun <lorenz@monogon.tech>