7 Commits

Author	SHA1	Message	Date
Anso	f23b7e1bac	feat: ordered multi-file Compose for Git sources (#1380) ... * feat: ordered multi-file Compose for Git sources Extend Git sources to deploy an ordered list of compose files merged with docker compose -f base.yaml -f override.yaml ..., plus an optional project directory. - Pick and reorder compose files from the repository tree (drag to reorder on desktop, up/down arrows on phones); manual path entry is also supported. - The ordered set drives every stack-scoped compose command (deploy, update, start/stop/restart/down, image scans, Compose Doctor) and the container lookup, so a service or image declared only in an override is handled too. - Runtime keys off the materialized set, not the saved configuration: saving a source does not change deploy args until the pull is applied, and apply materializes from the pending snapshot rather than live config. - The project directory is passed as --project-directory, with -p <stack> pinning the Compose project so container labels stay stable. - The Mesh override is layered last; single-file sources are byte-identical to before, and existing rows keep working via the single-path fallback. Docs cover the picker, ordering, project directory, and the new troubleshooting and limitations (referenced files are not materialized; the dependency graph, drift, and networking views read the primary file). * fix: harden multi-file Git source (hash, unlink, collisions, node id) - hashContent folds ordered file CONTENTS (not paths) so a clean multi-file stack is not flagged as locally edited: create/apply hash the fetched files (repo paths) while pull hashes the on-disk files (materialized paths), which previously disagreed and showed a false "local edits detected". - Block unlinking a multi-file or project-directory Git source (409): the deploy spec lives on the source row, so removing it would silently revert deploys to root compose.yaml. Single-file sources still unlink. - Reject materialized-path collisions in the selection validator: an additional file equal to or nested under compose.yaml, an ancestor/descendant overlap between selected files, and a project directory nested under a compose file (previously a 500 at materialization). - DockerController.getContainersByStack uses the controller's node compose dir and passes its node id to the authored prefix, instead of the process default. * fix: CI failures on multi-file Git source (test crash, aria query, path barrier) - GitSourceFields no longer crashes when repoUrl/branch are falsy: the canBrowse trim() is optional-chained, so a reusable field component tolerates partial props. Fixes the apply-binding panel test, which feeds a minimal source object. - GitSourcePanel tests query the footer Remove button by its exact name, so the picker's per-file "Remove <path>" buttons no longer collide with the broad /remove/i match (the test intent, footer Remove present/absent, is unchanged). - validateCompose uses an inline resolve + startsWith barrier at the context-dir mkdir sink (CodeQL does not credit the wrapped isPathWithinBase helper), clearing the js/path-injection alert. The containment check is equivalent and contextDir is also validated upstream. * test: update Git source E2E spec for the multi-file compose picker The compose-file picker replaced the single #git-source-path input and added per-file Remove buttons, so the E2E spec drove selectors that no longer exist: - Drop the redundant compose.yaml fills (the picker defaults to compose.yaml). - Select the footer Remove button by exact name so the picker's per-file "Remove <path>" buttons no longer make the locator ambiguous. - Set a custom compose path through the picker (add via the manual input, press Enter, then remove the default compose.yaml). * test: match the footer Remove button with an exact Playwright name Playwright's getByRole name option is a substring match by default, so { name: 'Remove' } also matched the picker's "Remove <path>" buttons. Require an exact match so only the footer Remove button is selected.	2026-06-17 13:24:55 -04:00
Anso	f7f3afe05a	feat(stacks): one-click import for stray compose files (#1320) ... * feat(stacks): move discovered import candidates into place The guided import flow previewed loose and nested compose files but could not act on them, so it only told the user where to move files by hand. Add an opt-in "Move into place" action: relocate a loose-root file into its own <name>/ subfolder, or promote a nested stack directory one level up, so Sencho's filesystem discovery lists it as a stack. The file stays a plain compose file on disk; nothing is captured into a store. The move re-derives the candidate from a fresh scan and matches by location, validates the destination name and containment, resolves symlinks before the rename, and never overwrites an existing stack. Backend and frontend both gate the action on stack:create. Also fix the rescan flicker: scan results now stay on screen while a rescan runs (only the Rescan button shows progress) instead of the whole panel collapsing to a spinner, and an empty rescan surfaces a toast. * fix(stacks): make import-move destination creation atomic The loose-root branch created the destination directory with mkdir recursive after an access() existence precheck. If the destination appeared between the check and the create, recursive accepted the existing directory and the following rename could overwrite a same-named compose file inside it, so the intended conflict response never fired. Use a non-recursive mkdir so a destination that already exists raises a conflict instead of being merged into. Add a regression test that forces the precheck to miss and asserts the existing file is left intact. * fix(stacks): only offer not-yet-imported compose files in the import tab The import tab listed every compose file in the compose directory, including ones that are already stacks (a top-level subfolder with a compose file), which just duplicated the sidebar. The scan now skips those and surfaces only files that still need importing: a compose file loose at the compose-dir root, or one nested a folder too deep. Also harden the move-into-place write path that turns a stray file into a stack: a failed rename after the destination folder is created now rolls back the empty folder, so a retry is not blocked by a false "already exists" conflict, and the move switches on an exhaustive set of placements so a new one cannot silently take the wrong branch. The sidebar refreshes after a move so the imported stack appears right away, and the docs describe import as relocating a file, not capturing running containers. * fix(stacks): reject a nested import whose compose file escapes the base The move-into-place path for a nested compose file validated only the parent directory's real path, not the compose file itself. A directory that is real and inside the compose base but holds a compose file symlinked outside the base would survive the directory move and become a stack whose compose file still points outside the base, which the editor read path would then follow. The move now resolves the compose file too and refuses it unless it stays inside the resolved source directory, matching the loose-root check and the scan's preview reader. * fix(stacks): satisfy CodeQL path and log analysis in import-move The import-move write path built its destination directory from the user-provided stack name through resolveStackDir, whose containment barrier is wrapped in a helper that static analysis does not credit, so every filesystem sink on the destination was flagged as path injection. Re-establish the resolve-against-the-safe-base plus startsWith barrier inline at the sinks, matching the read and backup paths in the same file, and route the relocated file path through the same check. The name is already restricted to an alphanumeric, hyphen, and underscore allowlist, so the containment can never actually fail; this only makes the existing safety visible to the analyzer. Also log the move route's error as a sanitized message rather than the raw error object, so a name embedded in an error message cannot forge log lines.	2026-06-05 22:35:04 -04:00
Anso	06b25262cc	feat(stacks): guided first stack import flow (#1285) ... * feat(stacks): add guided first stack import flow Add an Import mode to the Create Stack dialog and a zero-stacks empty state so a new user who already has compose files on disk can land their first stack without reading the docs first. A read-only scan of the compose directory (GET /api/stacks/import/scan) lists the compose files it finds with a dry preview of each file's services, ports, volumes, and env files. Each result is labelled by placement: already a stack, loose at the root of the compose directory, or one folder too deep, with the exact path to move misplaced files to. The scan never writes, moves, or changes any files. Manual stack creation (Empty, From Git, From Docker Run) is unchanged. * fix(stacks): read import-scan candidates via a single file handle Open the compose file once and stat plus read on the same descriptor so the size check and the read observe the same inode, instead of resolving the path twice (stat then readFile), which is a time-of-check/time-of-use race. Mirrors the existing handle-based readers in FileSystemService. * fix(stacks): confine import scan to the compose dir and refine the empty state Harden the read-only import scan: - Resolve symlinks and confirm the real target stays inside the compose directory before reading a candidate, and reject non-regular files, so a symlinked compose file or parent cannot expose a file outside the compose directory through the preview (matches resolveSafeStackPath). - Read at most the stat-reported size (bounded by the 1 MiB cap) from the open handle, so a file that grows after the size check cannot exceed the cap. - Log when the compose directory or a subdirectory cannot be read, so an access failure is not silently reported as "no compose files found". Only show the first-run "No stacks yet" prompt when no filter chip is active, so a filter that matches nothing is not mistaken for an empty fleet.	2026-06-02 16:10:05 -04:00
Anso	9d8d8abcba	fix(stacks): close dialog and toast on Empty create (F-2) (#1168) ... * fix(stacks): close dialog and toast on Empty create (F-2) The Empty branch of the Create Stack dialog left no visual confirmation on a successful POST: no success toast, no busy state on the Create button, and no double-click guard. The first thing a new operator does is create a stack, so a click that looks like a no-op is the day-one impression killer. What changed - Empty handler now mirrors the Git and docker-run patterns: a creatingEmpty busy guard, Loader2 spinner on the Create button, disabled Cancel mid-flight, and a "Stack <name> created." success toast fired synchronously before the editor-load handoff. - The Empty panel is wrapped in a form so the Enter key submits the same path as clicking Create. - Mapped 403 to a clearer permission message; fall back to the backend's error string for other non-OK statuses. - Capture the active node id at handler entry and pass it through onStackCreated. The parent compares against the live node ref and skips the editor load if the user switched nodes mid-create, with an info toast pointing at the prior node. - Tightened the create-a-new-stack E2E (no more silent .catch on the dialog-close assertion, asserts the toast, no longer relies on a page reload to see the sidebar entry) and added a regression spec that the busy guard collapses double-clicks into a single POST. * fix(stacks): close double-click race in create handler (F-2) The setState-based busy guard could race a second click that landed before React committed the disabled state, so two POSTs got dispatched when a user double-clicked Create. The new useRef-based check is read and written synchronously inside the handler so a re-entrant invocation bails before issuing a second fetch. The accompanying E2E (`create dialog: double-clicking Create fires only one POST`) was also hanging to its 30s test timeout: the second click's locator resolution could outlive the dialog when the first POST resolved quickly, so Playwright waited for `[role="dialog"]` to reappear. Both clicks now fire in the same microtask via Promise.all with a 1s timeout on the second click so the locator-resolution path fails fast instead of hanging the test. * fix(stacks): keep busy guard active across modal close (F-2) Two issues from independent review. 1. Important: resetting creatingEmpty / creatingEmptyRef inside the modal close handler created an Escape/backdrop race. A user could close the dialog mid-flight (clearing both flags), reopen, click Create again, and slip past the guard before the first POST settled. The finally block already owns that lifecycle, so the close handler no longer touches either flag. 2. Nit: bring 403 messaging to parity with the Git branch. The Empty handler now reads the backend's error field first and falls back to the original hardcoded copy if it is missing, mirroring how handleCreateStackFromGit surfaces backend permission errors. * test(stacks): rebuild double-click spec around observable disabled-state (F-2) The Promise.all racing approach to "double-click fires only one POST" hung to the 30s test timeout on CI. The page snapshot at timeout confirms the product fix works correctly (dialog closed, stack created, editor navigated); the test itself was the flake. Race-based assertions on a single React-state commit boundary are inherently timing-sensitive. The rewrite turns the test inside-out: - The route handler holds POST responses for 400ms so the in-flight window is large enough to observe deterministically. - await route.continue() (instead of void fire-and-forget) closes a subtle stall pattern Playwright's docs flag under load. - After the first click the test asserts the button reaches a disabled state within the in-flight window, which proves the busy guard activated at the React-state layer. - A best-effort force-click against the now-disabled button exercises the user-mash path; the synchronous useRef guard inside the handler catches it whether or not the browser dispatches the click. - expect(postCount).toBe(1) still owns the actual regression assertion. No product code change. The synchronous creatingEmptyRef guard already landed in 61e79861.	2026-05-23 03:04:53 -04:00
Anso	24155cad66	fix(stacks): prevent right-side clipping in Create Stack modal (#1081) ... The "From Docker Run" tab's converted compose.yaml preview uses <pre whitespace-pre> inside a ScrollArea that defaulted to overflow-x: hidden. Long YAML lines (long env values, long volume paths) were silently clipped on the right with no horizontal scroll affordance, and Radix's display: table viewport child propagated the overflow back up the chain, pushing the form's ModalBody past the dialog's 576px max-width. Opt into the ScrollArea component's existing `block` prop on the YAML preview and on both tabpanel form ScrollAreas. `block` switches the viewport child to display: block; min-w-0 and renders a horizontal ScrollBar (Radix mounts it only when content actually overflows). DOM trace confirms the outer `block` is load-bearing when the inner pre is wider than the viewport. Matches the established pattern used by VulnerabilityScanSheet, ScanComparisonSheet, and SecurityHistoryView.	2026-05-17 04:13:02 -04:00
Anso	945259f048	refactor(frontend): migrate CreateStackDialog to Modal chrome system (D-4) (#908) ... * refactor(frontend): migrate CreateStackDialog to Modal chrome system (D-4) Swap raw shadcn Dialog/DialogContent/DialogHeader/DialogFooter for the Modal/ModalHeader/ModalBody/ModalFooter primitives shipped in D-1 and introduce an inline ModeRail to replace the TabsHighlight chip. The new chrome carries the cyan rail, mono kicker (STACKS · NEW), italic serif title, and contextual footer hints per mode (ALPHANUMERIC · HYPHENS, HTTPS REPOS ONLY, CONVERT FIRST / YAML READY + line-count accent). ModeRail implements the full WAI-ARIA tabs pattern: aria-selected on the active tab, aria-controls/role=tabpanel/aria-labelledby linkage to each mode panel, roving tabIndex (active=0, inactive=-1), and ArrowLeft / ArrowRight / Home / End keyboard navigation matching the contract that the prior shadcn Tabs primitive provided. Each mode also gains an explicit Cancel button alongside the existing primary action, the empty-mode primary button is now disabled until the stack name is non-empty, and the ModeRail disables itself while a Git or docker-run create is in flight. The async handlers (handleCreateStack, handleCreateStackFromGit, handleConvertDockerRun, handleCreateStackFromDockerRun) and form-reset helpers are unchanged; this PR is structural plus the segmented-control redesign called out in the migration tracker as the D-4 risk note. * test(e2e): align git-sources spec with new CreateStackDialog title D-4 renamed the dialog title from "Create New Stack" to "New stack". The shared openCreateStackDialog helper in git-sources.spec.ts was still asserting the old literal, so three tests in the "Create stack from Git" group failed at the helper's first assertion. Update the assertion to match the shipped title and refresh the two stale references in docs/features/stack-management.mdx so the docs stay in sync with the UI copy. * test(e2e): use dialog accessible name in openCreateStackDialog helper The previous helper used getByText('New stack') which matched two elements: the dialog title h2 and the sr-only description (which starts "Create a new stack: empty, ..." and contains the substring). Playwright fails with a strict mode violation. Switch to getByRole('dialog', { name: 'New stack' }), which asserts the dialog by its accessible name (provided by DialogTitle via the Radix aria-labelledby wiring). One match, more precise, and independent of any future description copy.	2026-05-04 11:17:29 -04:00
Anso	71b7a52def	refactor(frontend): extract CreateStackDialog from EditorLayout (#895) ... Continues the EditorLayout decomposition (B4-2). Pulls the inline three-tab Create Stack dialog (Empty / From Git / From Docker Run) out of EditorLayout into EditorLayout/CreateStackDialog.tsx. Parent now owns only the open boolean and a domain callback pair; all 14 form-state vars and 6 handlers move into the child. The slot renders a thin trigger button plus the new dialog. Metrics: - EditorLayout.tsx: 3,266 -> 2,843 LOC - new CreateStackDialog.tsx: 463 LOC (under the 500 ceiling) - useState count in EditorLayout: 81 -> 66	2026-05-03 12:54:37 -04:00