Fix Publish Docker Images: status-page and dashboard builds fail at corepack enable (pnpm 12.3.4) - #2698

Fixes: Publish Docker Images: status-page and dashboard builds fail at corepack enable (pnpm 12.3.4)

The "Publish Docker Images" workflow on main fails for two of seven images — dashboard and status-page — at the corepack enable step with Error: Cannot find module '/root/.cache/node/corepack/v1/pnpm/12.3.4/bin/pnpm.cjs'. The other five images build fine. As a result, the ghcr.io/openstatushq/openstatus-dashboard and -status-page images stop publishing, so self-hosted deployments pulling those images get stale code. Merging regenerates those two images against the same base image the four passing images already use.

What caused this

Affected: GitHub repository openstatusHQ/openstatus · severity low

What changed

• apps/dashboard/Dockerfile, apps/dashboard/dofigen.lock, apps/dashboard/.dockerignore: regenerated with Dofigen 2.8.0; base image node:24-slim digest bumped 0afb7822… → 2fe369e9…, io.dofigen.version label 2.7.0 → 2.8.0.
• apps/status-page/Dockerfile, apps/status-page/dofigen.lock, apps/status-page/.dockerignore: same regeneration.
• No source files, TS, or Deno code touched; env blocks in the generated Dockerfiles are the same keys, reordered by the generator.

Why it's safe

• The change is pure generator output: dofigen gen re-run after regeneration produced no further diff, so the committed files are exactly what Dofigen 2.8.0 emits for the existing dofigen.yml sources — no hand edits that could drift from the generator.
• The new base digest 2fe369e9… is the identical digest the server, workflows, and db-migrate images already built and pushed successfully on the same pnpm install --frozen-lockfile + pnpm turbo run build path in run 🧑‍✈️ doing 🧑‍✈️ things #454, so the corepack/pnpm behavior is proven by that passing set, not assumed.
• No application source, build logic, runtime entrypoint, or env values changed: the env blocks contain the same keys as before, only reordered by the generator, and the runtime stages keep the same non-root user and entrypoint.
• Scope is confined to the two failing images; the five passing images are untouched.

Validation

• dofigen update && dofigen gen (Dofigen v2.8.0, checksum-verified) on apps/dashboard and apps/status-page: regenerated both; digest 0afb7822… → 2fe369e9…, version 2.7.0 → 2.8.0.
• Re-ran dofigen gen on both apps: no additional diff (deterministic output).
• rg '0afb7822' across the repo: zero remaining references to the stale digest.
• pnpm verify: 37/39 tasks pass; the 2 failures (@openstatus/upstash#check, @openstatus/notification-pagerduty#check) are deno missing in the sandbox (exit 127, both run deno check), pre-existing and unrelated to this generated-file-only diff.
• not run: full docker build — Docker is not available in the sandbox; the build path is validated by the four passing images sharing the new digest.

Detection outcome

The fingerprinted signal "GitHub Actions workflow Publish Docker Images run #454 concluded failure on main" stops firing once this change is deployed. The two failing build-and-push matrix legs (dashboard, status-page) fail at corepack enable with Cannot find module '/root/.cache/node/corepack/v1/pnpm/12.3.4/bin/pnpm.cjs', produced by the stale node:24-slim digest 0afb7822… (Dofigen 2.7.0) whose corepack cannot resolve pnpm 12.3.4's ESM-only pnpm.mjs bin. Regenerating both images with Dofigen 2.8.0 pins them to digest 2fe369e9… — the same digest the server, workflows, and db-migrate legs already build on successfully — so corepack enable downloads and activates pnpm 12.3.4 and the builds complete instead of failing.

Fix chosen

Chosen: cause (removes the mechanism that produces the failure): Regenerate the two failing images with Dofigen 2.8.0 so their node:24-slim base digest (and corepack) matches the four passing images, removing the stale-digest corepack that cannot resolve pnpm 12.3.4's ESM-only bin.

Considered and not chosen:

• loosen (raises a limit, threshold, or timeout, or widens a retry): Downgrade the packageManager pin back to pnpm 11.x so the stale digest's corepack keeps working. Not chosen: The pnpm 12 bump is intentional (pnpm 12 pnpm 12 #2694) and the rest of the monorepo already moved; reverting it would undo a deliberate toolchain upgrade to accommodate a stale image.
• suppress (silences, downgrades, or reroutes the signal without changing what produces it): Add corepack enable pnpm or a manual pnpm.cjs shim in the two Dockerfiles. Not chosen: Hand-editing generated Dockerfiles would drift from the dofigen.lock and be overwritten on the next dofigen gen; the generator output already fixes the cause.

Outcome after fix

• Triggering input: a push to main (e.g. the current head a3a6d9f7) that changes packages/** or apps/dashboard/** / apps/status-page/**, so prepare selects those services for build.
• With the fix, the dashboard and status-page Dockerfiles reference FROM node@sha256:2fe369e9…, the digest the four passing legs already use.
• At corepack enable, corepack reads the packageManager: [email protected] field, downloads pnpm-12.3.4.tgz, and activates its pnpm.mjs bin — no pnpm.cjs lookup, no Cannot find module error.
• pnpm install --frozen-lockfile and pnpm turbo run build --filter=… then complete, the image builds and pushes, and the SBOM step runs, exactly as the five passing legs do today.
• Fate of the at-risk artifact: the ghcr.io/openstatushq/openstatus-dashboard and -status-page images resume publishing on every push, so self-hosted deployments no longer pull stale code. Nothing is dropped or dead-lettered; the previously failing builds simply complete.

Repository conventions present in the repository: AGENTS.md, CLAUDE.md, apps/checker/AGENTS.md, apps/dashboard/AGENTS.md, apps/server/AGENTS.md, apps/status-page/AGENTS.md, apps/web/AGENTS.md, apps/workflows/AGENTS.md, packages/services/AGENTS.md, packages/ui/AGENTS.md.

Repository lint: pnpm run lint (declared in package.json) passed over the whole repository (the declared target takes no file arguments).

Generated by Polylane.