Pin zelnet to images that run on the ARM64 fleet #295

Merged

binjovi-bot merged 2 commits from fix/zelnet-arm64-images into trunk 2026-09-13 16:57:54 +00:00

Conversation 0 Commits 2 Files changed 3 +35 -12

sean commented 2026-09-13 16:38:18 +00:00

Owner

Copy link

Third and last change unblocking zelnet. Its first build after the ARM migration died in its own check stage:

exec /bin/sh: exec format error
ERROR [check-run 4/4] RUN zig build check

Every image zelnet named was an AMD64 manifest, and the fleet has no AMD64 node and no emulation since the host binfmt registration was retired on 2026-09-12.

Images. The worker moves to zig-builder:v9, the ARM64 rebuild (builder-images #353, released and verified arm64 in the registry). The publisher and the renderer move to binjovi-package-publisher:v11 and cast-render:v8, which have been AMD64+ARM64 indexes since 2026-09-10 and needed only a repin; zelnet was two and three versions behind on images that were already fixed.

Install tests. The matrix keeps its six ARM64 testers and drops the six AMD64 ones. Those install a .deb or .rpm and then run zelnet --version inside the tester, which this fleet cannot do at all; no change to the builder images affects that. functional_image follows the first remaining Debian tester.

This is a real loss of coverage and I am not hiding it: the AMD64 packages are still cross-compiled and published, they are simply no longer installed and executed by the pipeline. Restoring that needs an AMD64 node or host emulation.

Checks. The zelnet assertion pinned the matrix at exactly eight and four, the same fixed shape binjovi #1754 just relaxed; it becomes a ceiling of one-to-eight and one-to-four. A new check refuses an -amd64 pin anywhere in zelnet's images and refuses a zig-builder older than v9, so neither can come back silently. Verified red on the pre-repin bundle and green after. scripts/check passes.

Order: binjovi v0.1.725 is deployed with the matching domain rule, so this catalog is valid against the running control plane.

zdns, zerotea and rpg-demo have the same breakage and are deliberately untouched.

https://claude.ai/code/session_01XdBRc9CHgFhAxCyHbdVtt6

Third and last change unblocking zelnet. Its first build after the ARM migration died in its own check stage: ``` exec /bin/sh: exec format error ERROR [check-run 4/4] RUN zig build check ``` Every image zelnet named was an AMD64 manifest, and the fleet has no AMD64 node and no emulation since the host binfmt registration was retired on 2026-09-12. **Images.** The worker moves to `zig-builder:v9`, the ARM64 rebuild (builder-images #353, released and verified arm64 in the registry). The publisher and the renderer move to `binjovi-package-publisher:v11` and `cast-render:v8`, which have been AMD64+ARM64 indexes since 2026-09-10 and needed only a repin; zelnet was two and three versions behind on images that were already fixed. **Install tests.** The matrix keeps its six ARM64 testers and drops the six AMD64 ones. Those install a `.deb` or `.rpm` and then run `zelnet --version` inside the tester, which this fleet cannot do at all; no change to the builder images affects that. `functional_image` follows the first remaining Debian tester. This is a real loss of coverage and I am not hiding it: the AMD64 packages are still cross-compiled and published, they are simply no longer installed and executed by the pipeline. Restoring that needs an AMD64 node or host emulation. **Checks.** The zelnet assertion pinned the matrix at exactly eight and four, the same fixed shape binjovi #1754 just relaxed; it becomes a ceiling of one-to-eight and one-to-four. A new check refuses an `-amd64` pin anywhere in zelnet's images and refuses a `zig-builder` older than v9, so neither can come back silently. Verified red on the pre-repin bundle and green after. `scripts/check` passes. Order: binjovi v0.1.725 is deployed with the matching domain rule, so this catalog is valid against the running control plane. zdns, zerotea and rpg-demo have the same breakage and are deliberately untouched. https://claude.ai/code/session_01XdBRc9CHgFhAxCyHbdVtt6

sean added 1 commit 2026-09-13 16:38:18 +00:00

Pin zelnet to images that run on the ARM64 fleet ... 4a5481d3af

Every zelnet build image was an AMD64 manifest. The fleet has no AMD64
node and no emulation, so its first build after the migration died in the
check stage with an exec format error.

The worker moves to zig-builder v9, the ARM64 rebuild. The publisher and
the renderer move to v11 and v8, which have been AMD64 and ARM64 indexes
since 2026-09-10 and needed only a repin.

The install test matrix keeps its six ARM64 testers and drops the six
AMD64 ones. An AMD64 tester installs the package and then runs the binary,
which this fleet cannot do at all. The AMD64 packages are still
cross-compiled and published; they are no longer installed and executed.
The matrix assertion becomes a ceiling to match, and a new check refuses
an AMD64 pin or a zig-builder older than v9.

Claude-Session: https://claude.ai/code/session_01XdBRc9CHgFhAxCyHbdVtt6

sean added 1 commit 2026-09-13 16:57:36 +00:00

Say why zelnet pins the ARM64 half of its matrix ... 8aa875087d

The fleet has no emulation, so every image a project names must run on it.
The reason belongs in the catalog's own README, beside the rest of the
rules a project definition has to satisfy.

Claude-Session: https://claude.ai/code/session_01XdBRc9CHgFhAxCyHbdVtt6

binjovi-bot merged commit 8aa875087d into trunk 2026-09-13 16:57:54 +00:00

binjovi-bot deleted branch fix/zelnet-arm64-images 2026-09-13 16:57:55 +00:00

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

sean/binjovi-plans!295

No description provided.