feat(canvas): add /buildinfo endpoint exposing the build SHA (core#2235) #2253

Merged

hongming merged 1 commits from feat/core2235-canvas-buildinfo into main 2026-06-04 21:25:45 +00:00

Conversation 0 Commits 1 Files Changed 5

+67 -12

hongming commented 2026-06-04 20:58:58 +00:00

Owner

Copy Link

Copy Source

Closes #2235.

Problem

The platform image exposes GET /buildinfo ({git_sha}) so the fleet redeploy workflow can poll each tenant and assert it runs the merge SHA before reporting success. The Next.js canvas had a GET /api/buildinfo route, but it only read VERCEL_GIT_COMMIT_SHA — which the canvas's ECR-image Docker deploy never sets (the fleet deploys the Docker image, not via Vercel). So the served SHA always reported "dev" and canvas deploys could only be verified indirectly (CI-green gate + immutable :staging-<sha> + digest-pin), never by the served SHA.

Change

Bake the merge SHA into the canvas image at build time and surface it through the existing route.

• canvas/Dockerfile — ARG BUILD_SHA=dev -> ENV BUILD_SHA in the final runtime stage. Server-only (not NEXT_PUBLIC_) so it stays out of the client bundle. Default "dev" matches workspace-server's sentinel, so an unwired build fails the SHA comparison closed.
• canvas/src/app/api/buildinfo/route.ts — priority BUILD_SHA -> VERCEL_GIT_COMMIT_SHA -> "dev". Added export const dynamic = "force-dynamic" so the route reads BUILD_SHA from the standalone Node server's runtime env per request rather than freezing it at next build.
• .gitea/workflows/publish-canvas-image.yml — pass BUILD_SHA=${{ github.sha }} (full 40-char SHA) in build-args, mirroring how the platform image wires GIT_SHA.
• docker-compose.yml — BUILD_SHA build arg (default dev) for local compose builds.
• test — assert BUILD_SHA wins over the Vercel var, the Vercel fallback, and the dev default.

Server-vs-static

canvas/next.config.ts sets output: "standalone" — the canvas ships a Node server, so this is a server route reading a server-only env, not NEXT_PUBLIC_ (which would leak the SHA into the client bundle and freeze it into the static JS). next build confirms /api/buildinfo renders as ƒ (Dynamic) server-rendered on demand, so ENV BUILD_SHA in the final image is read at request time.

Route shape

GET /api/buildinfo -> 200 application/json

{ "git_sha": "<40-char merge sha | dev>", "git_ref": "", "vercel_env": "local" }

Fleet verification reads .git_sha, same field name as workspace-server.

Validation

• npm ci + npx tsc --noEmit — no new errors in buildinfo files (223 pre-existing tsc errors on clean main in unrelated test files; this PR adds zero).
• npx vitest run src/app/api/buildinfo — 4/4 pass.
• npm run build — compiles; /api/buildinfo is ƒ Dynamic.
• eslint clean on the route + test; publish-canvas-image.yml and docker-compose.yml parse as valid YAML.

Follow-up (flagged, not in scope)

core#2226's canvas deploy could poll this /api/buildinfo per-tenant to assert the served SHA, the same way the platform redeploy workflow polls workspace-server's /buildinfo — a small wiring follow-up.

🤖 Generated with Claude Code

Closes #2235. ## Problem The platform image exposes `GET /buildinfo` (`{git_sha}`) so the fleet redeploy workflow can poll each tenant and assert it runs the merge SHA before reporting success. The Next.js canvas had a `GET /api/buildinfo` route, but it only read `VERCEL_GIT_COMMIT_SHA` — which the canvas's **ECR-image Docker deploy never sets** (the fleet deploys the Docker image, not via Vercel). So the served SHA always reported `"dev"` and canvas deploys could only be verified indirectly (CI-green gate + immutable `:staging-<sha>` + digest-pin), never by the served SHA. ## Change Bake the merge SHA into the canvas image at build time and surface it through the existing route. - **`canvas/Dockerfile`** — `ARG BUILD_SHA=dev` -> `ENV BUILD_SHA` in the **final runtime stage**. Server-only (not `NEXT_PUBLIC_`) so it stays out of the client bundle. Default `"dev"` matches workspace-server's sentinel, so an unwired build fails the SHA comparison closed. - **`canvas/src/app/api/buildinfo/route.ts`** — priority `BUILD_SHA` -> `VERCEL_GIT_COMMIT_SHA` -> `"dev"`. Added `export const dynamic = "force-dynamic"` so the route reads `BUILD_SHA` from the standalone Node server's **runtime** env per request rather than freezing it at `next build`. - **`.gitea/workflows/publish-canvas-image.yml`** — pass `BUILD_SHA=${{ github.sha }}` (full 40-char SHA) in `build-args`, mirroring how the platform image wires `GIT_SHA`. - **`docker-compose.yml`** — `BUILD_SHA` build arg (default `dev`) for local compose builds. - **test** — assert `BUILD_SHA` wins over the Vercel var, the Vercel fallback, and the `dev` default. ## Server-vs-static `canvas/next.config.ts` sets `output: "standalone"` — the canvas ships a Node server, so this is a **server route** reading a **server-only** env, not `NEXT_PUBLIC_` (which would leak the SHA into the client bundle and freeze it into the static JS). `next build` confirms `/api/buildinfo` renders as `ƒ (Dynamic) server-rendered on demand`, so `ENV BUILD_SHA` in the final image is read at request time. ## Route shape `GET /api/buildinfo` -> `200 application/json` ```json { "git_sha": "<40-char merge sha | dev>", "git_ref": "", "vercel_env": "local" } ``` Fleet verification reads `.git_sha`, same field name as workspace-server. ## Validation - `npm ci` + `npx tsc --noEmit` — no new errors in buildinfo files (223 pre-existing tsc errors on clean `main` in unrelated test files; this PR adds zero). - `npx vitest run src/app/api/buildinfo` — 4/4 pass. - `npm run build` — compiles; `/api/buildinfo` is `ƒ Dynamic`. - `eslint` clean on the route + test; `publish-canvas-image.yml` and `docker-compose.yml` parse as valid YAML. ## Follow-up (flagged, not in scope) core#2226's canvas deploy could poll this `/api/buildinfo` per-tenant to assert the served SHA, the same way the platform redeploy workflow polls workspace-server's `/buildinfo` — a small wiring follow-up. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

hongming added 1 commit 2026-06-04 20:58:58 +00:00

feat(canvas): bake build SHA into image for /api/buildinfo (core#2235) ... a409d9032a

The canvas /api/buildinfo route existed but only read VERCEL_GIT_COMMIT_SHA,
which the fleet's ECR-image Docker deploy never sets — so the served SHA
always reported "dev" and canvas deploys could not be verified by the
served SHA the way the platform's /buildinfo is.

Bake the merge SHA into the canvas image at build time and surface it:

- canvas/Dockerfile: ARG BUILD_SHA=dev -> ENV BUILD_SHA in the final
  runtime stage (server-only, not NEXT_PUBLIC_, so it stays out of the
  client bundle). Default "dev" matches workspace-server's sentinel so an
  unwired build fails the SHA comparison closed.
- route.ts: BUILD_SHA takes priority, then VERCEL_GIT_COMMIT_SHA, then
  "dev". force-dynamic so the route reads BUILD_SHA from the standalone
  Node server's runtime env per request (confirmed via next build: the
  route renders as Dynamic / server-rendered on demand).
- publish-canvas-image.yml: pass BUILD_SHA=${{ github.sha }} (full 40-char
  SHA) so the fleet redeploy verification can match exactly.
- docker-compose.yml: BUILD_SHA build arg (default "dev") for local builds.
- test: assert BUILD_SHA wins over the Vercel var + the dev fallback.

Follow-up (flagged, not in scope): core#2226's canvas deploy could poll
this /api/buildinfo per-tenant to assert the served SHA, the same way the
platform redeploy workflow polls workspace-server's /buildinfo.

Closes #2235

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

hongming added the tier:low label 2026-06-04 21:21:13 +00:00

core-qa approved these changes 2026-06-04 21:22:12 +00:00

core-qa left a comment

Member

Copy Link

Copy Source

QA review (core#2235 canvas /buildinfo). Additive observability route. Reviewed: BUILD_SHA priority chain (BUILD_SHA→VERCEL→dev), force-dynamic ensures runtime-env read under output:standalone, tests assert BUILD_SHA wins + dev fallback, server-only var stays out of client bundle, Dockerfile/workflow/compose wiring consistent. CI green (Canvas build + Playwright E2E). Approve.

QA review (core#2235 canvas /buildinfo). Additive observability route. Reviewed: BUILD_SHA priority chain (BUILD_SHA→VERCEL→dev), force-dynamic ensures runtime-env read under output:standalone, tests assert BUILD_SHA wins + dev fallback, server-only var stays out of client bundle, Dockerfile/workflow/compose wiring consistent. CI green (Canvas build + Playwright E2E). Approve.

core-security approved these changes 2026-06-04 21:22:14 +00:00

core-security left a comment

Member

Copy Link

Copy Source

Security review (core#2235). No secret/authz surface: /api/buildinfo exposes only the build SHA (same as workspace-server /buildinfo). BUILD_SHA is non-sensitive build metadata, server-only (not NEXT_PUBLIC). No new auth paths, no user input, no injection surface. Approve.

Security review (core#2235). No secret/authz surface: /api/buildinfo exposes only the build SHA (same as workspace-server /buildinfo). BUILD_SHA is non-sensitive build metadata, server-only (not NEXT_PUBLIC). No new auth paths, no user input, no injection surface. Approve.

hongming merged commit aa9ea5f99f into main 2026-06-04 21:25:45 +00:00

Sign in to join this conversation.

Reviewers

No Reviewers

core-qa

core-security

Labels

Clear labels

area/ci

CI/CD pipeline issues

do-not-auto-merge

Opt out of autonomous merge-queue merging

kind/infrastructure

Infrastructure-related issues

merge-queue

Ready for serialized Gitea merge queue

merge-queue-hold

Temporarily hold PR in merge queue

platform/go

Go platform test issues

release-blocker

Blocks the staging→main promotion / a release

release-test

security

test-label-sre

tier:high

High risk per dev-sop §SOP-6 — ceo only, 24h cooldown

tier:low

Low risk per dev-sop §SOP-6 — engineers/managers/ceo can approve

tier:medium

Medium risk per dev-sop §SOP-6 — managers/ceo can approve

triage-test

test

wip

Work in progress — do not auto-merge

No Label tier:low

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

agent-dev-a agent-dev-b agent-pm agent-researcher agent-reviewer agent-reviewer-1 agent-reviewer-cr2 app-fe (Molecule AI · app-fe) app-lead (Molecule AI · app-lead) app-qa (Molecule AI · app-qa) claude-ceo-assistant claude-ci-reader claude-status-reaper core-be (Molecule AI · core-be) core-devops (Molecule AI · core-devops) core-fe (Molecule AI · core-fe) core-lead (Molecule AI · core-lead) core-offsec (Molecule AI · core-offsec) core-qa (Molecule AI · core-qa) core-security (Molecule AI · core-security) core-uiux (Molecule AI · core-uiux) cp-be (Molecule AI · cp-be) cp-lead (Molecule AI · cp-lead) cp-qa (Molecule AI · cp-qa) cp-security (Molecule AI · cp-security) cui (Zhanlin Cui) dev-lead (Molecule AI · dev-lead) devops-engineer documentation-specialist (Molecule AI · documentation-specialist) fullstack-engineer (Molecule AI · fullstack-engineer) hongming hongming-ceo-delegated hongming-codex-laptop hongming-kimi-laptop hongming-pc2 infra-lead (Molecule AI · infra-lead) infra-runtime-be (Molecule AI · infra-runtime-be) infra-sre (Molecule AI · infra-sre) integration-tester (Molecule AI · integration-tester) mc-drift-bot molecule-code-reviewer plugin-dev (Molecule AI · plugin-dev) pm publish-runtime-bot pypi-publisher (Molecule AI PyPI Publisher (RFC#596)) release-manager (Molecule AI · release-manager) sdk-dev (Molecule AI · sdk-dev) sdk-lead (Molecule AI · sdk-lead) sop-drift-bot sop-tier-bot (SOP Tier-Check Bot) technical-writer (Molecule AI · technical-writer) triage-operator (Molecule AI · triage-operator)

No Assignees

3 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: molecule-ai/molecule-core#2253