The dev/rc/release workflows rebuilt libadwaita from source inside an
uncached Fedora container on every single run, because Ubuntu 24.04's
packaged libadwaita was too old for gtk4 0.11's v4_12 feature. That
from-source build broke repeatedly on drift (rust dep versions,
libadwaita ABI, and finally a removed meson option), producing eight
straight failed CI runs.
Arch's repos already carry current gtk4/libadwaita/gtk4-layer-shell as
prebuilt packages, and breadpad only targets BOS/Arch, so there's no
reason to build anything from source. Swap the container base to a
digest-pinned archlinux image (ci/Containerfile) with those packages
installed via pacman, and extract the shared "build the image, run
cargo inside it" logic into ci/build.sh so it isn't duplicated three
times across the workflows. Cargo's registry/git/target caches persist
in named docker volumes across runs.
Also:
- Add check.yml: clippy + test on feature/**/fix/** pushes, so lint/
build breakage surfaces before it reaches main and triggers a
dev-track release.
- Fix release.yml's tag trigger (tags-ignore) so an rc tag push no
longer also spawns a skipped release.yml run alongside rc-release.yml.
Verified locally: the container builds cleanly via pacman (no source
compilation), and `cargo build --release --locked --workspace` inside
it produces working breadpad/breadman binaries linked against
libgtk4-layer-shell.so.0 and libadwaita-1.so.0 respectively.
Documents the dev/beta/main branch and release-track workflow shared
across the bread ecosystem. See bread-ecosystem's docs/release-channels.md
for the full policy this implements.
