Files
fips/packaging/debian/Dockerfile.build
T
Johnathan Corgan 01be207274 Embed the source revision in container-built binaries again
The build image had no git, so build.rs could not read the revision and every
binary built through the container carried none: -V printed only the version.
The image now installs git, and trusts the source mounted at /src, which is
owned by the host user while the build runs as root; without that entry git
refuses the repository and the revision is silently empty just the same.

The image tag now includes a hash of Dockerfile.build. Before, the tag named
only the floor image and the toolchain, so a host with the image cached kept
using it after the Dockerfile changed, and this change would never have
reached it.

A build from a git worktree still has no revision, because the worktree's git
directory is outside the mounted tree. That is documented, with the -V
reference noting that the revision is omitted when it could not be read,
rather than worked around; release and CI builds use full checkouts.
2026-09-19 10:08:39 +00:00

66 lines
3.0 KiB
INI

# Build image for the Linux release artifacts.
#
# Pinned to the oldest distribution FIPS supports, because the glibc a binary is
# linked against decides the glibc it will run on. See packaging/build-floor.env
# for the floor and the reasoning; BASE is passed from there, not written here,
# so there is one place to change it.
#
# This image carries the toolchain and the build dependencies only. It never
# carries the source: the source is mounted at run time, so editing a file does
# not invalidate the image and a warm rebuild costs seconds rather than minutes.
#
# A build from a git worktree carries no source revision: the worktree's .git is
# a file pointing outside the mounted tree, so git cannot read it here. Release
# and CI builds use full checkouts and carry one.
ARG BASE=ubuntu:22.04
FROM ${BASE}
ENV DEBIAN_FRONTEND=noninteractive
# dpkg-dev is not in a bare ubuntu:22.04 and is what provides dpkg-shlibdeps,
# which cargo-deb's "$auto" dependency resolution shells out to. Without it the
# declared dependencies would silently lose their versions again.
RUN apt-get update && apt-get install -y --no-install-recommends \
build-essential \
pkg-config \
libdbus-1-dev \
libclang-dev \
clang \
binutils \
dpkg-dev \
git \
curl \
ca-certificates \
&& apt-get clean && rm -rf /var/lib/apt/lists/*
# build.rs asks git for the revision it embeds in the binaries. The source is
# mounted at /src owned by the host user, while the build runs as root, and git
# refuses a repository owned by someone else: without this entry the revision is
# silently empty, exactly as it was when the image had no git at all.
# The dirty flag can be stale in a local container build. build.rs reruns only
# when .git/HEAD or .git/refs change, and the target directory is a persistent
# volume, so an uncommitted edit alone does not refresh it; git here also runs
# without the host user's global excludes, so a file only those ignore reads as
# dirty. Release and CI builds start from a committed, fresh tree.
RUN git config --system --add safe.directory /src
# The toolchain version is passed in, read from rust-toolchain.toml by the
# calling script, and the image tag carries it -- so the image cannot drift from
# the compiler the rest of CI uses, and bumping the pin rebuilds the image. The
# builder this replaces installed `stable` and never copied rust-toolchain.toml,
# so it compiled with a different compiler from the release and nothing said so.
ARG RUST_TOOLCHAIN
ENV RUSTUP_HOME=/usr/local/rustup \
CARGO_HOME=/usr/local/cargo \
PATH=/usr/local/cargo/bin:$PATH
RUN test -n "${RUST_TOOLCHAIN}" \
&& curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs \
| sh -s -- -y --profile minimal --default-toolchain "${RUST_TOOLCHAIN}" \
&& chmod -R a+w "$RUSTUP_HOME" "$CARGO_HOME"
ARG CARGO_DEB_VERSION=3.6.3
RUN cargo install cargo-deb --version "${CARGO_DEB_VERSION}" --locked \
&& chmod -R a+w "$CARGO_HOME"
WORKDIR /src