refactor(qa): make Matrix sharding execution-owned (#115589)

* refactor(qa): make sharding execution-owned

* test(qa): simplify transport selection coverage
This commit is contained in:
Dallin Romney
2026-07-29 15:23:37 +08:00
committed by GitHub
parent 28e09a04d3
commit f027d7bcf6
19 changed files with 302 additions and 239 deletions
+1 -1
View File
@@ -279,7 +279,7 @@ A legacy fallback correction tag may reuse base-package evidence only when the c
Manually dispatch `Windows Node Release` only for recovery, and always pass an exact tag, never `latest`, plus the explicit `expected_installer_digests` JSON map from the approved source release. Website download links should target exact OpenClaw release asset URLs for the current stable release, or `releases/latest/download/...` only after verifying GitHub's latest redirect points at that same release; do not link only to the companion repo release page.
- Release checks now run in a separate manual workflow: `OpenClaw Release Checks`. It also runs the QA Lab mock parity lane plus the Matrix catalog and Telegram QA lane before release approval. The live lanes use the `qa-live-shared` environment; Telegram also uses Convex CI credential leases. The `QA-Lab - All Lanes` workflow derives Matrix membership from scenario channel eligibility and fans it across deterministic balanced shards to keep proof within per-job timeouts; there is no separate Matrix selector input.
- Release checks now run in a separate manual workflow: `OpenClaw Release Checks`. It also runs the QA Lab mock parity lane plus the Matrix catalog and Telegram QA lane before release approval. The live lanes use the `qa-live-shared` environment; Telegram also uses Convex CI credential leases.
- Cross-OS install and upgrade runtime validation is part of public `OpenClaw Release Checks` and `Full Release Validation`, which call the reusable workflow `.github/workflows/openclaw-cross-os-release-checks-reusable.yml` directly. This split is intentional: keep the real npm release path short, deterministic, and artifact-focused, while slower live checks stay in their own lane so they do not stall or block publish.
- Secret-bearing release checks should be dispatched through `Full Release Validation` or from the `main`/release workflow ref so workflow logic and secrets stay controlled.
- `OpenClaw Release Checks` accepts a branch, tag, or full commit SHA as long as the resolved commit is reachable from an OpenClaw branch or release tag.