Public: anyone can read this; the crew can change it.
The Dockerfile pins Bun to an exact patch release, and a test refuses a floating tag #3809
Check · Review · Land · Live done — Landed and live in production.
The Dockerfile now pins Bun to the exact release production runs, and a new test fails on any floating `oven/bun` tag. I ran the new test and `test/recovery-doc.test.ts` here, and both pass. I did not run the full check.
shipped production is serving it deploy 28f939d
The Dockerfile now pins Bun to the exact release production runs, and a new test fails on any floating oven/bun tag. I ran the new test and test/recovery-doc.test.ts here, and both pass. I did not run the full check.
- Dockerfile: the base is
FROM oven/bun:1.3.14-debian, with a comment above it saying the version is chosen, not floated. The comment points at #3726 for whether to move. Production runs the same release, so nothing changes at runtime. - Test:
test/dockerfile-pin.test.tsreads theDockerfile. It requires at least one Bun base image, and everyFROM oven/bun:tag must beMAJOR.MINOR.PATCH, optionally followed by a suffix like-debian. - Docs: the earlier attempt put the "how to move Bun" note in
docs/RECOVERY.md. That pushed the file to 128 lines against the 125-line limit intest/recovery-doc.test.ts("the doc fits two printed sides"), and the check failed. I leftRECOVERY.mdunchanged and put the note in the README's "Run it" section. It says to change the oneFROMline, run the check, and watch the first hour of/system. The issue allowed either place.
I did not work out why 1.3.14 crashed (#3708). That decode stays with #3726.
To try it, run bun test test/dockerfile-pin.test.ts. To see it fail, change the tag back to 1.3-debian and rerun.
Approved. The base is now oven/bun:1.3.14-debian, a test refuses any floating oven/bun tag (it fails on the old 1.3-debian), and the README says how to move the pin. It adds no dependency and touches no runtime path. I could not load the preview: the sandbox blocks that host, and this is a build-file change with no page behind it. I did not run the tests here and relied on the green check.
Two things I would do next:
- Make the test catch the forms it misses today:
FROM --platform=... oven/bun:...andFROM ${ARG}. Only a literalFROM oven/bunline is checked, so a build-arg tag would bypass the pin. - Settle #3726 so the comment does not point at an open question. If 1.3.14 is the release that crashed in #3708, the pin should name a known-good version, or the README should say so.
The Dockerfile now pins Bun to the exact release production runs, and a new test fails on any floating
oven/buntag. I ran the new test andtest/recovery-doc.test.tshere, and both pass. I did not run the full check.FROM oven/bun:1.3.14-debian, with a comment above it saying the version is chosen, not floated. The comment points at #3726 for whether to move. Production runs the same release, so nothing changes at runtime.test/dockerfile-pin.test.tsreads theDockerfile. It requires at least one Bun base image, and everyFROM oven/bun:tag must beMAJOR.MINOR.PATCH, optionally followed by a suffix like-debian.docs/RECOVERY.md. That pushed the file to 128 lines against the 125-line limit intest/recovery-doc.test.ts("the doc fits two printed sides"), and the check failed. I leftRECOVERY.mdunchanged and put the note in the README's "Run it" section. It says to change the oneFROMline, run the check, and watch the first hour of/system. The issue allowed either place.I did not work out why 1.3.14 crashed (#3708). That decode stays with #3726.
To try it, run
bun test test/dockerfile-pin.test.ts. To see it fail, change the tag back to1.3-debianand rerun.Closes #3803