Release checks stages

Release checks stages

OpenClaw Release Checks is the largest child workflow. It resolves the target once and validates the umbrella's shared package artifact when available. A direct or focused dispatch prepares its own release-package-under-test artifact when package or Docker-facing stages need it.

Windows-node candidate lanes

Windows-node checks run only in the candidate phase, after package preparation, not in the independent phase. The shared release planner selects them for all and windows-node. The newest stable node must pass setup, connection, and a Gateway-mediated invocation for every selected Gateway candidate, including betas. Stable failures, protocol mismatches, and skips block release. Alpha and main still run, but failures or unavailable coverage are advisory.

The release resolver selects the latest published canonical stable (vX.Y.Z or correction vX.Y.Z-N) and production alpha (vX.Y.Z-alpha.N), requires a hashed x64 Tray ZIP (or MSIX when no ZIP exists), and records the tag, source commit, asset name, and digest. Missing, unresolvable, artifact-less, or superseded alpha coverage is reported without blocking stable validation. The main lane resolves main once to a commit and never substitutes for release artifact coverage. The callee verifies downloaded bytes against these digests.

The immutable reusable workflow revision is separate from the app source revision and also pins the maintained setup/test harness. Release lanes use the published app bytes; main builds its separately checked-out source commit. The harness installs the exact candidate (including beta versions), connects the app, and invokes system.which through the real Gateway. It does not require old apps to advertise the current harness's full capability inventory.

The harness installs one local tarball inside WSL and resolves every other dependency from npm. Release-shaped candidates keep core dependencies such as @openclaw/ai unbundled because they publish together with core, so package preparation hands Windows-node a self-contained copy: it bundles each unbundled core dependency at the exact candidate version from the verified prerelease plugin registry, and passes the candidate through unchanged when there is no registry or nothing to bundle. Other lanes keep installing the unmodified release package.

Evidence names distinguish the app source kind and release tag or source SHA. No lane accepts a protocol mismatch as a passing test. Preview failures retain their raw GitHub job conclusions; Release Checks can therefore appear red while Full Release Validation passes with explicit advisory evidence. The release policy admits only the named preview jobs and main-source resolver, and only when stable E2E succeeds and the release-check verifier passes the existing trusted-tooling policy. Independently approved provider waivers retain their aggregate-log checks. Unrelated unwaived failures and whole-workflow cancellation still block. Automatic child reuse remains limited to green runs; advisory-red children run again rather than reusing red evidence.

The harness OIDC check binds the called workflow, not the caller's authority. The workflow receives caller-scoped read permissions, no inherited secrets, and runs on GitHub-hosted Windows; it does not publish releases. This is setup/connect coverage, not MXC/AppContainer containment proof.

Docker release-path chunks

The Docker release-path stage runs these chunks when live_suite_filter is empty:

All package/update rows retain their coverage across every release profile. With multiple published baselines, package-update-migrations expands into one channel-switching job and one isolated upgrade job per baseline. Every job reuses the exact candidate package and images, retains the existing weighted npm limit, and uploads a separate shard artifact. This avoids serializing all published upgrades behind one runner's npm pool without increasing per-host concurrency. package-update-core and package-update remain aggregate manual chunk names. Root-managed VPS upgrade and authenticated restart checks run in the OpenAI row. Missing required credentials still fail the job; the diagnostic pool continues so independent non-live checks also report their results. Setup failures and cancellation do not start that pool.

Expanded published-upgrade survivor and update-migration coverage runs in baseline-specific, isolated scenario jobs, with up to 32 targeted Docker jobs active per matrix. Long standalone restart/auth, plugin-update, and root-managed upgrade jobs are admitted before the scenario expansion; pinned baseline cohorts start newest first. The grouping and execution planners share the same baseline compatibility rules; package identities, fresh scenario containers, per-runner npm limits, and failure reporting remain unchanged.

Use targeted docker_lanes=<lane[,lane]> on the reusable live/E2E workflow when only one Docker lane failed. The release artifacts include per-lane rerun commands with package artifact and image reuse inputs when available.