Build production from the pinned Bun 1.4.0 Dockerfile and check it in CI (#89) #41

Merged

backmeupplz merged 2 commits from 89-pin-deploy-bun into main

2026-10-12 19:00:08 +00:00

backmeupplz commented

2026-10-12 18:49:36 +00:00

(Migrated from github.com)

Board ticket: https://agentboard.icefish-betta.ts.net/#89

Problem

The Easypanel service bots/jev-antispam-bot builds with Nixpacks 1.41.0, which installs Bun 1.3.0 from nixpkgs. CI pins Bun 1.4.0. Bun 1.3 cannot read bun.lock (lockfileVersion 2), so it prints "Ignoring lockfile" and production installs dependency versions that CI never tested. Test code that is valid on 1.4 can also break the deploy-time bun run check; that is what broke the 9cefa2d deploy (#88, PR #40).

Change

Dockerfile is now the production build, on oven/bun:1.4.0-slim (Debian/glibc, close to the current Ubuntu Nixpacks runtime; it includes the openssl the TLS test needs).
- The check stage runs bun install --frozen-lockfile and bun run check on the same Bun that runs the bot. This keeps the existing deploy-time gate. The runtime stage copies a marker from check, so BuildKit cannot skip that stage.
- The runtime stage runs bun install --frozen-lockfile --production and then copies src and migrations (as before) plus scripts/. The old Nixpacks image contained the whole repo, and the documented in-container release proof bun scripts/audit-report.ts check needs scripts/.
CI defines a single BUN_VERSION: 1.4.0 env, which setup-bun uses. A new deploy-image job fails if any Dockerfile FROM line differs from oven/bun:${BUN_VERSION}-slim, then builds the production image (running the check stage).
README and docs/telegram-preview-tls.md are updated.

Rollout (after merge)

Switch the Easypanel service's build type from Nixpacks to Dockerfile (Dockerfile). Source, env, deploy settings and mounts stay unchanged, and deploy.command stays null so the image CMD (bun run src/index.ts, same as bun start) applies. Then deploy, and verify that the action reaches done, the build log shows bun install v1.4.0 with no "Ignoring lockfile", and the running commit matches.

Tests

Local docker build (linux/arm64): bun install v1.4.0, frozen lockfile honoured, check stage 495 pass / 0 fail (DB/live tests skip as in the old deploy build). The image starts and fails fast only on missing runtime config, as expected without env.
Tested the CI pin check locally: it passes with 1.4.0 and fails when the version is changed to 1.3.0.

Board ticket: https://agentboard.icefish-betta.ts.net/#89 ## Problem The Easypanel service `bots/jev-antispam-bot` builds with Nixpacks 1.41.0, which installs **Bun 1.3.0** from nixpkgs. CI pins **Bun 1.4.0**. Bun 1.3 cannot read `bun.lock` (lockfileVersion 2), so it prints "Ignoring lockfile" and production installs dependency versions that CI never tested. Test code that is valid on 1.4 can also break the deploy-time `bun run check`; that is what broke the 9cefa2d deploy (#88, PR #40). ## Change - **Dockerfile** is now the production build, on `oven/bun:1.4.0-slim` (Debian/glibc, close to the current Ubuntu Nixpacks runtime; it includes the `openssl` the TLS test needs). - The `check` stage runs `bun install --frozen-lockfile` and `bun run check` on the same Bun that runs the bot. This keeps the existing deploy-time gate. The runtime stage copies a marker from `check`, so BuildKit cannot skip that stage. - The runtime stage runs `bun install --frozen-lockfile --production` and then copies `src` and `migrations` (as before) plus `scripts/`. The old Nixpacks image contained the whole repo, and the documented in-container release proof `bun scripts/audit-report.ts check` needs `scripts/`. - **CI** defines a single `BUN_VERSION: 1.4.0` env, which `setup-bun` uses. A new `deploy-image` job fails if any Dockerfile `FROM` line differs from `oven/bun:${BUN_VERSION}-slim`, then builds the production image (running the check stage). - README and docs/telegram-preview-tls.md are updated. ## Rollout (after merge) Switch the Easypanel service's build type from Nixpacks to Dockerfile (`Dockerfile`). Source, env, deploy settings and mounts stay unchanged, and `deploy.command` stays null so the image CMD (`bun run src/index.ts`, same as `bun start`) applies. Then deploy, and verify that the action reaches `done`, the build log shows `bun install v1.4.0` with no "Ignoring lockfile", and the running commit matches. ## Tests - Local `docker build` (linux/arm64): `bun install v1.4.0`, frozen lockfile honoured, check stage 495 pass / 0 fail (DB/live tests skip as in the old deploy build). The image starts and fails fast only on missing runtime config, as expected without env. - Tested the CI pin check locally: it passes with 1.4.0 and fails when the version is changed to 1.3.0.