ci: use bread-ecosystem's shared Arch build image/script

Moves the Containerfile and build.sh added in the previous CI fix up
into bread-ecosystem/ci/, so other GTK4 layer-shell products in the
ecosystem can share it instead of each carrying their own copy. This
repo's ci/build.sh is now a thin wrapper that clones bread-ecosystem
at the commit pinned in ci/bread-ecosystem.rev and delegates to its
ci/build.sh — pinned by sha rather than tracking main, so an unrelated
change over there can't silently break this repo's release builds
(the failure mode the bread-theme test fix a moment ago was caused by).

Verified locally: clippy, test, and release build all pass through
the new delegator path.

CONTRIBUTING.md

@@ -76,14 +76,19 @@ cargo test --release --workspace
 - `release.yml` — triggered on any other `v*` tag push, cuts the actual
   stable release.
 
-All of these build inside a pinned Arch Linux container (`ci/Containerfile`,
+All of these build inside a pinned Arch Linux container on a self-hosted
-run via `ci/build.sh`) on a self-hosted runner — not the runner host's
+runner — not the runner host's native environment. Arch's repos carry
-native environment. Arch's repos carry current `gtk4`/`libadwaita`/
+current `gtk4`/`libadwaita`/`gtk4-layer-shell` as prebuilt packages, so
-`gtk4-layer-shell` as prebuilt packages, so there's no from-source library
+there's no from-source library build to go stale. The Containerfile and
-build to go stale. The image is rebuilt (and re-cached by Docker) only when
+build script are shared across bread-ecosystem GTK4 products, living in
-`ci/Containerfile` changes, so a plain push doesn't refetch or recompile
+`bread-ecosystem/ci/`; `ci/build.sh` here is a thin wrapper that clones
-the toolchain. Nothing runs automatically on plain commits or PRs beyond
+that repo at the commit pinned in `ci/bread-ecosystem.rev` (not `main` —
-the jobs listed above. See
+an unrelated change there shouldn't silently affect this repo's release
+builds) and delegates to it. Bump the pin deliberately when you want the
+shared image or build logic updated. A `ci/deps.txt` here (currently
+absent — breadpad needs nothing beyond the shared base) would layer on
+extra pacman packages if that ever changes. Nothing runs automatically on
+plain commits or PRs beyond the jobs listed above. See
 [bread-ecosystem's docs/release-channels.md](https://git.breadway.dev/Breadway/bread-ecosystem/src/branch/main/docs/release-channels.md)
 for the full policy, including how a new product gets wired onto these tracks.
 

ci/Containerfile

@@ -1,22 +0,0 @@
-# Pinned CI build environment for breadpad.
-#
-# Arch instead of Fedora because breadpad targets BOS/Arch only, and Arch's
-# repos already carry current libadwaita/gtk4/gtk4-layer-shell as prebuilt
-# packages — no from-source libadwaita build needed (that from-source build
-# was the repeated CI breakage: rust dep mismatches, libadwaita ABI
-# mismatches, and finally a removed meson option).
-#
-# Base image pinned by digest, package set frozen at build time: this image
-# only changes when someone deliberately rebuilds it, not on every push.
-FROM archlinux@sha256:fae033b815a16f930325c2697e620362be4d2e5d739a301b10ad1fc9c8643a06
-
-RUN pacman -Syu --noconfirm --needed \
-        base-devel \
-        git \
-        pkgconf \
-        rust \
-        gtk4 \
-        libadwaita \
-        gtk4-layer-shell \
-        graphene \
-    && pacman -Scc --noconfirm

ci/bread-ecosystem.rev

@@ -0,0 +1 @@
+cd5da468b3782fddcb52b4eaff0755ff933524be

ci/build.sh

@@ -1,31 +1,21 @@
 #!/usr/bin/env bash
-# Builds (or reuses, via docker's own layer cache) the pinned Arch CI image
+# Delegates to bread-ecosystem's shared CI build image/script, pinned to
-# from ci/Containerfile, then runs the given cargo command inside it against
+# the commit in ci/bread-ecosystem.rev — not `main`. bread-ecosystem's CI
-# this repo checkout.
+# files now affect every product's release pipeline, so bumping the pin
-#
+# is a deliberate act instead of silent drift (see the bread-theme test
-# Cargo's registry/git caches and CARGO_TARGET_DIR are persisted in named
+# that broke here for exactly that reason, before it was pinned by rev).
-# docker volumes so they survive across runs even though the repo checkout
-# itself (a fresh --depth 1 clone per workflow run) does not.
 #
 # Usage: ci/build.sh cargo build --release --locked
 set -euo pipefail
 
 ROOT="$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)"
-cd "$ROOT"
+REV="$(cat "${ROOT}/ci/bread-ecosystem.rev")"
 
-docker build -t breadpad-ci:archlinux -f ci/Containerfile ci
+CACHE_DIR="/tmp/bread-ecosystem-ci-${REV}"
+if [ ! -d "$CACHE_DIR" ]; then
+    rm -rf /tmp/bread-ecosystem-ci-*
+    git clone https://git.breadway.dev/Breadway/bread-ecosystem.git "$CACHE_DIR"
+    git -C "$CACHE_DIR" checkout --quiet "$REV"
+fi
 
-docker run --rm \
+bash "${CACHE_DIR}/ci/build.sh" "$ROOT" "$@"
-    -v "${ROOT}:/workspace" \
-    -v breadpad-cargo-registry:/root/.cargo/registry \
-    -v breadpad-cargo-git:/root/.cargo/git \
-    -v breadpad-cargo-target:/cargo-target \
-    -w /workspace \
-    -e CARGO_TARGET_DIR=/cargo-target \
-    breadpad-ci:archlinux \
-    bash -c '
-        set -euo pipefail
-        "$@"
-        mkdir -p /workspace/target
-        cp -a /cargo-target/. /workspace/target/
-    ' bash "$@"