test(e2e): restore staging Launchable checkpoint - #11270
Conversation
Signed-off-by: Julie Yaunches <jyaunches@nvidia.com>
Signed-off-by: Julie Yaunches <jyaunches@nvidia.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 12 included reviews per hour; 11 remain after this review. 📝 WalkthroughWalkthroughThe staging E2E test now performs a Launchable control-plane checkpoint. The workflow uses staging-specific paths and evidence names. Assertion budgets, workspace assertions, and mock parity mappings were updated. ChangesStaging Launchable control-plane flow
Priority: ⬇️ Low Estimated code review effort: 3 (Moderate) | ~20 minutes Merge Risk: ⚪ Minimal · up to This replaces the prior staging scenario with a Launchable control-plane checkpoint that creates, records, and deletes a staging workspace. No concrete current-head merge-blocking risk remains. Suggested reviewers: Sequence Diagram(s)sequenceDiagram
participant LiveTest
participant StagingHandoff
participant StagingWorkspace
participant CheckpointArtifact
LiveTest->>StagingHandoff: Resolve staging handoff
LiveTest->>StagingWorkspace: Create workspace and register cleanup
LiveTest->>CheckpointArtifact: Write identity data
LiveTest->>LiveTest: Mark checkpoint passed
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Signed-off-by: Julie Yaunches <jyaunches@nvidia.com>
Code Coverage OverviewLanguages: TypeScript TypeScript / code-coverage/pluginThe overall line coverage in commit 0a6d0dd in the TypeScript / code-coverage/cliThe overall line coverage in commit 0a6d0dd in the Show a line coverage summary of the most impacted files.
Updated |
Signed-off-by: Julie Yaunches <jyaunches@nvidia.com>
Signed-off-by: Julie Yaunches <jyaunches@nvidia.com>
…le-control-plane-checkpoint
|
PR Review Advisor finished for commit |
<!-- markdownlint-disable MD041 --> ## Outcome The general staging Launchable E2E now succeeds only after `brev exec <owned-workspace-id> true` proves remote execution readiness. Failed probes remain bounded and retain only the final bounded, redacted diagnostic, while the existing control-plane checkpoint and confirmed cleanup remain intact. ## Reason The control-plane checkpoint merged in PR #11270 proves workspace creation but does not prove that Brev can execute a remote command. This is the first deferred capability slice in epic #11250. ### Related issues Part of #11250 ## Changes - Add a distinct remote execution readiness phase after workspace creation and before the retained control-plane checkpoint. - Reuse `BrevLaunchableFixture.waitForExec` and its exact-owned-ID, bounded retry, redaction, and diagnostic contracts. - Add fast evidence that readiness succeeds after two failed probes and uses only the owned workspace ID. - Align workflow and artifact names with remote execution readiness and record the retry policy. - Keep runtime identity, onboarding, inference credentials, OpenClaw execution, and issue #9880 classification deferred. ## Verification - `npx vitest run --project e2e-support test/e2e/support/brev-launchable-fixture.test.ts` — 29 tests passed. - `npm run test:changed` — 45 integration tests and 29 E2E-support tests passed. - `npm run test:e2e-phases:check` — 134 tests across 88 files passed semantic phase validation. - `npm run test:projects:check` — 2,632 candidates have exact Vitest project membership. - `npm run e2e:assertions:check` — assertion ratchet passed with 1,800 direct live assertions. - `npm run checks:repository` — repository checks passed. - `actionlint .github/workflows/staging-launchable-full.yaml` — passed. - `node --experimental-strip-types --no-warnings scripts/checks/e2e-mock-parity.mts --base origin/main --head HEAD` — mock/live parity passed. - Normal commit and push hooks passed after local build prerequisites were restored. - The diff contains no secrets, API keys, or credentials. ## Review notes This changes a credentialed, billable remote-execution workflow. Brev credentials remain confined to the workflow-specific `HOME`, command probes persist no raw attempt artifacts, diagnostics are bounded and redacted before persistence or error reporting, operations remain bound to the persisted owned ID, and cleanup still requires two confirmed absence observations. --- Signed-off-by: Julie Yaunches <jyaunches@nvidia.com> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **New Features** - Added validation that remote execution becomes ready after workspace creation. - Added retry handling for temporary execution-readiness probe failures. - **Bug Fixes** - Improved staging verification timing and readiness checks. - Updated monitoring and evidence labeling to reflect remote execution readiness. - **Documentation** - Documented retry timing, conditions, safety guarantees, and diagnostic evidence. - **Tests** - Added coverage for readiness after temporary probe failures. - Added readiness evidence and classification checks for staging end-to-end runs. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Signed-off-by: Julie Yaunches <jyaunches@nvidia.com>
Summary
Restores the general staging Brev Launchable workflow as a host-side Vitest control-plane checkpoint. The trusted lane resolves the latest staging handoff, creates a uniquely owned workspace, records its control-plane identity, and requires ID-bound deletion with confirmed absence.
The existing live-test path is retained to carry its assertion budget without increasing the live E2E inventory. The workflow, target ID, title, artifacts, and behavior are general staging Launchable coverage and no longer run the issue #9880 product scenario.
Changes
Verification
Signed-off-by: Julie Yaunches jyaunches@nvidia.com
Summary by CodeRabbit
Tests
Chores