Repository navigation
test(dev): run the Compose dev-up cases in their own file - #2960
Conversation
dev-up.test.mjs ran its 69 cases one after another and set the checks-baseline-1 window (CI median 82 s; the other 95 files pack into about 78 s at fileConcurrency 8). The Compose stack cases (engine selection, generated configuration, key output, readiness, rendered ports) move verbatim to dev-up-compose.test.mjs; the Kubernetes Compute lifecycle, rollback and launcher cases stay, so open PRs that add Kubernetes cases still merge cleanly. runDevDown moves to the shared helper. No assertion changes.
|
🦞👀 Pull request received. I will update this pull request when review starts. ClawSweeper review completeClawSweeper finished reviewing this revision. The review result is being finalized. |
…how the row was scaled Review follow-up: the Compose file keeps the Kubernetes Compute checks that refuse before startup, and the dev-up row adds the CLI build to the Kubernetes half's share before scaling.
|
Codex review: needs maintainer review before merge. What this changesThis PR separates Compose development-startup tests from Kubernetes lifecycle tests so CI can run both files concurrently. Example: Checks and Conformance 1 executes the 69 development-startup cases.
Review scores
ProductKind: Test only · Worth it: Yes · Fix scope: Complete Merge readiness✅ Ready for maintainer review Keep this PR open with no actionable findings: the split preserves the existing test behavior and uses the established parallel CI runner. Priority: P3 Before mergeNone. FindingsNone. Agent review detailsHow this fits togetherThe CI lane manifest selects test files and required cases; the existing runner schedules isolated Node processes, which exercise development commands through disposable fixtures and report their results. flowchart TB
A[CI lane manifest] --> B[Parallel test runner]
B --> C[Compose test file]
B --> D[Kubernetes lifecycle file]
C --> E[Shared development fixtures]
D --> E
E --> F[Development CLI and scripts]
Technical reviewBest possible solution: Retain the focused split and shared cleanup helper within the existing CI scheduling system. Do we have a high-confidence way to reproduce the issue? This is a test-organization optimization; source inspection confirms the original sequential grouping, while the supplied timing comparisons were not independently rerun. Is this the best way to solve the issue? The split uses existing file-level concurrency, preserves assertions and fixture ownership, and extracts only the cleanup helper needed by both files. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning medium; reviewed against 7fa0a561df61. Provenance checked
TestingProof path: in-process harness. SecurityNone. EvidenceWhat I checked:
Likely related people:
Review metrics
LabelsLabel changes:
Label justifications:
Rating scale6/6 🦀 challenger crab · 5/6 🦞 diamond lobster · 4/6 🐚 platinum hermit · 3/6 🦐 gold shrimp · 2/6 🦪 silver shellfish · 1/6 🧂 unranked krab. Overall follows the weaker of proof and patch quality; ✨ marks media proof (a screenshot, video, or linked artifact) that directly shows the changed behavior. WorkflowClawSweeper edits this one comment on every review. Comment Reviewed October 19, 2026, 4:11 PM ET / 20:11 UTC. |
Problem
tests/integration/dev-up.test.mjsruns its 69 cases one after another and sets the Checks and Conformance 1 window: CI median 82.1 s over the 15 green main runs from 61ec422 to d331d24, while the lane's other 95 files pack into about 78 s atfileConcurrency8. The file is CPU-light and serial (the product under test spawns its fake engine, k3d and CLI processes one at a time), so the lane's last minute mostly waits on this one file.Change
Test-only, no assertion changes.
tests/integration/dev-up-compose.test.mjs(46 cases, main lines 33-766 and 1210-1299, in order): engine selection, generated configuration, key output, readiness, profile selection, the ports Compose renders, and the Kubernetes Compute checks that refuse before startup.dev-up.test.mjs. Keeping them in place means open PRs that add Kubernetes cases (fix(occdev): use Docker Desktop's bridge resolver for k3d on macOS #1557) still merge without conflicts.runDevDownmoves totests/helpers/dev-up.mjs, since both files use it.checks-baseline-1.jsonlists the new file as a parallel file with its own expected tests.file-durations.json: dev-up 58.5 s -> 25.7 s, dev-up-compose 30.9 s. These rows are the file's slowdown-normalised median (55.1 s, the method test(console): consolidate the console browser tests added since #2903 #2947 uses) scaled by each half's share of its 79.3 s of summed per-test CI medians: 44.5 s for dev-up-compose, and for dev-up 34.8 s plus 2.2 s for building its own CLI.Each case keeps its own fixture (temporary directory, fake engine and state directory), and the files share no process state, so running them side by side can't leak state between cases. Both files build the Go CLI once each.
Verification
runDevDown's move andloadYamlsitting below the header. Test counts are 46 + 23 = 69, the same as main.dev-up.test.mjs: 20/20.dev-up-compose.test.mjs: 20/20.podman composeprovider fails the realconfigcall. They fail the same way on main, so the pin counts a run as passing only when no other case fails. CI runs them.scripts/dev-up,internal/occdev/{compose,down,up,state,node_dns_k3d,cluster_create_k3d}.go. Each ran against main's single file and against the two new files.script_key_exists(the earlier Python check still refuses),script_key_mode,go_rollback_keeps_key.run-tests.mjs run checks-baseline-1, alternating)node scripts/ci/run-tests.mjs audit: no issues. Prettier and ESLint are clean on the touched files.git merge-treeagainst main and against this head gives the same conflicted files and hunk counts, so this PR adds no new conflict.Risks
dev-up.test.mjswill now conflict and must move the edit todev-up-compose.test.mjs. None of the open PRs do.