mirror of
https://github.com/openclaw/openclaw.git
synced 2026-05-06 19:31:00 +00:00
test: auto-discover vitest suites
This commit is contained in:
Peter Steinberger
19
docs/ci.md
19
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
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user