chore: drop amd64 image build, ship arm64 only #58

Merged
gofix merged 1 commit from chore/drop-amd64-build into master 2026-05-03 16:55:02 +00:00
Owner

Closes #53.

Why

The self-hosted Forgejo runner host has 4.8 GiB RAM shared with several other containers, leaving ~200-300 MiB free at build time. After two rounds of memory mitigation in the Dockerfile (#56 jobs=1 + codegen-units=256, #57 opt-level=2) the amd64 Kaniko build still OOM-killed rustc during the release link step, and Forgejo's task log gets wiped on runner death so we couldn't even read what was failing.

The only production target for this relay is rly.best, which is arm64. The pragmatic call is to drop the amd64 image build path; anyone needing amd64 can build from source.

Changes

Workflow (.forgejo/workflows/container-image.yml):

  • Drop the build matrix; one job, runs-on [docker, arm64].
  • Drop the multi-arch publish job. Build job now pushes :<image_tag> and :latest directly as the arm64 manifest, no crane index append step.

Dockerfile:

  • Remove the amd64 cross-toolchain (gcc-x86-64-linux-gnu, libc6-dev-amd64-cross, linux-libc-dev-amd64-cross).
  • Collapse the case "$TARGETARCH" switch to the arm64 path.
  • Revert the OOM mitigations from #56 / #57. arm64 builds fine at default release settings.
  • Drop the diagnostics block (was added to surface amd64 failures; not needed for release builds).

README: note linux/arm64 only and point amd64 users at cargo build --release from source.

Validation

  • cargo fmt --check clean
  • cargo test --locked 86 passed, 3 ignored
  • cargo clippy --locked --all-targets -- -D warnings clean
  • Workflow YAML parses

Follow-up

After merge:

  1. Delete the v0.0.0-debug-amd64-1 and v0.0.0-debug-amd64-2 tags and any leftover Forgejo Releases.
  2. Re-cut v2.1.8+rs.1 (currently in draft) — the arm64 build alone is enough now.
Closes #53. ## Why The self-hosted Forgejo runner host has 4.8 GiB RAM shared with several other containers, leaving ~200-300 MiB free at build time. After two rounds of memory mitigation in the Dockerfile (#56 jobs=1 + codegen-units=256, #57 opt-level=2) the amd64 Kaniko build still OOM-killed rustc during the release link step, and Forgejo's task log gets wiped on runner death so we couldn't even read what was failing. The only production target for this relay is rly.best, which is arm64. The pragmatic call is to drop the amd64 image build path; anyone needing amd64 can build from source. ## Changes **Workflow** (`.forgejo/workflows/container-image.yml`): - Drop the build matrix; one job, runs-on `[docker, arm64]`. - Drop the multi-arch publish job. Build job now pushes `:<image_tag>` and `:latest` directly as the arm64 manifest, no `crane index append` step. **Dockerfile**: - Remove the amd64 cross-toolchain (`gcc-x86-64-linux-gnu`, `libc6-dev-amd64-cross`, `linux-libc-dev-amd64-cross`). - Collapse the `case "$TARGETARCH"` switch to the arm64 path. - Revert the OOM mitigations from #56 / #57. arm64 builds fine at default release settings. - Drop the diagnostics block (was added to surface amd64 failures; not needed for release builds). **README**: note `linux/arm64` only and point amd64 users at `cargo build --release` from source. ## Validation - `cargo fmt --check` clean - `cargo test --locked` 86 passed, 3 ignored - `cargo clippy --locked --all-targets -- -D warnings` clean - Workflow YAML parses ## Follow-up After merge: 1. Delete the `v0.0.0-debug-amd64-1` and `v0.0.0-debug-amd64-2` tags and any leftover Forgejo Releases. 2. Re-cut `v2.1.8+rs.1` (currently in draft) — the arm64 build alone is enough now.
chore: drop amd64 image build, ship arm64 only
All checks were successful
Rust CI / Format, lint, and test (pull_request) Successful in 1m52s
1c600686c5
The self-hosted Forgejo runner kept OOM-killing rustc during the
release link step on the amd64 matrix arm (#53). Two rounds of
mitigation (jobs=1 + codegen-units=256, then opt-level=2) reduced peak
memory but the runner still didn't have enough headroom to complete.
The runner host has 4.8 GiB RAM shared with several other containers,
leaving roughly 200-300 MiB free at build time, which is below what a
Rust release link needs even after the cuts.

The only production target — rly.best — is arm64, so the simplest
unblock is to drop the amd64 build path entirely. Anyone needing an
amd64 binary can build from source (`cargo build --release --bin
portal-relay`) on any amd64 host with a Rust toolchain.

Workflow:
- Drop the matrix; the build job runs only on the `[docker, arm64]`
  runner.
- Drop the multi-arch publish job. The build job pushes
  `:<image_tag>` and `:latest` directly to the registry as the arm64
  manifest — no `crane index append` step needed.

Dockerfile:
- Drop the amd64 cross-toolchain (`gcc-x86-64-linux-gnu`,
  `libc6-dev-amd64-cross`, `linux-libc-dev-amd64-cross`).
- Collapse the `case "$TARGETARCH"` switch to the arm64 path.
- Revert the OOM mitigations from #56 / #57 (they were workarounds for
  the dropped amd64 build; arm64 builds successfully at default
  release settings).
- Keep the diagnostics block out — release builds don't need to print
  `free -h` etc. at every run.

README: note that published images are linux/arm64 only and link to
the from-source path for amd64 users.

Closes #53.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
gofix merged commit 5022e119ef into master 2026-05-03 16:55:02 +00:00
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
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
gofix/portal-tunnel-rs!58
No description provided.