ci: keep npm publish and GitHub releases coupled, self-heal release gaps#829
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughThe release workflow now uses read-only top-level permissions, runs tests in a separate job before release, and passes ChangesRelease Workflow Improvements
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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. Comment |
🚀 Changeset Version PreviewNo changeset entries found. Merging this PR will not cause a version bump for any packages. |
|
View your CI Pipeline Execution ↗ for commit 3b16c5c
☁️ Nx Cloud last updated this comment at |
@tanstack/ai
@tanstack/ai-angular
@tanstack/ai-anthropic
@tanstack/ai-client
@tanstack/ai-code-mode
@tanstack/ai-code-mode-skills
@tanstack/ai-devtools-core
@tanstack/ai-elevenlabs
@tanstack/ai-event-client
@tanstack/ai-fal
@tanstack/ai-gemini
@tanstack/ai-grok
@tanstack/ai-groq
@tanstack/ai-isolate-cloudflare
@tanstack/ai-isolate-node
@tanstack/ai-isolate-quickjs
@tanstack/ai-mcp
@tanstack/ai-ollama
@tanstack/ai-openai
@tanstack/ai-openrouter
@tanstack/ai-preact
@tanstack/ai-react
@tanstack/ai-react-ui
@tanstack/ai-solid
@tanstack/ai-solid-ui
@tanstack/ai-svelte
@tanstack/ai-utils
@tanstack/ai-vue
@tanstack/ai-vue-ui
@tanstack/openai-base
@tanstack/preact-ai-devtools
@tanstack/react-ai-devtools
@tanstack/solid-ai-devtools
commit: |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/release.yml:
- Around line 79-92: The release backfill logic only checks each package’s
current package.json version, so it misses earlier npm-published versions that
also lack GitHub releases. Update the release workflow loop around the
package.json scan to enumerate all published npm versions for each package, then
filter those versions to the intended recovery window or changelog entries
before calling gh release view/create so every missing npm version is restored,
not just the latest one.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 5cd34324-75a1-41ad-97ca-0a6596f86dcd
📒 Files selected for processing (1)
.github/workflows/release.yml
| for pkg in packages/*/package.json; do | ||
| [ "$(jq -r '.private // false' "$pkg")" = "true" ] && continue | ||
| name=$(jq -r '.name' "$pkg") | ||
| version=$(jq -r '.version' "$pkg") | ||
| tag="${name}@${version}" | ||
|
|
||
| # Already released → nothing to do. | ||
| if gh release view "$tag" >/dev/null 2>&1; then | ||
| continue | ||
| fi | ||
| # Only mirror versions that actually reached npm. This IS the invariant. | ||
| if ! npm view "${name}@${version}" version >/dev/null 2>&1; then | ||
| continue | ||
| fi |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift
Backfill all missing npm versions, not just the current one.
This loop only checks the current package.json version. If multiple versions were published after the release gap started, older npm versions without GitHub releases remain missing, so the stated published to npm => GitHub release exists invariant is not fully restored. Consider enumerating npm versions and filtering to the intended recovery window/changelog entries before creating missing releases.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/release.yml around lines 79 - 92, The release backfill
logic only checks each package’s current package.json version, so it misses
earlier npm-published versions that also lack GitHub releases. Update the
release workflow loop around the package.json scan to enumerate all published
npm versions for each package, then filter those versions to the intended
recovery window or changelog entries before calling gh release view/create so
every missing npm version is restored, not just the latest one.
AlemTuzlak
force-pushed
the
ci/couple-npm-github-releases
branch
3 times, most recently
from
cda8ae3 to
a9ffa7b
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/release.yml:
- Around line 80-82: The release tag creation block is tagging the current
checkout, which can point the GitHub Release at a later commit than the actual
npm publish. Update the workflow around the git rev-parse/git tag/git push logic
to resolve the commit that produced the published version first using the
release/tag context, and create the tag on that commit instead of HEAD; if that
commit cannot be determined, fail closed rather than backfilling the tag. Use
the existing tag-generation flow in the release workflow to locate the fix.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 80447b04-f738-4fc4-8093-b0b5e10679eb
📒 Files selected for processing (1)
.github/workflows/release.yml
| if ! git rev-parse -q --verify "refs/tags/${tag}" >/dev/null; then | ||
| git tag "$tag" | ||
| git push origin "refs/tags/${tag}" |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift
Don’t backfill release tags at workflow HEAD.
For already-published npm versions, Line 81 can point the GitHub Release at a later commit than the package that was actually published. Resolve the publish commit first, or fail closed instead of tagging the current checkout.
Safer tag target example
if ! git rev-parse -q --verify "refs/tags/${tag}" >/dev/null; then
- git tag "$tag"
+ git_head="$(npm view "${name}@${version}" gitHead --json 2>/dev/null | jq -r 'select(type == "string" and length > 0) // empty')"
+ if [ -z "$git_head" ] || ! git cat-file -e "${git_head}^{commit}" 2>/dev/null; then
+ echo "::error::Cannot resolve git commit for ${tag}; refusing to tag the workflow HEAD"
+ exit 1
+ fi
+ git tag "$tag" "$git_head"
git push origin "refs/tags/${tag}"
fi📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| if ! git rev-parse -q --verify "refs/tags/${tag}" >/dev/null; then | |
| git tag "$tag" | |
| git push origin "refs/tags/${tag}" | |
| if ! git rev-parse -q --verify "refs/tags/${tag}" >/dev/null; then | |
| git_head="$(npm view "${name}@${version}" gitHead --json 2>/dev/null | jq -r 'select(type == "string" and length > 0) // empty')" | |
| if [ -z "$git_head" ] || ! git cat-file -e "${git_head}^{commit}" 2>/dev/null; then | |
| echo "::error::Cannot resolve git commit for ${tag}; refusing to tag the workflow HEAD" | |
| exit 1 | |
| fi | |
| git tag "$tag" "$git_head" | |
| git push origin "refs/tags/${tag}" | |
| fi |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/release.yml around lines 80 - 82, The release tag creation
block is tagging the current checkout, which can point the GitHub Release at a
later commit than the actual npm publish. Update the workflow around the git
rev-parse/git tag/git push logic to resolve the commit that produced the
published version first using the release/tag context, and create the tag on
that commit instead of HEAD; if that commit cannot be determined, fail closed
rather than backfilling the tag. Use the existing tag-generation flow in the
release workflow to locate the fix.
a9ffa7b to
79d0d6d
Compare
|
Thanks @coderabbitai — addressing both findings: Tag pointing at the wrong commit — fixed. The tag now pins explicitly to the release commit ( Only the current version is backfilled, not earlier missing ones — intentional, not fixing here. This step's job is the coupling guarantee for the current release (publish → release, in one run), not a historical sweep. Auto-backfilling every earlier npm version would require resolving the correct commit per old version, which can't be reliably reconstructed after the fact — synthesizing those tags at the release commit would create a pile of wrong-commit tags across ~30 packages. Restoring the existing |
|
Tip For best results, initiate chat on the files or code changes.
Thanks for the clear write-up! ✏️ Learnings added
|
|
Caution Failed to replace (edit) comment. This is likely due to insufficient permissions or the comment being deleted. Error details |
AlemTuzlak
force-pushed
the
ci/couple-npm-github-releases
branch
from
79d0d6d to
a78389c
Compare
|
Update: removed the self-heal/backfill step entirely. The two findings above were both about that step, so they're now moot. The PR is reduced to the structural changes: test/release job split (gated together), explicit GITHUB_TOKEN on the changesets step, and least-privilege permissions. |
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/release.yml (1)
30-55: 🗄️ Data Integrity & Integration | 🟠 MajorBuild packages in the release job before publishing
changeset:publishis justchangeset publishand does not rebuild the workspace. The publishable packages point atdist/outputs, and the release runner starts from a fresh checkout with no tracked build artifacts. Add an explicit build step before the Changesets action, or make the publish command build first.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/release.yml around lines 30 - 55, The release job currently runs changesets publish without rebuilding the workspace, so the publishable packages may point to missing dist outputs on a fresh checkout. Update the release workflow around the release job and the changesets/action step to ensure package builds happen first, either by adding an explicit build step before Run Changesets or by changing the publish command to invoke the build before publishing. Use the release job, Run Changesets (version or publish), and changesets/action as the anchors for the fix.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In @.github/workflows/release.yml:
- Around line 30-55: The release job currently runs changesets publish without
rebuilding the workspace, so the publishable packages may point to missing dist
outputs on a fresh checkout. Update the release workflow around the release job
and the changesets/action step to ensure package builds happen first, either by
adding an explicit build step before Run Changesets or by changing the publish
command to invoke the build before publishing. Use the release job, Run
Changesets (version or publish), and changesets/action as the anchors for the
fix.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 01e72976-e416-4398-88dc-2ffce818ff6b
📒 Files selected for processing (1)
.github/workflows/release.yml
AlemTuzlak
force-pushed
the
ci/couple-npm-github-releases
branch
from
a78389c to
3b16c5c
Compare
GitHub releases are created only by the changesets/action step, and that step has not completed cleanly on any release-triggering run since mid-June (last release: @tanstack/ai-react@0.15.5 on 2026-06-15; npm is now at 0.15.12). The "Version Packages" merge runs (#773, #778, #787, #792, #808, #813) passed the test gate and then FAILED at the "Run Changesets" step: CI ran `changeset publish` and npm advanced, but the step died before the tag-push / GitHub-release phase, so no tags (0.15.6-0.15.12 don't exist) and no releases were created. More recent runs (#814, #825) now fail even earlier, at the test gate (test:kiira). (The exact in-step error is no longer recoverable - those runs' logs have expired.) Changes: - Split into a `test` gate job and a `release` job (needs: test) so a flaky run blocks BOTH npm and GitHub releases together, never one without the other. - Tighten permissions: top-level contents:read; write scoped to the release job.
2 participants
Problem
GitHub releases stopped being created after 2026-06-15 (
@tanstack/ai-react@0.15.5was the last one), even though npm kept receiving new versions through CI (ai-reactis now at0.15.12).Root cause: GitHub releases are created by one thing only — the
changesets/actionstep inrelease.yml— and that step has not completed cleanly on any release-triggering run since mid-June:ci: Version Packagesmerge run (ci: Version Packages #773, ci: Version Packages #778, ci: Version Packages #787, ci: Version Packages #792, ci: Version Packages #808, ci: Version Packages #813) passed Run Tests and then failed at the "Run Changesets" step. CI ranchangeset publishand npm advanced, but the step died before the tag-push / GitHub-release phase — so no git tags (0.15.6–0.15.12don't exist) and no releases were created.root:test:kiira(added totest:ciin ci(docs): type-check doc code samples with kiira #805) fails, so the changesets step is never reached.(The exact in-step error from the Jun 16–23 runs is no longer recoverable — those runs' logs have expired — but the structural signature is clear: test gate green, changesets step red, npm published, no tags, no releases.)
What this PR does
test(gate) +release(needs: test) jobs. A flaky run blocks both npm and GitHub releases together — never one without the other.contents: read; write scoped to thereleasejob.What this PR does NOT do
It does not diagnose or fix why the changesets step itself was failing after publishing to npm (logs expired). If that step still fails mid-way, npm and GitHub can still drift — this PR relies on the changesets step succeeding. The next post-merge release run is the place to capture its
Run Changesetslog before it expires.Follow-ups (not in this PR)
0.15.6–0.15.12, etc.) as a one-off, with accurate per-version commits.Testing
Workflow changes can only be fully exercised on
main. Validated locally: YAML parses and the job graph istest → release.