ci: do not block PRs on broken Next.js canary publishes#16408
Merged
denolfe merged 4 commits intopayloadcms:mainfrom Apr 28, 2026
Merged
ci: do not block PRs on broken Next.js canary publishes#16408denolfe merged 4 commits intopayloadcms:mainfrom
denolfe merged 4 commits intopayloadcms:mainfrom
Conversation
When Vercel publishes `next@<canary>` to npm but its peer packages (`@next/env`, `@next/eslint-plugin-next`) are missing for the same version, `pnpm create next-app@canary` fails with `ERR_PNPM_NO_MATCHING_VERSION`, which used to fail every `int-* (1/3)` shard on every PR for reasons unrelated to the PR. A new `probe-next-canary` job checks the registry up front: - If the canary is incomplete, `tests-int` skips the `Canary` variants in `test/create-payload-app/int.spec.ts` via Vitest's `-t` filter (`^(?!.*Canary).*$`). The latest variants still run and remain strict. - A new `notify-next-canary-broken` job posts a sticky PR comment via `marocchino/sticky-pull-request-comment` explaining the upstream issue, making clear it does not block the PR, and asking the author to open an issue at vercel/next.js. The comment is removed automatically once a healthy canary lands on npm. The job is intentionally not part of `all-green` so an upstream Next.js breakage cannot block a Payload PR. Implementation is YAML-only; the test file is unchanged.
- Reword sticky comment to present tense (it posts before tests-int finishes, so claiming the tests "were skipped" was inaccurate). - Skip the notify job when needs_tests is false, so it does not spawn a runner just to evaluate two false if-conditions on doc-only PRs. - Lowercase the new jobs' display names to match neighboring jobs (lint, build, tests-int, etc.). - Retry each `npm view` lookup up to 3 times with linear backoff so a transient registry hiccup does not flip healthy to false.
Move the sticky PR comment into a dedicated workflow that runs on `pull_request_target` so it also works on PRs from forks; the `pull_request` event used by `main.yml` gives fork PRs a read-only `GITHUB_TOKEN` and cannot post comments. The probe only calls `npm view`, never checks out PR code, so `pull_request_target` is safe here. Drop the equivalent (fork-skipped) job from `main.yml`.
denolfe
approved these changes
Apr 28, 2026
Member
denolfe
left a comment
denolfe
left a comment
There was a problem hiding this comment.
Comment blocks are a bit verbose (I assume generated), but we can get this merged to unblock CI.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When Vercel publishes
next@<canary>to npm but its peer packages (@next/env,@next/eslint-plugin-next) are missing for the same version,pnpm create next-app@canaryfails withERR_PNPM_NO_MATCHING_VERSION, which used to fail everyint-* (1/3)shard on every PR for reasons unrelated to the PR.A new
probe-next-canaryjob checks the registry up front:tests-intskips theCanaryvariants intest/create-payload-app/int.spec.tsvia Vitest's-tfilter (^(?!.*Canary).*$). The latest variants still run and remain strict.notify-next-canary-brokenjob posts a sticky PR comment viamarocchino/sticky-pull-request-commentexplaining the upstream issue, making clear it does not block the PR, and asking the author to open an issue at vercel/next.js. The comment is removed automatically once a healthy canary lands on npm. The job is intentionally not part ofall-greenso an upstream Next.js breakage cannot block a Payload PR.Implementation is YAML-only; the test file is unchanged.