ci(oci): switch build cache from registry to runner gha cache #361

Merged

David merged 1 commit from feat/MAPPS-326-oci-gha-build-cache into main

2026-06-26 03:06:13 +02:00

David commented

2026-06-26 02:49:36 +02:00

Owner

Switches the mokosh-www OCI build cache from the registry to act_runner's built-in type=gha cache server, and removes the MAPPS-131 "Warm build cache" workaround that only existed to survive the registry stall.

Why

build-oci-image.yml cached build layers via type=registry against a :buildcache tag. The dev.a8n.run registry cache-export PUT stalls indefinitely with no error (MAPPS-131 hung the job ~3h until the runner max-runtime killed it, even after --push had finished). To work around it, cache-to was pulled out of the main build into a trailing best-effort "Warm build cache" step guarded by timeout-minutes: 20 + continue-on-error: true and skipped on tag builds (MAPPS-121).

type=gha points buildx at the on-LAN Actions cache server instead (the same cache.enabled server the Check workflow already uses), matching the governance standard set in GOV-20 / vervain-server VS-53. The export is fast and does not stall, so the entire workaround collapses back into the main build.

Changes

Add an "Export Actions runtime env for buildx gha cache" step (crazy-max/ghaction-github-runtime@v3) before the build. A raw docker buildx build (unlike docker/build-push-action) does not auto-inject the gha cache env, and ACTIONS_RUNTIME_TOKEN is masked from run: steps, so this re-exports ACTIONS_CACHE_URL / ACTIONS_RUNTIME_TOKEN into GITHUB_ENV.
"Build and push mokosh-www image" now uses cache-from type=gha and cache-to type=gha,mode=max,ignore-error=true inline.
Remove the "Warm build cache (best effort)" step entirely, along with its :buildcache / type=registry references, the 20-minute timeout, the continue-on-error, and the tag-build skip - all MAPPS-131 / MAPPS-121 mitigations for a stall that no longer happens.
Multi-arch build (amd64 + arm64), the docker-container buildx driver, the public-registry mirror, version stamping, and CARGO_BUILD_JOBS are unchanged. The docker-container driver is already required for type=gha export too, so no driver change.

Net: +21 / -61 lines.

Verification

just pre-commit passes (cargo fmt/clippy/check + 189 tests green). Workflow YAML validated; no remaining type=registry / :buildcache references; no em-dashes. The pattern is proven on vervain-server VS-53: a warm build logged importing cache manifest from gha, CACHED cargo layers, and exporting to GitHub Actions Cache in ~2s with no 499/stall.

Prerequisite: the runner must have cache.enabled: true (already required for the Check workflow's cache). If it were off, the type=gha export would no-op silently under ignore-error=true; read freshness from the build log's importing/exporting cache lines rather than the exit code.

#MAPPS-326

Switches the `mokosh-www` OCI build cache from the registry to `act_runner`'s built-in `type=gha` cache server, and removes the MAPPS-131 "Warm build cache" workaround that only existed to survive the registry stall. ## Why `build-oci-image.yml` cached build layers via `type=registry` against a `:buildcache` tag. The `dev.a8n.run` registry cache-export PUT stalls indefinitely with no error (MAPPS-131 hung the job ~3h until the runner max-runtime killed it, even after `--push` had finished). To work around it, `cache-to` was pulled out of the main build into a trailing best-effort "Warm build cache" step guarded by `timeout-minutes: 20` + `continue-on-error: true` and skipped on tag builds (MAPPS-121). `type=gha` points buildx at the on-LAN Actions cache server instead (the same `cache.enabled` server the Check workflow already uses), matching the governance standard set in GOV-20 / vervain-server VS-53. The export is fast and does not stall, so the entire workaround collapses back into the main build. ## Changes - Add an "Export Actions runtime env for buildx gha cache" step (`crazy-max/ghaction-github-runtime@v3`) before the build. A raw `docker buildx build` (unlike `docker/build-push-action`) does not auto-inject the gha cache env, and `ACTIONS_RUNTIME_TOKEN` is masked from `run:` steps, so this re-exports `ACTIONS_CACHE_URL` / `ACTIONS_RUNTIME_TOKEN` into `GITHUB_ENV`. - "Build and push mokosh-www image" now uses `cache-from type=gha` and `cache-to type=gha,mode=max,ignore-error=true` inline. - Remove the "Warm build cache (best effort)" step entirely, along with its `:buildcache` / `type=registry` references, the 20-minute timeout, the `continue-on-error`, and the tag-build skip - all MAPPS-131 / MAPPS-121 mitigations for a stall that no longer happens. - Multi-arch build (amd64 + arm64), the `docker-container` buildx driver, the public-registry mirror, version stamping, and `CARGO_BUILD_JOBS` are unchanged. The `docker-container` driver is already required for `type=gha` export too, so no driver change. Net: +21 / -61 lines. ## Verification `just pre-commit` passes (cargo fmt/clippy/check + 189 tests green). Workflow YAML validated; no remaining `type=registry` / `:buildcache` references; no em-dashes. The pattern is proven on vervain-server VS-53: a warm build logged `importing cache manifest from gha`, `CACHED` cargo layers, and `exporting to GitHub Actions Cache` in ~2s with no 499/stall. Prerequisite: the runner must have `cache.enabled: true` (already required for the Check workflow's cache). If it were off, the `type=gha` export would no-op silently under `ignore-error=true`; read freshness from the build log's `importing/exporting cache` lines rather than the exit code. #MAPPS-326

David added 1 commit

2026-06-26 02:49:36 +02:00

ci(oci): switch build cache from registry to runner gha cache

Check / fmt + clippy + tests (pull_request) Successful in 15m23s

Details

Create release / Create release from merged PR (pull_request) Has been skipped

Details

0665fb49af

The build-oci-image workflow cached mokosh-www build layers via the registry. Because the dev.a8n.run registry cache-export PUT stalls indefinitely with no error (MAPPS-131 hung the job ~3h until max-runtime killed it), cache-to was split out of the main build into a trailing best-effort "Warm build cache" step guarded by timeout-minutes + continue-on-error and skipped on tag builds (MAPPS-121).

Point the cache at act_runner's built-in Actions cache server (type=gha) instead, matching the governance standard (GOV-20, vervain-server VS-53). cache-from and cache-to both use type=gha (mode=max, ignore-error=true) inline in the main build, a crazy-max/ghaction-github-runtime step exports ACTIONS_CACHE_URL / ACTIONS_RUNTIME_TOKEN so the raw docker buildx build can reach the cache server, and the whole "Warm build cache" workaround is removed: the on-LAN gha export is fast and does not stall, so the decoupling, the 20-minute timeout, the continue-on-error, and the tag-build skip are no longer needed. Multi-arch build, public mirror, version stamping, and CARGO_BUILD_JOBS are unchanged.

#MAPPS-326