NVIDIA / NVIDIA/NemoClaw

[Epic] Restore staging Brev Launchable E2E

Open
#11,250 0 comments 0 reactions 1 assignee Claimed by @jyaunches View on GitHub
area: e2e integration: openclaw
Dominant language
TypeScript
Stars
22.5k
Forks
3.1k
Avg merge
1d 1h
Merged PRs (30d)
715

Description

## Outcome

Restore the staging Brev Launchable E2E as a viable, valuable test through independently reviewable capability slices.

The completed lane must prove that the latest staging handoff can create an owned workspace, reach remote execution, verify the expected runtime, exercise supported product behavior, and clean up reliably. Each slice must remain useful on its own and must not claim later behavior before its prerequisite is green.

## Baseline

- The existing trusted staging lane resolves the latest successful staging image handoff.
- PR #11270 restored uniquely owned workspace creation, control-plane readiness, persisted ownership, exact-ID cleanup, and confirmed absence.
- Remote execution readiness and later product assertions remain to be restored incrementally.
- Issue #9880 can be investigated, reproduced, and fixed independently of this epic. Restoring this lane enables additional staging validation; it does not block product issue work.

## Capability slices

- [ ] Remote execution readiness: prove `brev exec true` succeeds and retain bounded, redacted failure evidence.
- [ ] Runtime identity: prove boot image, NemoClaw SHA, image-repository SHA, clean checkout, and absence of runtime overrides match the handoff.
- [ ] Supported onboarding and inference: verify the staging Launchable can onboard and complete a supported inference path without exposing credentials.
- [ ] Product scenario coverage: add focused supported scenarios only after the shared readiness and identity checkpoints are green.
- [ ] Optional issue-specific staging validation: use the qualified lane for additional coverage. Investigation and fixes for product issues, including #9880, can proceed independently.

## Delivery order

1. Keep the control-plane checkpoint green.
2. Add remote execution readiness without later assertions.
3. Add runtime identity after remote execution is green.
4. Add supported onboarding and inference after identity is green.
5. Add product and issue-specific scenarios to this staging lane after it is qualified. Work on those issues can proceed independently.

## Guardrails

- Use the host-side Vitest controller and `BrevLaunchableFixture`.
- Do not create a shell product-scenario harness.
- Retain exact workspace ownership, ID-bound operations, persisted ownership, independent cleanup, and two confirmed absence observations.
- Keep each credential scoped to the workflow step that owns it.
- Do not expose credentials in argv, logs, errors, or artifacts.
- Record bounded, redacted diagnostics for infrastructure failures.
- Classify infrastructure failures separately from product behavior.
- Do not add a later assertion while an earlier capability slice is still failing.

## Definition of Done

- [ ] Workspace creation and control-plane readiness are green in a trusted run.
- [ ] Remote execution readiness is green in a trusted run.
- [ ] Runtime identity is green in a trusted run.
- [ ] Supported onboarding and inference are green in a trusted run.
- [ ] Cleanup records the exact owned workspace ID and two confirmed absence observations.
- [ ] Downstream product scenarios can consume the qualified lane without redefining its general contracts.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.