Repository navigation
fix(docker): decouple the best-effort Bun image from the release manifest - #11724
Merged
Merged
Conversation
…fest The v3.8.50 Docker publish failed on both arches with: process "/bin/sh -c bun run --quiet build" ... cannot allocate memory Only Dockerfile.bun failed. The SUPPORTED images built fine — runner-base in 16m03 (amd64) / 14m13 (arm64), runner-web in 3m15 / 1m31 — yet none of them reached the registry, because one best-effort target sank the whole workflow. AGENTS.md is explicit that Bun is a compatibility path and NOT a supported runtime. Giving it the power to block the release inverts that: the runtime users actually run stayed unpublished so an experimental one could fail loudly. The Bun image is still built and still pushed on every run — it only stops being a release blocker: - both Bun build steps are `continue-on-error` - the digest files are only created when a digest actually exists - `create_manifest` takes an `optional` flag: an empty digest dir now warns and skips that tag instead of exiting 1. base/web stay hard-fail, so a real regression in a supported image still stops the publish. Applied to both the Docker Hub and GHCR manifest steps. One trap worth naming: the digest guard uses `if` blocks rather than `[ -n "$X" ] && touch ...`. Under `set -euo pipefail` a failing AND-list aborts the step — which is exactly the empty-digest case this is meant to handle, so the terse form would have swapped one blocker for another.
Contributor
CI Coverage Report
Coverage artifact was not available for this run. |
diegosouzapw
added a commit
that referenced
this pull request
Aug 27, 2026
Follow-up to #11724. That PR made the bun image non-blocking and taught the manifest step to skip its tags when no digest exists — but stopped one step short: the upload still carried `if-no-files-found: error`, so an absent digest (now the *expected* outcome of a skipped bun build) failed the job anyway. Run 33030348950 shows it precisely: both arches died at `Upload bun-base digests`, after the decoupling had already done its part. The blocker had simply moved from the manifest to the upload. - bun digest uploads: `if-no-files-found: ignore` - bun digest downloads: `continue-on-error`, since the artifact may not exist base/web keep `error` on both sides — a supported image producing no digest is still a real failure that must stop the publish.
diegosouzapw
added a commit
that referenced
this pull request
Aug 28, 2026
…nc-back step 2/2
The eighteen commits main carries beyond the cycle branch, and what each one
became here:
already in release/v3.8.51 by its own PR (no-op, verified by content):
b090b60 / 026e1ca deps: nanoid 3.3.18 equal, dompurify 3.4.14 newer
918fba5 .gitignore: /_tasks already anchored
5f0a394 #10026 hide health-check-excluded models — same helper, 5 call sites
c68cda7 #11075 shared passthrough providers — superseded by #11071/#11078
superseded, one piece kept:
ca23eed #10055 memoize models.dev pricing — the cycle memoizes on the
catalog cache version already; only the resetDbInstance() hook is
ported, wired to that memo
applied as-is:
8778ea7 stamp dist/BUILD_SHA before the npm provenance gate (#11721)
aa52351 decouple the Bun image from the release manifest (#11724)
925feb2 let the bun digest artifact be absent (#11740)
b65ef33 size the install-upgrade gate to a measured run
0ce2123 #11845 converge install/upgrade schemas (migration renumbered in
the next commit: 163 collides with 163_radar_feed_cache_generated_at)
b7c07ed #11855 install-upgrade gate on disk, not tmpfs
8e2fb04 #11864 drop *.nft.json from the npm tarball (413)
dea6bb8 #11877 publish npm from a hosted runner (provenance 422)
handled by the sync script that follows (CHANGELOG protocol):
b4ec780 Release v3.8.50 — squash of content this branch already carries
5458026 / c44c0a2 CHANGELOG aggregation, stats and top-25
applied separately (its own commit, ten files):
65e8115 #11088 Ollama capability routing — a 5,094-file squash from a
stale base; only the Ollama files are the change
Every cherry-pick that touched a file this branch had also changed was
resolved by hand and re-run through the tests both sides own for it.
muhamadgalihsaputra
pushed a commit
to niyatna/NiyatnaRoute
that referenced
this pull request
Sep 27, 2026
…nc-back step 2/2
The eighteen commits main carries beyond the cycle branch, and what each one
became here:
already in release/v3.8.51 by its own PR (no-op, verified by content):
7124dd3 / bae33e2 deps: nanoid 3.3.18 equal, dompurify 3.4.14 newer
ceb8e3e .gitignore: /_tasks already anchored
bf87c7d cheaper-inference#10026 hide health-check-excluded models — same helper, 5 call sites
3816ade cheaper-inference#11075 shared passthrough providers — superseded by cheaper-inference#11071/cheaper-inference#11078
superseded, one piece kept:
b735371 cheaper-inference#10055 memoize models.dev pricing — the cycle memoizes on the
catalog cache version already; only the resetDbInstance() hook is
ported, wired to that memo
applied as-is:
a93d123 stamp dist/BUILD_SHA before the npm provenance gate (cheaper-inference#11721)
dd329d7 decouple the Bun image from the release manifest (cheaper-inference#11724)
a5e649b let the bun digest artifact be absent (cheaper-inference#11740)
e9045c4 size the install-upgrade gate to a measured run
f5addae cheaper-inference#11845 converge install/upgrade schemas (migration renumbered in
the next commit: 163 collides with 163_radar_feed_cache_generated_at)
a38590e cheaper-inference#11855 install-upgrade gate on disk, not tmpfs
8588804 cheaper-inference#11864 drop *.nft.json from the npm tarball (413)
28bde09 cheaper-inference#11877 publish npm from a hosted runner (provenance 422)
handled by the sync script that follows (CHANGELOG protocol):
fc15eef Release v3.8.50 — squash of content this branch already carries
2b80128 / 4398260 CHANGELOG aggregation, stats and top-25
applied separately (its own commit, ten files):
837b36a cheaper-inference#11088 Ollama capability routing — a 5,094-file squash from a
stale base; only the Ollama files are the change
Every cherry-pick that touched a file this branch had also changed was
resolved by hand and re-run through the tests both sides own for it.
muhamadgalihsaputra
pushed a commit
to niyatna/NiyatnaRoute
that referenced
this pull request
Sep 27, 2026
…fest (cheaper-inference#11724) The v3.8.50 Docker publish failed on both arches with: process "/bin/sh -c bun run --quiet build" ... cannot allocate memory Only Dockerfile.bun failed. The SUPPORTED images built fine — runner-base in 16m03 (amd64) / 14m13 (arm64), runner-web in 3m15 / 1m31 — yet none of them reached the registry, because one best-effort target sank the whole workflow. AGENTS.md is explicit that Bun is a compatibility path and NOT a supported runtime. Giving it the power to block the release inverts that: the runtime users actually run stayed unpublished so an experimental one could fail loudly. The Bun image is still built and still pushed on every run — it only stops being a release blocker: - both Bun build steps are `continue-on-error` - the digest files are only created when a digest actually exists - `create_manifest` takes an `optional` flag: an empty digest dir now warns and skips that tag instead of exiting 1. base/web stay hard-fail, so a real regression in a supported image still stops the publish. Applied to both the Docker Hub and GHCR manifest steps. One trap worth naming: the digest guard uses `if` blocks rather than `[ -n "$X" ] && touch ...`. Under `set -euo pipefail` a failing AND-list aborts the step — which is exactly the empty-digest case this is meant to handle, so the terse form would have swapped one blocker for another.
muhamadgalihsaputra
pushed a commit
to niyatna/NiyatnaRoute
that referenced
this pull request
Sep 27, 2026
…r-inference#11740) Follow-up to cheaper-inference#11724. That PR made the bun image non-blocking and taught the manifest step to skip its tags when no digest exists — but stopped one step short: the upload still carried `if-no-files-found: error`, so an absent digest (now the *expected* outcome of a skipped bun build) failed the job anyway. Run 33030348950 shows it precisely: both arches died at `Upload bun-base digests`, after the decoupling had already done its part. The blocker had simply moved from the manifest to the upload. - bun digest uploads: `if-no-files-found: ignore` - bun digest downloads: `continue-on-error`, since the artifact may not exist base/web keep `error` on both sides — a supported image producing no digest is still a real failure that must stop the publish.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
The v3.8.50 Docker publish failed on both architectures with:
Only
Dockerfile.bunfailed. The supported images built fine:runner-baserunner-webDockerfile.bun (runner-base)Yet none of them reached the registry, because one best-effort target sank the whole workflow.
AGENTS.md→ Environment is explicit that Bun is a compatibility path and NOT a supported runtime. Letting it block the release inverts that: the runtime users actually run stayed unpublished so an experimental one could fail loudly.What
The Bun image is still built and still pushed on every run — it only stops being a release blocker:
continue-on-error: truecreate_manifestgains anoptionalflag: an empty digest dir warns and skips that tag instead ofexit 1base/webstay hard-fail, so a real regression in a supported image still stops the publish. Applied to both the Docker Hub and GHCR manifest steps.One trap worth naming
The digest guard uses
ifblocks, not[ -n "$X" ] && touch .... Underset -euo pipefaila failing AND-list aborts the step — which is exactly the empty-digest case this handles, so the terse form would have swapped one blocker for another. Verified by simulating bothcreate_manifestpaths in bash: supported manifest created, Bun tag skipped, step survives.Follow-up not in scope
The Bun OOM itself is untouched and still needs a fix (or a documented decision that the image is expected to fail on hosted runners). This PR only stops it from holding the supported images hostage.