Skip to content

ci: run the jobs in a prebuilt builder image - #332

Merged
thesprockee merged 2 commits into
mainfrom
ci/builder-image
Oct 10, 2026
Merged

thesprockee merged 2 commits into
mainfrom
ci/builder-image

Conversation

@thesprockee

Copy link
Copy Markdown
Member

What and why

build.yml, vcpkg-cache.yml and defender-scan.yml started from archlinux:base-devel and installed the toolchain on every run (~29 billed minutes for build.yml).

  • .github/builder/Dockerfile: exactly what those jobs installed (read from their steps): the pacman set (union of the three lists), the libCrypt32.a link, osslsigncode 2.14, buf 1.47.2.
  • .github/workflows/builder-image.yml: workflow_dispatch, packages: write; builds it and pushes ghcr.io/echotools/nevr-runtime-builder:<tag>, tag = first 12 hex of the Dockerfile's sha256 (42010dd4ba8e). An existing tag is not rebuilt.
  • The three workflows run in that image (packages: read, GITHUB_TOKEN credentials). tools/tests/test_builder_image.py fails if a workflow's tag is not the Dockerfile's hash.

Needs one manual dispatch before any workflow can run: gh workflow run builder-image.yml --ref ci/builder-image (or from main after merge). I did not trigger it. The package may also need its visibility/repo access set once on ghcr.io.

Caches: does a run hit them? (past-run logs)

cache evidence verdict
Buf (buf-v1.47.2-<go>) run 38028853975: Cache not found for input keys: buf-v1.47.2-go1.27.2-X:nodwarf5, then saved. Runs 37950708596 and 37943604255 hit, but only on their own PR ref. gh cache list shows 12+ identical entries, one per ref, because build.yml never runs on main. A first run on any new ref misses; only a re-push hits. Removed: buf is in the image.
vcpkg binary (vcpkg-bin2-…) runs 38028853975, 37950708596, 37943604255: exact Cache hit, archives restored from the cache entry: 38, but Restored 5 package(s) of Installing …/19; 14 x64-mingw-static ports rebuilt (protobuf 8.9 min, abseil 1.3 min, curl 50 s), ending at archives in the binary cache now: 52. Exact hit means no save, so it repeats every run. Seed run 37914950616 restored an older entry as fallback (Restored 0 package(s)) and saved 38 archives (19 unusable), 231 MB -> 547 MB. Effectively a 5/19 hit. Fixed below.
Android NDK (android-ndk-r26d-linux) runs 37934828032, 37931335863, 37928129890: Cache hit for: android-ndk-r26d-linux, Pkg.Revision = 26.3.11579264 Hits.
vcpkg android (vcpkg-android-…) same runs: Cache hit, Restored 3 package(s), archives in the binary cache: 3 Hits.

vcpkg fix, and what I could not prove

I could not reproduce the 14-archive mismatch. In a container experiment (/var/tmp/work-nevr-runtime/claude-ci/abi/), the image and a bare archlinux:base-devel with the seed's package list produced identical archive hashes for zlib and minhook on x64-mingw-static (11600b49…, 74544324…, 761a7597…, b3f415de…), and the logged toolchain versions are identical across runs 37943604255 and 38028853975. So the cause is not the package set, the libCrypt32 link or the logged versions. It remains unproven; the likeliest candidate is something unlogged that changed between the seed (10-09 10:00 UTC) and the builds (mingw-w64-binutils is not in the "Toolchain versions" output). Changes that make a mismatch visible and non-sticky:

  • the seed and the build run in the same image;
  • the key carries a hash of gcc + binutils + headers + crt + winpthreads, so a moved toolchain is a new key instead of an exact hit that never matches;
  • the seed no longer falls back to an older entry;
  • binutils is added to the "Toolchain versions" step.

The first seeded run after merge should log Restored 19 package(s) in build.yml; if it does not, the cause is still open.

No issue: operational CI change requested by the owner's lane order, no defect tracked.

How it was verified

  • python3 -m unittest tools.tests.test_builder_image tools.tests.test_vcpkg_pin tools.tests.test_release_contract: Ran 27 tests ... OK
  • docker build of the Dockerfile locally (previous revision of the comment only): image built, 4.67 GB.
  • all six workflow YAML files parse (yaml.safe_load).
  • capped just verify on tip 0cf3b50: verify: OK (mingw-release).
  • Not run: any workflow on GitHub (the image does not exist yet), the pull/credentials path to ghcr.io, client login test (no runtime code changed).

Merge note: build.yml, vcpkg-cache.yml, defender-scan.yml and test_vcpkg_pin.py are also edited by #331 (on-demand triggers); the hunks are adjacent, expect a trivial merge.

Branch lifecycle: deleted when this PR merges or closes.

thesprockee and others added 2 commits October 10, 2026 02:37
build.yml, vcpkg-cache.yml and defender-scan.yml started from
archlinux:base-devel and installed the toolchain, osslsigncode, buf and
the libCrypt32.a link on every run. .github/builder/Dockerfile holds
exactly that; builder-image.yml (workflow_dispatch, packages: write)
builds it and pushes ghcr.io/echotools/nevr-runtime-builder:<tag>, tag =
first 12 hex of the Dockerfile's sha256. The three workflows name that
tag and test_builder_image.py fails when they disagree.

Caches: the Buf cache is dropped (the image has buf). The vcpkg key now
carries a hash of the MinGW package set, and the seed no longer restores
an older entry, which doubled the saved entry with archives that could
not match.

Co-Authored-By: nevr-work <agents@sprock.io>
Co-Authored-By: nevr-merge <agents@sprock.io>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant