Walkthrough

This PR integrates a new installer integration CI job into both main and PR workflows. It defines a composite action for running installer-focused Vitest tests, wires it as a required dependency to the checks job in both workflows, and removes a duplicate self-hosted unit test job. PR workflow logic conditionally uses a trusted pre-approved action or falls back to direct setup. All wiring is validated by expanded contract tests.

Changes

Installer Integration CI Job Integration

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• NVIDIA/NemoClaw#4991: Both PRs extend trusted CI action handling in PR workflows—the main PR adds the installer-integration action to the trusted sparse-checkout allowlist and tests it, while the retrieved PR establishes the base framework for trusted action checkout and contract testing.
• NVIDIA/NemoClaw#4887: Both PRs modify workflow contract tests and the checks job's dependency/success wiring, though this PR specifically adds and tests the new installer-integration job integration.

Suggested labels

CI/CD, area: ci, chore

Suggested reviewers

• jyaunches

Poem

🐰 A fresh job springs to test the installer's way,
With trusted actions shining in the light of day,
Sparse checkouts guide each step with care,
While tests ensure the wiring's solid everywhere! ✨

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

E2E Recommendation Advisor

Base: origin/main
Head: HEAD
Confidence: high

Required E2E

• None. No product E2E is recommended. This PR is limited to CI workflow plumbing, a new composite action for existing installer-integration Vitest coverage, and workflow contract tests. It does not modify installer scripts, onboarding/runtime source, sandbox lifecycle logic, credentials handling, network policy, inference routing, deployment assets, or user-flow scenario definitions. Existing PR CI and the updated workflow-contract tests are the right validation surface; running product E2E would not materially exercise the changed logic.

Optional E2E

• None.

New E2E recommendations

• None.

E2E Scenario Advisor

Base: origin/main
Head: HEAD
Confidence: high

Required scenario E2E

• None. No scenario E2E is recommended: this PR changes CI workflow wiring, a CI installer-integration composite action, and PR workflow contract tests, but does not modify test/e2e-scenario runtime, scenario metadata, expected-state contracts, validation suites, suite scripts, onboarding/install helpers used by scenario E2E, or the e2e-scenarios workflows.

Optional scenario E2E

• None.

Relevant changed files

• None.

🛠️ Needs attention

• None.

🔎 Worth checking

• Source-of-truth review needed: .github/workflows/pr.yaml installer-integration bootstrap fallback: The advisor marked localized patch analysis as needs_followup.
  • Recommendation: Identify the invalid state, source boundary, source-fix constraint, regression test, and removal condition before merging the localized behavior.
  • Evidence: .github/workflows/pr.yaml detects .trusted-ci-actions/.github/actions/ci-installer-integration/action.yaml and runs inline bootstrap setup/install/build/test steps when unavailable.
• Installer bootstrap fallback still needs a removal and steady-state validation plan (.github/workflows/pr.yaml:127): The PR workflow normally runs composite CI actions from the base SHA checkout so pull_request jobs do not execute PR-defined CI action logic. The new installer-integration job preserves that boundary when the base checkout contains the new action, but falls back to inline setup/install/build/test commands when the action is missing. That bootstrap path is reasonable for introducing a new trusted action and remains read-only/no-secret with pinned setup-node and --ignore-scripts installs, but it is still a localized exception to the trusted-code boundary if retained indefinitely.
  • Recommendation: Document the intended removal condition directly in the workflow or a tracked follow-up, and add or identify validation for both states: base action absent takes only the bootstrap path and aggregate checks accept success; base action present takes only the base-trusted composite action path and skips bootstrap steps. Once the composite action exists on main, prefer removing the bootstrap branch.
  • Evidence: .github/workflows/pr.yaml checks out .github/actions/ci-installer-integration from github.event.pull_request.base.sha, probes .trusted-ci-actions/.github/actions/ci-installer-integration/action.yaml, then either uses ./.trusted-ci-actions/.github/actions/ci-installer-integration or runs inline setup-node, npm install --ignore-scripts, build, and CI=true npx vitest run --project installer-integration. test/pr-workflow-contract.test.ts asserts this YAML shape but does not simulate base-action-missing and base-action-present runtime states or define when the fallback is removed.

🌱 Nice ideas

• None.

• **Runtime validation** — Validate a pull_request workflow run where the base SHA lacks .github/actions/ci-installer-integration/action.yaml takes only the installer bootstrap path and the aggregate checks job accepts installer-integration success.. The changed behavior is GitHub Actions control flow and Vitest project selection. Static contract tests are useful, but they do not execute the workflow under the two trusted-action availability states or prove the removed self-hosted full Vitest job leaves equivalent PR coverage.
• **Runtime validation** — Validate a pull_request workflow run where the base SHA contains .github/actions/ci-installer-integration/action.yaml takes only the base-trusted composite action path and skips bootstrap install/build/test steps.. The changed behavior is GitHub Actions control flow and Vitest project selection. Static contract tests are useful, but they do not execute the workflow under the two trusted-action availability states or prove the removed self-hosted full Vitest job leaves equivalent PR coverage.
• **Runtime validation** — Validate CI=true npx vitest run --project installer-integration in regular PR CI includes test/install-preflight.test.ts and test/install-openshell-version-check.test.ts.. The changed behavior is GitHub Actions control flow and Vitest project selection. Static contract tests are useful, but they do not execute the workflow under the two trusted-action availability states or prove the removed self-hosted full Vitest job leaves equivalent PR coverage.
• **Runtime validation** — Validate the PR CLI shard command still executes test/e2e-scenario/framework-tests/**/*.test.ts after removing the self-hosted full Vitest job.. The changed behavior is GitHub Actions control flow and Vitest project selection. Static contract tests are useful, but they do not execute the workflow under the two trusted-action availability states or prove the removed self-hosted full Vitest job leaves equivalent PR coverage.
• **Runtime validation** — Validate the main workflow installer-integration job builds CLI and plugin artifacts before running installer integration tests.. The changed behavior is GitHub Actions control flow and Vitest project selection. Static contract tests are useful, but they do not execute the workflow under the two trusted-action availability states or prove the removed self-hosted full Vitest job leaves equivalent PR coverage.
• **Acceptance clause:** Regular PR CI already runs the CLI and plugin Vitest coverage gates, so the self-hosted workflow can focus on sandbox image builds and Docker E2E validation. — add test evidence or identify existing coverage. .github/workflows/pr.yaml retains CLI shard/merge and plugin coverage jobs, adds installer-integration, and requires them in aggregate checks; .github/workflows/pr-self-hosted.yaml keeps sandbox image build, arm64 image build, and Docker E2E jobs. Static contract tests cover these relationships, but runtime validation is still advisable for the new installer bootstrap/steady-state behavior and the removed broad Vitest job.
• **Acceptance clause:** `npx prek run --all-files` passes — add test evidence or identify existing coverage. This is asserted in PR-provided text only. I did not execute commands. Static inspection shows the shared static-check action still runs a pre-push npx prek run --all-files variant with selected skips.
• **Acceptance clause:** `npm test` passes — add test evidence or identify existing coverage. This is asserted in PR-provided text only. I did not execute commands.

Current findings:

• Source-of-truth review needed: .github/workflows/pr.yaml installer-integration bootstrap fallback: The advisor marked localized patch analysis as needs_followup.
  • Recommendation: Identify the invalid state, source boundary, source-fix constraint, regression test, and removal condition before merging the localized behavior.
  • Evidence: .github/workflows/pr.yaml detects .trusted-ci-actions/.github/actions/ci-installer-integration/action.yaml and runs inline bootstrap setup/install/build/test steps when unavailable.
• Installer bootstrap fallback still needs a removal and steady-state validation plan (.github/workflows/pr.yaml:127): The PR workflow normally runs composite CI actions from the base SHA checkout so pull_request jobs do not execute PR-defined CI action logic. The new installer-integration job preserves that boundary when the base checkout contains the new action, but falls back to inline setup/install/build/test commands when the action is missing. That bootstrap path is reasonable for introducing a new trusted action and remains read-only/no-secret with pinned setup-node and --ignore-scripts installs, but it is still a localized exception to the trusted-code boundary if retained indefinitely.
  • Recommendation: Document the intended removal condition directly in the workflow or a tracked follow-up, and add or identify validation for both states: base action absent takes only the bootstrap path and aggregate checks accept success; base action present takes only the base-trusted composite action path and skips bootstrap steps. Once the composite action exists on main, prefer removing the bootstrap branch.
  • Evidence: .github/workflows/pr.yaml checks out .github/actions/ci-installer-integration from github.event.pull_request.base.sha, probes .trusted-ci-actions/.github/actions/ci-installer-integration/action.yaml, then either uses ./.trusted-ci-actions/.github/actions/ci-installer-integration or runs inline setup-node, npm install --ignore-scripts, build, and CI=true npx vitest run --project installer-integration. test/pr-workflow-contract.test.ts asserts this YAML shape but does not simulate base-action-missing and base-action-present runtime states or define when the fallback is removed.