ci(root): stop the test step rebuilding under running suites

[mobeenabdullah]

PRs have been going red on Lint / Typecheck / Test / Build with errors like:

Cannot find module '.../packages/nextly/dist/chunk-OZJFLON7.mjs'
  imported from '.../packages/nextly/dist/index.mjs'
Failed to resolve entry for package "nextly".

in packages the change never touched, and in a different package each run.

Cause, measured rather than argued

The Test step runs pnpm turbo test --filter=… after the Build step has already built every package. Because test declares dependsOn: ["^build"], turbo re-materialises each test's build dependencies from cache — it rewrites their dist/ directories while sibling suites are already collecting against them.

Measured on a fully built tree, three filters only:

invocation	build replays triggered
turbo test --filter=… (what CI runs today)	11
turbo test --only --filter=…	0

Eleven packages' dist/ rewritten under running test processes. A suite that resolves a dependency's entry mid-rewrite sees index.mjs but not yet the chunk it imports. On a fast machine with a warm cache the window is tiny, which is why this never reproduces locally; in CI it is wide enough to lose, and which package loses varies run to run.

That accounts for every observation: no GitHub Actions cache is needed (a run with Cache not found failed identically), the missing artifact is logged as built minutes earlier, main sometimes gets lucky, and the failing package changes between runs.

The fix

--only on the Test step: run the specified tasks, not their parents. The Build step immediately above already covers them.

Safe because the Test step's filter list is a subset of ./packages/*, which the Build step builds. A package added to the test list but not built above would fail loudly at collection, not skip silently.

It composes with #651 rather than undoing it: blocks-react gains its build edge from vitest.global-setup.ts as well as from turbo, and that setup still runs.

Scope, deliberately narrow

integration.yml has the same build-then-test shape and I did not change it. Those jobs are green today, I cannot run them locally without the database services, and changing something green on an analogy is how the last three attempts at this went wrong. If integration ever shows the symptom, the same one-word fix applies with its own evidence.

Honesty about the path here

This is the fourth hypothesis for this failure. The first three — cancelled runs poisoning the turbo cache, concurrent workflows sharing a cache key, tsup clean: true racing a test — were each falsified by evidence, and one of them reached main as #667 before I could retract it. #667 is not harmful and its cache-save gating stands on its own, but it did not fix this.

What makes this one different is that it is measured, not inferred: 11 replays versus 0, on the same tree, one flag apart.

No changeset — CI-only, per AGENTS.md.

[mobeenabdullah]

@codex please review this PR

[coderabbitai]

Warning

Review limit reached

@mobeenabdullah, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 36 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 28233e64-993f-40da-ab86-374c4570ca78

📥 Commits

Reviewing files that changed from the base of the PR and between 8a82d3e and 74f6cd8.

📒 Files selected for processing (1)

• .github/workflows/ci.yml

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[mobeenabdullah]

Two verifications on the risks a reviewer would reasonably raise, both run rather than argued.

1. Does --only leave anything unbuilt? The Test step filters 17 packages; all 17 resolve to directories under packages/, which is exactly what the Build step covers with --filter='./packages/*'.

test-filtered packages: 17
covered by ./packages/*: 17
NOT covered (would break under --only): none

2. Does --only regress #651? That PR gave blocks-react a turbo.json with dependsOn: ["$TURBO_EXTENDS$", "build"], and --only skips exactly that kind of parent edge — so this is the sharpest objection to the change.

It does not regress it, because #651 deliberately built two guarantees and only one of them is a turbo edge. Deleting packages/blocks-react/dist entirely and running under --only:

rm -rf packages/blocks-react/dist
pnpm turbo test --only --filter=@nextlyhq/blocks-react
  → Test Files  15 passed (15)
  → dist REBUILT by vitest.global-setup

vitest.global-setup.ts rebuilds before collection, which is the case its own comment describes as covering "the entry points turbo never sees". That guarantee is untouched here.

Worth noting the shape of it: #651's author wrote the belt-and-braces because a single turbo edge was not trusted to be sufficient, and that judgement is what makes this change safe a week later.

[pkg-pr-new]

Open in StackBlitz

@nextlyhq/adapter-drizzle

npm i https://pkg.pr.new/@nextlyhq/adapter-drizzle@74f6cd8

@nextlyhq/adapter-mysql

npm i https://pkg.pr.new/@nextlyhq/adapter-mysql@74f6cd8

@nextlyhq/adapter-postgres

npm i https://pkg.pr.new/@nextlyhq/adapter-postgres@74f6cd8

@nextlyhq/adapter-sqlite

npm i https://pkg.pr.new/@nextlyhq/adapter-sqlite@74f6cd8

@nextlyhq/admin

npm i https://pkg.pr.new/@nextlyhq/admin@74f6cd8

@nextlyhq/admin-css

npm i https://pkg.pr.new/@nextlyhq/admin-css@74f6cd8

@nextlyhq/blocks-engine

npm i https://pkg.pr.new/@nextlyhq/blocks-engine@74f6cd8

@nextlyhq/blocks-react

npm i https://pkg.pr.new/@nextlyhq/blocks-react@74f6cd8

@nextlyhq/builder

npm i https://pkg.pr.new/@nextlyhq/builder@74f6cd8

create-nextly-app

npm i https://pkg.pr.new/create-nextly-app@74f6cd8

nextly

npm i https://pkg.pr.new/nextly@74f6cd8

@nextlyhq/plugin-form-builder

npm i https://pkg.pr.new/@nextlyhq/plugin-form-builder@74f6cd8

@nextlyhq/plugin-page-builder

npm i https://pkg.pr.new/@nextlyhq/plugin-page-builder@74f6cd8

@nextlyhq/plugin-sdk

npm i https://pkg.pr.new/@nextlyhq/plugin-sdk@74f6cd8

@nextlyhq/plugin-seo

npm i https://pkg.pr.new/@nextlyhq/plugin-seo@74f6cd8

@nextlyhq/storage-s3

npm i https://pkg.pr.new/@nextlyhq/storage-s3@74f6cd8

@nextlyhq/storage-uploadthing

npm i https://pkg.pr.new/@nextlyhq/storage-uploadthing@74f6cd8

@nextlyhq/storage-vercel-blob

npm i https://pkg.pr.new/@nextlyhq/storage-vercel-blob@74f6cd8

@nextlyhq/ui

npm i https://pkg.pr.new/@nextlyhq/ui@74f6cd8

commit: 74f6cd8

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 74f6cd8981

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Preserve dependency invalidation when skipping parent tasks

When a PR changes only a workspace dependency, this can replay a stale result for an unchanged dependent package: turbo.jsonc keeps test cached, but pnpm turbo test --only --filter=@nextlyhq/plugin-page-builder --dry-run=json reports dependencies: [] and inputs only from that package, whereas the command without --only includes @nextlyhq/blocks-react#build, @nextlyhq/blocks-engine#build, and the other dependency hashes. The checked-in Turbo 2.9.18 help confirms that --only “does not execute parent tasks.” Because the workflow restores Turbo entries from prior SHAs, a blocks-react change can therefore leave plugin-page-builder's dependency-importing suites cached and unexecuted despite the fresh Build step. Force the selected tests to execute (for example with --force) or otherwise retain dependency content in their cache keys while avoiding artifact replay.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Move the nested build ahead of concurrent tests

When @nextlyhq/blocks-react#test is a cache miss alongside any dependent suite, this still starts a build after the concurrent Test step has begun: its vitest.global-setup.ts unconditionally runs pnpm exec turbo run build --filter=@nextlyhq/blocks-react, including the ^build chain, while an --only dry run shows the selected test tasks have no ordering dependencies. At that point builder and plugin-page-builder suites can already be collecting imports from blocks-react or blocks-engine, and both packages' tsup configurations use clean: true, so the nested build can delete and rewrite the same dist trees that those suites are resolving. This preserves the missing-chunk race the change is intended to remove; the blocks-react build needs to happen before the concurrent test phase, or its global setup must avoid rebuilding when CI has already completed that build.

Useful? React with 👍 / 👎.

[mobeenabdullah]

Superseded by the PR above — --only narrows the outer invocation but cannot reach a turbo run nested inside vitest, which is where the rebuild actually happens. Measured: this PR's own run had 0 build replays in the Test step and failed identically. Closing rather than leaving a fix in flight that does not fix it.