Skip to content

ci: repo-scanning tests move out of the heavy packages' test tasks into one repo-conformance task so package suites become cacheable again (maintainer-directed, measure-first) #16466

Description

@claude

Filed by the skills lane seat (session session_019RfFHiRCSs3JXLK4cwcfox, os-steve) on the maintainer's direction, 2026-09-07T02:5xZ, and dispatched by the same seat on that direction. Surface owner stays domain:devx.

Authority (maintainer, verbatim, live PM chat 2026-09-07): 「同意你的建议,你负责执行派发所有可行的优化」, after the seat measured why docs-only merges still run 15–20-minute shards in the queue.

What

The repo-scanning tests — the ones whose declared inputs are the whole repository — leave the heavy packages' test tasks and run once per CI run as their own task, so @objectstack/spec, core, types, runtime, objectql and rest become cacheable again and a change outside a package no longer re-runs that package's whole suite.

Measured

  • turbo.json declares $TURBO_ROOT$ inputs 169 times. @objectstack/spec#test lists packages/**/*.ts, content/**, skills/**, scripts/** and more; core#test, types#test, runtime#test, objectql#test list packages/**/*.ts; rest#test lists content/**, docs/**, skills/**. Any .ts or docs change anywhere invalidates those five or six suites — the largest in the repo (spec alone 11,420 cases).
  • The declarations are correct: scripts/cross-package-test-inputs.mjs is the registry of tests that read outside their package (117 rows), and check-cross-package-test-inputs.mjs keeps turbo's inputs equal to it (main is red for every PR that touches packages/spec: #7769 gave sys_api_key update without bulk, and the conformance scan that catches it lives in a package #7769 never touched #7802). The cost is structural, not a mistake: package-scoped caching cannot work while repo-scanning tests live inside package suites.
  • Measured consequence: docs-only merge groups at 01:18Z ran shards of 15–20 minutes.

Ruling — measure first

  1. From the registry, list every repo-scanning test file with its home package and the globs it reads; measure each file's duration (a local vitest run of those files, or the per-file report from ci: every Test Core run publishes the slowest test files and packages beside their pinned weights (maintainer-directed, part B measurement) #16454 once it exists) and the share of its package's suite time. Report the table before any edit.
  2. If the scanning files are at most ~60 and separable (they import from their package's public entry or from the repo, not from private internals), move them into one task — a repo-conformance vitest project (home to be measured: packages/qa or a root-level project) that owns the wide inputs and runs once per CI run as its own Test Core item; the packages' test tasks then keep package-local inputs plus their dependency graph, and the cross-package registry keeps its gate over the new home. If the files are more numerous or entangled with package internals, stop after the table and report options with a recommendation on the four axes.
  3. Nothing about what the tests assert changes; no test is deleted; the registry gate stays green under the new layout.
  4. Clause-②: yes — what CI verifies per package at merge time changes shape. Contract tier.

Acceptance

  • The table from step 1 in the PR body; turbo cache hit rates before/after for a docs-only change and a leaf change, measured locally (turbo run test --dry-run=json shows the cache status per task).
  • check-cross-package-test-inputs green; partition-test-shards --self-test green with the new item present.

Refs #16173, #16453.


Generated by Claude Code

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions