From f9df78e486e3fb2810af806bf1a384fa0d1e0bc3 Mon Sep 17 00:00:00 2001 From: "openclaw-docs-sync[bot]" Date: Sun, 26 Apr 2026 23:57:33 +0000 Subject: [PATCH] chore(sync): mirror docs from openclaw/openclaw@fa0729e1458063603ffacb38a526e1aad997e53f --- .openclaw-sync/source.json | 4 ++-- docs/ci.md | 19 +++++++++++++++++-- docs/reference/RELEASING.md | 18 +++++++++++++----- 3 files changed, 32 insertions(+), 9 deletions(-) diff --git a/.openclaw-sync/source.json b/.openclaw-sync/source.json index 38fc5d967..58f69adfb 100644 --- a/.openclaw-sync/source.json +++ b/.openclaw-sync/source.json @@ -1,5 +1,5 @@ { "repository": "openclaw/openclaw", - "sha": "42db865673a05bd5fcf0a276496c29e266183df0", - "syncedAt": "2026-04-26T23:50:40.202Z" + "sha": "fa0729e1458063603ffacb38a526e1aad997e53f", + "syncedAt": "2026-04-26T23:56:09.662Z" } diff --git a/docs/ci.md b/docs/ci.md index 1387fb4d3..070e744e5 100644 --- a/docs/ci.md +++ b/docs/ci.md @@ -6,7 +6,7 @@ read_when: - You are debugging failing GitHub Actions checks --- -The CI runs on every push to `main` and every pull request. It uses smart scoping to skip expensive jobs when only unrelated areas changed. +The CI runs on every push to `main` and every pull request. It uses smart scoping to skip expensive jobs when only unrelated areas changed. Manual `workflow_dispatch` runs intentionally bypass smart scoping and fan out the full CI graph for release candidates or broad validation. QA Lab has dedicated CI lanes outside the main smart-scoped workflow. The `Parity gate` workflow runs on matching PR changes and manual dispatch; it @@ -79,6 +79,19 @@ gh workflow run duplicate-after-merge.yml \ | `android` | Android unit tests for both flavors plus one debug APK build | Android-relevant changes | | `test-performance-agent` | Daily Codex slow-test optimization after trusted activity | Main CI success or manual dispatch | +Manual CI dispatches run the same job graph as normal CI but force every +scoped lane on: Linux Node shards, bundled-plugin shards, channel contracts, +`check`, `check-additional`, build smoke, docs checks, Python skills, Windows, +macOS, Android, and Control UI i18n. They do not run the PR-only +`extension-fast` lane because the full bundled-plugin shard matrix already +covers bundled-plugin tests. Manual runs use a unique concurrency group so a +release-candidate full suite is not cancelled by another push or PR run on the +same ref. + +```bash +gh workflow run ci.yml --ref release/YYYY.M.D +``` + ## Fail-fast order Jobs are ordered so cheap checks fail before expensive ones run: @@ -89,6 +102,8 @@ Jobs are ordered so cheap checks fail before expensive ones run: 4. Heavier platform and runtime lanes fan out after that: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-extensions`, `checks-node-core-test`, PR-only `extension-fast`, `checks`, `checks-windows`, `macos-node`, `macos-swift`, and `android`. Scope logic lives in `scripts/ci-changed-scope.mjs` and is covered by unit tests in `src/scripts/ci-changed-scope.test.ts`. +Manual dispatch skips changed-scope detection and makes the preflight manifest +act as if every scoped area changed. CI workflow edits validate the Node CI graph plus workflow linting, but do not force Windows, Android, or macOS native builds by themselves; those platform lanes stay scoped to platform source changes. CI routing-only edits, selected cheap core-test fixture edits, and narrow plugin contract helper/test-routing edits use a fast Node-only manifest path: preflight, security, and a single `checks-fast-core` task. That path avoids build artifacts, Node 22 compatibility, channel contracts, full core shards, bundled-plugin shards, and additional guard matrices when the changed files are limited to the routing or helper surfaces that the fast task exercises directly. Windows Node checks are scoped to Windows-specific process/path wrappers, npm/pnpm/UI runner helpers, package manager config, and the CI workflow surfaces that execute that lane; unrelated source, plugin, install-smoke, and test-only changes stay on the Linux Node lanes so they do not reserve a 16-vCPU Windows worker for coverage that is already exercised by the normal test shards. @@ -103,7 +118,7 @@ Android CI runs both `testPlayDebugUnitTest` and `testThirdPartyDebugUnitTest`, `extension-fast` is PR-only because push runs already execute the full bundled plugin shards. That keeps changed-plugin feedback for reviews without reserving an extra Blacksmith worker on `main` for coverage already present in `checks-node-extensions`. GitHub may mark superseded jobs as `cancelled` when a newer push lands on the same PR or `main` ref. Treat that as CI noise unless the newest run for the same ref is also failing. Aggregate shard checks use `!cancelled() && always()` so they still report normal shard failures but do not queue after the whole workflow has already been superseded. -The CI concurrency key is versioned (`CI-v7-*`) so a GitHub-side zombie in an old queue group cannot indefinitely block newer main runs. +The automatic CI concurrency key is versioned (`CI-v7-*`) so a GitHub-side zombie in an old queue group cannot indefinitely block newer main runs. Manual full-suite runs use `CI-manual-v1-*` and do not cancel in-progress runs. ## Runners diff --git a/docs/reference/RELEASING.md b/docs/reference/RELEASING.md index 1600117b3..ea0f9deec 100644 --- a/docs/reference/RELEASING.md +++ b/docs/reference/RELEASING.md @@ -49,6 +49,12 @@ OpenClaw has three public release lanes: - Run `pnpm build && pnpm ui:build` before `pnpm release:check` so the expected `dist/*` release artifacts and Control UI bundle exist for the pack validation step +- Run the manual `CI` workflow before release approval when you need full normal + CI coverage for the release candidate. Manual CI dispatches bypass changed + scoping and force the Linux Node shards, bundled-plugin shards, channel + contracts, `check`, `check-additional`, build smoke, docs checks, Python + skills, Windows, macOS, Android, and Control UI i18n lanes. + Example: `gh workflow run ci.yml --ref release/YYYY.M.D` - Run `pnpm qa:otel:smoke` when validating release telemetry. It exercises QA-lab through a local OTLP/HTTP receiver and verifies the exported trace span names, bounded attributes, and content/identifier redaction without @@ -182,18 +188,20 @@ When cutting a stable npm release: SHA for a validation-only dry run of the preflight workflow 2. Choose `npm_dist_tag=beta` for the normal beta-first flow, or `latest` only when you intentionally want a direct stable publish -3. Run `OpenClaw Release Checks` separately with the same tag or the +3. Run the manual `CI` workflow on the release ref when you want full normal CI + coverage instead of smart-scoped merge coverage +4. Run `OpenClaw Release Checks` separately with the same tag or the full current workflow-branch commit SHA when you want live prompt cache, QA Lab parity, Matrix, and Telegram coverage - This is separate on purpose so live coverage stays available without recoupling long-running or flaky checks to the publish workflow -4. Save the successful `preflight_run_id` -5. Run `OpenClaw NPM Release` again with `preflight_only=false`, the same +5. Save the successful `preflight_run_id` +6. Run `OpenClaw NPM Release` again with `preflight_only=false`, the same `tag`, the same `npm_dist_tag`, and the saved `preflight_run_id` -6. If the release landed on `beta`, use the private +7. If the release landed on `beta`, use the private `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml` workflow to promote that stable version from `beta` to `latest` -7. If the release intentionally published directly to `latest` and `beta` +8. If the release intentionally published directly to `latest` and `beta` should follow the same stable build immediately, use that same private workflow to point both dist-tags at the stable version, or let its scheduled self-healing sync move `beta` later