docker: compose file list is single-sourced by prose only — mod.ts, actions.ts and the page header can diverge again #50
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Follow-up from the approving review on #48 (non-blocking items 1 and 2).
Two reads of the answering container's
configFilesare guarded only by a comment:packages/modules/docker/backend/mod.ts:607andpackages/modules/docker/backend/actions.ts:511. Reverting either tostack.containers[0]keeps the whole suite green (494 passed) — the page-seam test exercisescomposeProject→wantedEnvFilesdirectly, notcollectStackFiles, so it cannot see these lines. Contrast with the env-file seam, which a type refuses (TS2345).On top of that,
packages/shell/src/pages/StackDetailPage.svelte:132is a third read of the same label offcontainers[0]raw:subtitle={data.stack.containers[0]?.configFiles ?? ""}. With a one-off as the newest container the page header namescompose.yaml,/tmp/debug.yamlwhile the file list below it — correctly the answering container's — lists onlycompose.yaml.Suggested fix from the review: a
projectComposeFiles(stack) = splitLabel(answeringContainer(stack)?.configFiles ?? "")incompose_update.ts, used by both backend call sites (and feeding the page), so one test covers all readers and nothing spellscontainers[0]or a raw split any more.Source: #48 (comment) (inline comments 1028, and follow-up 2 in the review body).