chore(ci): trigger release workflow by git tag push#721
Conversation
Replace semantic-release on master push with a self-contained tag-triggered workflow. Supports pre-release dist-tags (beta, alpha, rc, next, dev) and creates GitHub Releases automatically. Release process: `npm version <version>` then `git push --tags` Closes #719
|
Note Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported. |
|
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:
📝 WalkthroughWalkthroughRelease workflow now triggers on pushed Git tags Changes
Sequence DiagramsequenceDiagram
participant Git as Git (tag push)
participant GH as GitHub Actions
participant Val as Validation
participant Build as Build job
participant NPM as npm Registry
participant Release as GitHub Release
Git->>GH: Push tag matching v*
GH->>Val: extract tag, strip "v", read package.json
Val->>Val: compare tag-version vs package.json.version
alt versions match
GH->>Build: run build (vp run build)
Build->>GH: return build/artifacts
GH->>NPM: npm publish --access public --tag <dist-tag>
NPM-->>GH: publish result
GH->>Release: create GitHub Release (prerelease if dist-tag != latest)
else mismatch
Val-->>GH: fail job with validation error
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 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 |
commit: |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #721 +/- ##
=======================================
Coverage 92.77% 92.77%
=======================================
Files 10 10
Lines 747 747
Branches 233 233
=======================================
Hits 693 693
Misses 51 51
Partials 3 3 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Pull request overview
This PR replaces the existing branch-push-driven release automation with a self-contained GitHub Actions workflow that publishes to npm and creates a GitHub Release when a v* git tag is pushed, including prerelease dist-tag handling and a tag↔package.json version guard.
Changes:
- Switch release trigger from
pushonmastertopushonv*tags. - Add in-workflow build, version/tag validation, npm dist-tag selection, npm publish, and GitHub Release creation.
- Remove use of the external reusable workflow previously used for npm releases.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
.github/workflows/release.yml
Outdated
| - name: Build | ||
| run: vp run build | ||
|
|
There was a problem hiding this comment.
The repo’s prepublishOnly script runs vp run build, and npm publish runs prepublishOnly by default. With the separate "Build" step here, the workflow will build twice unnecessarily. Consider removing this Build step (rely on prepublishOnly) or publish with scripts disabled if you want to build explicitly.
| - name: Build | |
| run: vp run build |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/release.yml:
- Around line 39-49: The dist-tag step (id: dist-tag) currently falls back to
"latest" for any prerelease it doesn't explicitly allow; update the logic so
that if TAG_VERSION (from GITHUB_REF_NAME) matches a prerelease pattern (the
grep -qE '-(alpha|beta|rc|next|dev)' check) you always extract the prerelease
identifier into PRE_TAG and emit that as the tag (do not default to "latest" for
unknown identifiers like "preview"), and ensure the subsequent release creation
step uses that tag to mark the GitHub Release as prerelease rather than stable
(i.e., use PRE_TAG/GITHUB_OUTPUT from dist-tag to decide prerelease status).
- Around line 57-64: The publish step ("Publish to npm") must be made rerun-safe
so a successful publish followed by a failing release step won't block later
reruns; modify the "Publish to npm" step to first check npm for the target
version (e.g., run npm view ${{ env.PACKAGE_NAME }}@${{
steps.dist-tag.outputs.tag }} or use npm info) and skip publishing if that
version already exists, then let the "Create GitHub Release" step run
unconditionally (or move "Create GitHub Release" into its own downstream job
that depends on the publish job); update the workflow to use the package
name/version outputs (steps/dist-tag.outputs.tag or your get_version step) to
perform the check and only run npm publish when the version is absent.
🪄 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: 6f4801a5-38e0-4ecd-881b-9a07e77e3478
📒 Files selected for processing (1)
.github/workflows/release.yml
There was a problem hiding this comment.
🧹 Nitpick comments (1)
README.md (1)
360-360: Document the npm Trusted Publisher prerequisitePlease add a short note near Line 360 that npm Trusted Publisher must target
.github/workflows/release.yml; otherwise publish can fail even when tags are pushed correctly.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@README.md` at line 360, Add a short note near the release workflow description around the paragraph referencing .github/workflows/release.yml (around the existing text about publishing on v* tags) stating that npm Trusted Publisher must be configured to target .github/workflows/release.yml; include a brief warning that if the Trusted Publisher target is not set to that specific workflow file, npm publish can fail even when tags are pushed correctly. Make the note one sentence and place it immediately after the sentence about automatic publishing and pre-release dist-tags.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@README.md`:
- Line 360: Add a short note near the release workflow description around the
paragraph referencing .github/workflows/release.yml (around the existing text
about publishing on v* tags) stating that npm Trusted Publisher must be
configured to target .github/workflows/release.yml; include a brief warning that
if the Trusted Publisher target is not set to that specific workflow file, npm
publish can fail even when tags are pushed correctly. Make the note one sentence
and place it immediately after the sentence about automatic publishing and
pre-release dist-tags.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
♻️ Duplicate comments (2)
.github/workflows/release.yml (2)
39-49:⚠️ Potential issue | 🟠 MajorUnknown prerelease identifiers will incorrectly publish as
latest.The grep pattern only recognizes
alpha|beta|rc|next|dev. A tag likev5.0.0-preview.0orv5.0.0-canary.1would fall through to theelsebranch and publish with--tag latest, which contradicts the prerelease intent.Consider failing closed on unrecognized prerelease identifiers rather than defaulting to
latest.,
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release.yml around lines 39 - 49, The current dist-tag step uses a fixed grep for alpha|beta|rc|next|dev and will default unknown prerelease identifiers to "latest"; update the logic in the "Determine npm dist-tag" step to detect any prerelease (check if TAG_VERSION contains a '-'), extract the prerelease identifier into PRE_TAG (as already done with sed), then if PRE_TAG is one of the allowed set keep echo "tag=$PRE_TAG", otherwise fail closed by printing an error referencing TAG_VERSION/PRE_TAG to stderr and exiting non‑zero (so the workflow stops instead of publishing with --tag latest); reference the variables TAG_VERSION and PRE_TAG in your change.
51-58:⚠️ Potential issue | 🟠 MajorPublish step is not rerun-safe.
If
npm publishsucceeds but the subsequent "Create GitHub Release" step fails, rerunning the workflow will fail because npm rejects duplicate version publishes. This leaves the release in a broken state where the npm package exists but the GitHub Release doesn't.Consider checking if the version already exists on npm before publishing.
,
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release.yml around lines 51 - 58, The "Publish to npm" step can cause unrecoverable failures if "Create GitHub Release" later fails; modify the workflow so the Publish to npm step first checks if the version already exists on npm (using the dist tag from steps.dist-tag.outputs.tag and the package version) and only runs npm publish when the package/version is not present, or make publishing idempotent by moving npm publish after a safe check step; update the steps named "Publish to npm" and the preceding logic that reads steps.dist-tag.outputs.tag to add an npm view/npm info check (or equivalent) and skip publish when the version is already published so rerunning the workflow won’t fail.
🧹 Nitpick comments (1)
.github/workflows/release.yml (1)
51-52: Add--provenancefor npm package attestation.The workflow has
id-token: writepermission, suggesting OIDC publishing intent, but the publish command doesn't use the--provenanceflag to generate build provenance attestations.Suggested fix
- name: Publish to npm - run: npm publish --access public --tag ${{ steps.dist-tag.outputs.tag }} + run: npm publish --access public --provenance --tag ${{ steps.dist-tag.outputs.tag }}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release.yml around lines 51 - 52, Update the "Publish to npm" step to include the --provenance flag so npm generates build attestations when OIDC credentials are available; modify the run command that currently invokes npm publish --access public --tag ${{ steps.dist-tag.outputs.tag }} to add --provenance, ensuring the workflow's id-token: write permission is used to produce provenance attestations during publish.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In @.github/workflows/release.yml:
- Around line 39-49: The current dist-tag step uses a fixed grep for
alpha|beta|rc|next|dev and will default unknown prerelease identifiers to
"latest"; update the logic in the "Determine npm dist-tag" step to detect any
prerelease (check if TAG_VERSION contains a '-'), extract the prerelease
identifier into PRE_TAG (as already done with sed), then if PRE_TAG is one of
the allowed set keep echo "tag=$PRE_TAG", otherwise fail closed by printing an
error referencing TAG_VERSION/PRE_TAG to stderr and exiting non‑zero (so the
workflow stops instead of publishing with --tag latest); reference the variables
TAG_VERSION and PRE_TAG in your change.
- Around line 51-58: The "Publish to npm" step can cause unrecoverable failures
if "Create GitHub Release" later fails; modify the workflow so the Publish to
npm step first checks if the version already exists on npm (using the dist tag
from steps.dist-tag.outputs.tag and the package version) and only runs npm
publish when the package/version is not present, or make publishing idempotent
by moving npm publish after a safe check step; update the steps named "Publish
to npm" and the preceding logic that reads steps.dist-tag.outputs.tag to add an
npm view/npm info check (or equivalent) and skip publish when the version is
already published so rerunning the workflow won’t fail.
---
Nitpick comments:
In @.github/workflows/release.yml:
- Around line 51-52: Update the "Publish to npm" step to include the
--provenance flag so npm generates build attestations when OIDC credentials are
available; modify the run command that currently invokes npm publish --access
public --tag ${{ steps.dist-tag.outputs.tag }} to add --provenance, ensuring the
workflow's id-token: write permission is used to produce provenance attestations
during publish.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 6273e2a3-feb9-4aad-af22-8449f240be1a
📒 Files selected for processing (1)
.github/workflows/release.yml
Any version with a hyphenated pre-release suffix (e.g., preview, canary) is now correctly published with its dist-tag and marked as prerelease.
fengmk2
changed the title
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| fi | ||
|
|
||
| - name: Publish to npm | ||
| run: npm publish --access public --tag ${{ steps.dist-tag.outputs.tag }} |
There was a problem hiding this comment.
npm publish here doesn't provide any auth (e.g., NODE_AUTH_TOKEN) and also doesn't enable npm Trusted Publishing via OIDC. With only id-token: write, npm typically requires --provenance (or NPM_CONFIG_PROVENANCE=true) to perform the OIDC exchange; otherwise this step is likely to fail or fall back to token-based auth. Consider publishing with provenance (and/or explicitly configuring auth) to match the PR's stated OIDC release process.
| run: npm publish --access public --tag ${{ steps.dist-tag.outputs.tag }} | |
| run: npm publish --access public --tag ${{ steps.dist-tag.outputs.tag }} --provenance |
| TAG_VERSION="${GITHUB_REF_NAME#v}" | ||
| if echo "$TAG_VERSION" | grep -qE '-([a-zA-Z]+)'; then | ||
| # Extract pre-release identifier (e.g., "beta" from "5.0.0-beta.0") | ||
| PRE_TAG=$(echo "$TAG_VERSION" | sed -E 's/.*-([a-zA-Z]+).*/\1/') | ||
| echo "tag=$PRE_TAG" >> "$GITHUB_OUTPUT" | ||
| else | ||
| echo "tag=latest" >> "$GITHUB_OUTPUT" | ||
| fi |
There was a problem hiding this comment.
Pre-release detection only matches tags with alphabetic identifiers (e.g., -beta). SemVer allows numeric-only prerelease identifiers like v1.0.0-0; those would fall into the latest branch and be published to the latest dist-tag and marked as a stable GitHub Release. Consider treating any version containing - as prerelease, and only mapping the identifier to a dist-tag when it is present/valid (otherwise default to a safe prerelease dist-tag like next).
Summary
v5.0.0-beta.0publishes with--tag beta,v5.0.0-alpha.1with--tag alpha, etc.Release process after merge
Note
Update the OIDC Trusted Publisher configuration on npmjs.com to point to
release.ymlin this repo.Closes #719
🤖 Generated with Claude Code
Summary by CodeRabbit