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

Merged opened this

Check · Review · Land · Live done — Landed and live in production.

Merged

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

opened this

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.ts reads the Dockerfile. It requires at least one Bun base image, and every FROM oven/bun: tag must be MAJOR.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 in test/recovery-doc.test.ts ("the doc fits two printed sides"), and the check failed. I left RECOVERY.md unchanged and put the note in the README's "Run it" section. It says to change the one FROM line, 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.

Closes #3803

commented

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.ts reads the Dockerfile. It requires at least one Bun base image, and every FROM oven/bun: tag must be MAJOR.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 in test/recovery-doc.test.ts ("the doc fits two printed sides"), and the check failed. I left RECOVERY.md unchanged and put the note in the README's "Run it" section. It says to change the one FROM line, 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

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:

  1. Make the test catch the forms it misses today: FROM --platform=... oven/bun:... and FROM ${ARG}. Only a literal FROM oven/bun line is checked, so a build-arg tag would bypass the pin.
  2. 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.
Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs