Repository navigation
feat(docker): expose DASHBOARD_ALLOW_EMBED as a build argument - #10701
Conversation
The dashboard's frame-ancestors policy is compiled into the route manifest at build time, so the only way to get an embed-enabled image was to edit the Dockerfile: Docker silently drops a --build-arg with no matching ARG, so `docker build --build-arg DASHBOARD_ALLOW_EMBED=vscode` produced the default image and no error. Declared as ARG+ENV in the builder stage, mirroring OMNIROUTE_BASE_PATH, and empty by default — the unframable default posture is unchanged. The runtime stages deliberately do not carry it: the headers are already baked, so a runtime value would advertise an effect it cannot have. Guarded by tests/unit/dockerfile-dashboard-embed-arg-10273.test.ts, verified by mutation (a bare ENV in place of the ARG fails 2 of the 3 assertions). Docs updated across the guide, ENVIRONMENT.md and .env.example. The guide also carries prettier normalization (emphasis markers, table padding) applied by lint-staged on commit. Refs #10273
Review: verified, correct as-is — no changes neededApplied the PR head ( Placement, verified against the PR head's Dockerfile:
Validation run (Windows, Node 24):
Not verifiable here: an actual Mirrored on |
|
| Failing check | What failed | Related to this PR? |
|---|---|---|
| Fast Quality Gates | 4 gates: error-helper (open-sse/handlers/imageGeneration/providers/geminiWeb.ts raw err.message), mutation-test-coverage (4 tests missing from stryker.conf.json tap.testFiles: sse-auth-exclusive-leases, aihorde-optional-api-key, responses-passthrough-openai-compatible), dead-code (knip 419 > baseline 415), open-sse-typecheck (1 new error under open-sse/) |
❌ No |
| Unit Tests fast-path 1–4/4 | tests/unit/chat-messages-validation-6402.test.ts — "Antigravity cloudcode envelope routes… gemini-3-pro-image(-preview)" |
❌ No |
| Vitest (fast-path) | tests/unit/autoCombo/provider-family-combos.test.ts — auto/glm virtual combo (flagged flaky in Trunk) |
❌ No |
| No new ESLint warnings | repo-wide npm run lint:json -- --max-warnings 0 — base red |
❌ No |
Per repo policy (AGENTS.md → Base-green check): inherited failures are not this branch's defect, are not fixed inside a feature branch, and are tracked via the base-red issue. This PR's own changes passed their targeted validation: 3/3 Dockerfile guard tests, mutation check (bare ENV → 2/3 fail), check:docs-all, ESLint on the new test, and typecheck on touched files.
…souzapw#10701) * feat(docker): expose DASHBOARD_ALLOW_EMBED as a build argument The dashboard's frame-ancestors policy is compiled into the route manifest at build time, so the only way to get an embed-enabled image was to edit the Dockerfile: Docker silently drops a --build-arg with no matching ARG, so `docker build --build-arg DASHBOARD_ALLOW_EMBED=vscode` produced the default image and no error. Declared as ARG+ENV in the builder stage, mirroring OMNIROUTE_BASE_PATH, and empty by default — the unframable default posture is unchanged. The runtime stages deliberately do not carry it: the headers are already baked, so a runtime value would advertise an effect it cannot have. Guarded by tests/unit/dockerfile-dashboard-embed-arg-10273.test.ts, verified by mutation (a bare ENV in place of the ARG fails 2 of the 3 assertions). Docs updated across the guide, ENVIRONMENT.md and .env.example. The guide also carries prettier normalization (emphasis markers, table padding) applied by lint-staged on commit. Refs diegosouzapw#10273 * chore(changelog): correct the fragment to the real PR number (diegosouzapw#10701) --------- Co-authored-by: Xiangzhe <bakryun0718@proton.me>
|
Rebased onto the post-#10698 base would make the This PR's own surface is green in isolation:
Held for review rather than auto-merged, since it's the first production-code change in this |
…souzapw#10701) * feat(docker): expose DASHBOARD_ALLOW_EMBED as a build argument The dashboard's frame-ancestors policy is compiled into the route manifest at build time, so the only way to get an embed-enabled image was to edit the Dockerfile: Docker silently drops a --build-arg with no matching ARG, so `docker build --build-arg DASHBOARD_ALLOW_EMBED=vscode` produced the default image and no error. Declared as ARG+ENV in the builder stage, mirroring OMNIROUTE_BASE_PATH, and empty by default — the unframable default posture is unchanged. The runtime stages deliberately do not carry it: the headers are already baked, so a runtime value would advertise an effect it cannot have. Guarded by tests/unit/dockerfile-dashboard-embed-arg-10273.test.ts, verified by mutation (a bare ENV in place of the ARG fails 2 of the 3 assertions). Docs updated across the guide, ENVIRONMENT.md and .env.example. The guide also carries prettier normalization (emphasis markers, table padding) applied by lint-staged on commit. Refs diegosouzapw#10273 * chore(changelog): correct the fragment to the real PR number (diegosouzapw#10701) --------- Co-authored-by: Xiangzhe <bakryun0718@proton.me>
3 participants
Why
DASHBOARD_ALLOW_EMBED=vscode(#10273) is read while the bundle is built — Next.js compilesheaders()into the route manifest — so an operator running the official image had no way toget an embed-enabled dashboard except by editing the
Dockerfile.Worse, the obvious attempt fails silently: Docker drops a
--build-argthat has no matchingARG, printing at most a warning, sodocker build --build-arg DASHBOARD_ALLOW_EMBED=vscodeproduced the default unframable image and no error. That is the same trap the Dockerfile already
documents for
OMNIROUTE_USE_TURBOPACK(L129-134: "a bare ENV shadows any same-named ARG … theescape hatch only ever worked via
-eat runtime").Surfaced while auditing the VS Code / OmniCopilot docs (#10697), which had to document Docker as
"❌ build your own".
Change
Dockerfile—ARG DASHBOARD_ALLOW_EMBED=""+ENV DASHBOARD_ALLOW_EMBED=$DASHBOARD_ALLOW_EMBEDin the builder stage, next to
OMNIROUTE_BASE_PATH, before the build stepENVIRONMENT.mdand.env.examplegain the Docker noteDefault posture unchanged. The arg is empty by default, so every existing build keeps
frame-ancestors 'none'+X-Frame-Options: DENY. The runtime stages deliberately do notcarry the variable — the headers are already baked, and a runtime value would advertise an
effect it cannot have.
Tests
tests/unit/dockerfile-dashboard-embed-arg-10273.test.ts— 3 assertions: declared as ARG (not abare ENV) and promoted from the ARG value, set before the build step, empty default, and absent
from every runtime stage.
Verified by mutation, not just by passing: replacing the
ARGwith a bareENV DASHBOARD_ALLOW_EMBED=vscodefails 2 of the 3 tests; restoring it returns 3/3.npm run check:docs-allandnpm run typecheck:coreare clean.Note on the diff size
docs/guides/VSCODE-COPILOT.mdshows more churn than the one-row change: lint-staged runsprettier on
*.md, which normalized emphasis markers (*x*→_x_) and table padding acrossthe file. Content-wise only the Docker row changed.
Not verified here
A real
docker build— no Docker daemon in this sandbox. The end-to-end proof is an image builtwith the arg serving
frame-ancestors 'self' vscode-webview:on/dashboard; the unit testguards the mechanism that makes the arg reachable at all.
Refs #10273