Publish amd64 first, then arm64, on a builder that keeps its cache #34

Merged

jcoffey-dev merged 1 commits from ci/faster-publish into main

2026-09-24 15:45:26 +00:00

jcoffey-dev commented

2026-09-24 15:05:22 +00:00

Owner

Release builds took about 68 minutes to reach any image. Two changes:

amd64 first. publish-amd64 builds amd64 alone and pushes :<version>-amd64 and :<version>. publish-arm64 runs after it, pushes :<version>-arm64, then replaces :<version> with the two-platform index and moves :latest. :latest never points at an amd64-only image. The two release builds (LTO, one codegen unit) no longer share the machine.
A builder that keeps its cache. Both jobs use the named builder gitea-builder, whose container and state volume stay on the host. A fresh job container's buildx create re-attaches to it; I checked this on the build host with two throwaway clients, and the second got a CACHED hit. The cargo chef cook layer is keyed on the recipe, so until the dependencies change a release compiles only the workspace.

The release is created once amd64 is up. Binaries are attached once arm64 is in, and they're still extracted from the image.

Not done: reusing CI's release build. CI builds with the default features and without the image's target flags, so its binary isn't the image's. Its cache volume is also mounted by pull-request jobs, which makes it the wrong place to take a published binary from.

Checks: the YAML parses, context-check and name-check pass. The first real run is the next tag.

Release builds took about 68 minutes to reach any image. Two changes: - **amd64 first.** `publish-amd64` builds amd64 alone and pushes `:<version>-amd64` and `:<version>`. `publish-arm64` runs after it, pushes `:<version>-arm64`, then replaces `:<version>` with the two-platform index and moves `:latest`. `:latest` never points at an amd64-only image. The two release builds (LTO, one codegen unit) no longer share the machine. - **A builder that keeps its cache.** Both jobs use the named builder `gitea-builder`, whose container and state volume stay on the host. A fresh job container's `buildx create` re-attaches to it; I checked this on the build host with two throwaway clients, and the second got a `CACHED` hit. The `cargo chef cook` layer is keyed on the recipe, so until the dependencies change a release compiles only the workspace. The release is created once amd64 is up. Binaries are attached once arm64 is in, and they're still extracted from the image. Not done: reusing CI's release build. CI builds with the default features and without the image's target flags, so its binary isn't the image's. Its cache volume is also mounted by pull-request jobs, which makes it the wrong place to take a published binary from. Checks: the YAML parses, `context-check` and `name-check` pass. The first real run is the next tag.

jcoffey-dev added 1 commit 2026-09-24 15:05:22 +00:00

Publish amd64 first, then arm64, on a builder that keeps its cache

ci / fork-checks (pull_request) Successful in 49s

Details

ci / build (pull_request) Successful in 4m30s

Details

22d8ad8572

Two release builds side by side on one machine each take twice as long,
and production only needs amd64. publish-amd64 now pushes :<version> as
soon as the amd64 build is done; publish-arm64 builds arm64 afterwards,
then replaces :<version> with the two-platform index and moves :latest.

Both jobs use one named BuildKit builder whose container outlives the
job, so the dependency layer (cargo chef cook) is reused until the
dependencies change. The release is created after amd64; the binaries
are attached once arm64 is in.

jcoffey-dev merged commit 24be4a1b85 into main

2026-09-24 15:45:26 +00:00

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: inbuxa/inbuxa-server#34