Uh oh!
There was an error while loading. Please reload this page.
ci(repo): gate api-changes detect on turbo cache-hit signal - #8723
Conversation
Skip the break-check snapshot/detect work (and the baseline worktree rebuild) when every tracked package's #build was a turbo cache HIT, since identical build inputs mean the emitted declarations are unchanged. A MISS, or any uncertainty (missing summary, cold cache, parse error), still runs detect as before. Keys on #build rather than #build:declarations so the gate stays correct as packages migrate declaration emission into the bundler (e.g. shared via tsdown has no build:declarations task); build:declarations dependsOn build, so a #build HIT already implies unchanged declarations for every package. On a cache-hit skip, post no comment. A turbo HIT is an inference that nothing changed, not a break-check run, so a "no breaking changes" clearance would overclaim (a revert to an older still-cached state HITs the cache yet differs from base). The "no API changes" comment is only posted when detect actually ran and found nothing, and break-check comments are now stamped with the head SHA they ran on, so a comment left unrefreshed by a later skipped push is recognizable as stale.
🦋 Changeset detectedLatest commit: 0313d87 The changes in this PR will be included in the next version bump. This PR includes changesets to release 0 packagesWhen changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
The latest updates on your projects. Learn more about Vercel for GitHub.
|
@clerk/astro@clerk/backend@clerk/chrome-extension@clerk/clerk-js@clerk/expo@clerk/expo-passkeys@clerk/express@clerk/fastify@clerk/hono@clerk/localizations@clerk/nextjs@clerk/nuxt@clerk/react@clerk/react-router@clerk/shared@clerk/tanstack-react-start@clerk/testing@clerk/ui@clerk/upgrade@clerk/vuecommit: |
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository YAML (base), Organization UI (inherited) Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughThe workflow's check-api job now fetches the PR base commit earlier and adds a "Determine API surface changed" Node gate that compares turbo build:declarations task hashes between the PR head and a detached baseline worktree. If the gate reports no change, expensive baseline snapshot, install, build, and break-check detect steps are skipped. When detect runs, the PR comment step now receives HEAD_SHA, computes a short SHA, and appends a “Last ran on …” note; inline docs clarify skip vs detect-run behavior. Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Comment |
API Changes Report
Summary
@clerk/astroCurrent version: 3.3.2 Subpath |
afe20f5 to
0313d87CompareUh oh!
There was an error while loading. Please reload this page.
break-check's API Extractor pass runs over all 19 tracked packages on every PR the paths filter catches, including ones that only touched tests, docs, or impl with no public
.d.tschange. This builds declarations with--summarizefirst and skips the snapshot/detect (and the baseline worktree rebuild) when every tracked package's#buildwas a turbo cache HIT.Worth a close look: the gate keys on
#build, not#build:declarations. The latter is going away as packages move declaration emission into the bundler (shared already has none, via tsdown), and a#buildHIT already implies unchanged declarations sincebuild:declarationsdependsOnbuild. Keying onbuild:declarationswould silently skip-blind those packages.On a HIT we post nothing rather than a "no API changes" comment, since a HIT is an inference that nothing changed, not an actual run, and a clearance would overclaim (a revert to an older still-cached state HITs the cache but differs from base). That same gap means a recent revert can be silently skipped, acceptable here since the job is informational and we no longer emit a false green; comments are stamped with the head SHA they ran on so an unrefreshed one reads as stale. HIT/MISS only exists with the remote cache on Blacksmith, so the first run here is the real test.