Skip to content

ci: trunk-based release (publish on tags, single main branch)#57

Merged
devCluna merged 1 commit into
mainfrom
chore/trunk-based-release
Jul 2, 2026
Merged

ci: trunk-based release (publish on tags, single main branch)#57
devCluna merged 1 commit into
mainfrom
chore/trunk-based-release

Conversation

@devCluna

@devCluna devCluna commented Jul 2, 2026

Copy link
Copy Markdown
Owner

For an npm library, releases are versions marked by git tags, not deploy-style environment branches. This drops the development/production split.

Changes

  • publish.yml — triggers on v* tags (not push to production); verifies the tag matches package.json version before publishing; GitHub release uses the pushed tag.
  • ci.yml — runs on main + PRs only (dropped development/production).
  • dependabot.yml — targets main.

Release flow after this

  1. Bump version in package.json, merge to main.
  2. git tag vX.Y.Z && git push origin vX.Y.Z → publish workflow runs (npm dist-tag auto: alpha/beta/rc/latest).

Manual follow-up (repo settings, not in this PR)

  • Rename default branch productionmain.
  • Delete the development branch.
  • Re-target any open Dependabot PRs (or let them recreate against main).

🤖 Generated with Claude Code

Summary by CodeRabbit

  • Chores
    • Updated automation to use the main branch for dependency updates and CI pushes.
    • Changed release publishing to run from version tags (v*) and added a version check to prevent mismatched releases.

- publish.yml triggers on 'v*' tags instead of pushing to a release branch,
  and verifies the tag matches package.json before publishing
- ci.yml runs on main + PRs only (drop development/production env branches)
- dependabot targets main

For a library, releases are npm versions marked by git tags, not deploy-style
env branches. Companion manual step: rename default branch production -> main
and delete development.
@coderabbitai

coderabbitai Bot commented Jul 2, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

📝 Walkthrough

Walkthrough

Dependabot target branches switched from development to main. CI workflow push trigger narrowed to main only. Publish workflow trigger changed from production branch push to git tag push (v*), with added tag/version verification and release creation using the triggering tag instead of creating a new tag.

Changes

CI/CD Configuration Migration

Layer / File(s) Summary
Branch targeting update
.github/dependabot.yml, .github/workflows/ci.yml
Dependabot update entries and CI push trigger now target main instead of development/production.
Tag-based publish workflow
.github/workflows/publish.yml
Publish trigger changed to tag pushes matching v*; adds a verification step comparing the tag to package.json version and uses the triggering tag for release creation, removing prior tag creation/push logic.

Estimated code review effort: 2 (Simple) | ~10 minutes

Possibly related PRs

Suggested labels: enhancement

Poem

A hop, a skip, a tag applied,
No more branches left to hide,
Main is now our only trail,
Releases ride the git-tag rail,
Thump-thump! Ship it, never fail. 🐇🏷️

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly summarizes the main workflow shift to trunk-based releases with tag-driven publishing and a single main branch.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch chore/trunk-based-release

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

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

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (1)
.github/workflows/publish.yml (1)

73-76: 🔒 Security & Privacy | 🔵 Trivial | 🏗️ Heavy lift

Consider switching this publish job to npm Trusted Publishing (OIDC)

The workflow still uses secrets.NPM_TOKEN via NODE_AUTH_TOKEN. Trusted Publishing would remove the long-lived secret, but it needs id-token: write in this job and npm-side trusted publisher setup.

🤖 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/publish.yml around lines 73 - 76, The Publish to npm job
still relies on NODE_AUTH_TOKEN from secrets.NPM_TOKEN instead of npm Trusted
Publishing. Update the publish workflow job to use OIDC by adding id-token:
write to the job permissions, remove the NPM_TOKEN-based env setup from the
Publish to npm step, and keep the publish command in the publish job aligned
with npm Trusted Publishing requirements.

Source: Linters/SAST tools

🤖 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/publish.yml:
- Around line 66-71: The tag verification step in the publish workflow is
vulnerable because github.ref_name is interpolated directly into the shell
script body. Move the tag value into an env variable for the run step in the
Verify tag matches package version block, then compare that variable against
steps.pkg.outputs.version inside the shell script without direct template
expansion. Keep the existing check logic, but reference the env-bound value
instead of github.ref_name in the script.

---

Nitpick comments:
In @.github/workflows/publish.yml:
- Around line 73-76: The Publish to npm job still relies on NODE_AUTH_TOKEN from
secrets.NPM_TOKEN instead of npm Trusted Publishing. Update the publish workflow
job to use OIDC by adding id-token: write to the job permissions, remove the
NPM_TOKEN-based env setup from the Publish to npm step, and keep the publish
command in the publish job aligned with npm Trusted Publishing requirements.
🪄 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: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 7bf4e992-f7e6-4789-b596-c79199ee5931

📥 Commits

Reviewing files that changed from the base of the PR and between 5c1d039 and 271fa4d.

📒 Files selected for processing (3)
  • .github/dependabot.yml
  • .github/workflows/ci.yml
  • .github/workflows/publish.yml
💤 Files with no reviewable changes (1)
  • .github/workflows/ci.yml

Comment on lines +66 to +71
- name: Verify tag matches package version
run: |
if [ "${{ github.ref_name }}" != "v${{ steps.pkg.outputs.version }}" ]; then
echo "❌ Tag ${{ github.ref_name }} does not match package.json version v${{ steps.pkg.outputs.version }}."
exit 1
fi

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔒 Security & Privacy | 🟠 Major | ⚡ Quick win

Shell injection via unescaped github.ref_name interpolation.

${{ github.ref_name }} is spliced directly into the run: script body. A maliciously crafted tag name (e.g. containing quotes/backticks) can break out of the string and inject arbitrary shell commands that run with access to NPM_TOKEN/GITHUB_TOKEN. Pass the value via env instead of direct template expansion.

🔒 Proposed fix
       - name: Verify tag matches package version
+        env:
+          REF_NAME: ${{ github.ref_name }}
+          PKG_VERSION: ${{ steps.pkg.outputs.version }}
         run: |
-          if [ "${{ github.ref_name }}" != "v${{ steps.pkg.outputs.version }}" ]; then
-            echo "❌ Tag ${{ github.ref_name }} does not match package.json version v${{ steps.pkg.outputs.version }}."
+          if [ "$REF_NAME" != "v$PKG_VERSION" ]; then
+            echo "❌ Tag $REF_NAME does not match package.json version v$PKG_VERSION."
             exit 1
           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.

Suggested change
- name: Verify tag matches package version
run: |
if [ "${{ github.ref_name }}" != "v${{ steps.pkg.outputs.version }}" ]; then
echo "❌ Tag ${{ github.ref_name }} does not match package.json version v${{ steps.pkg.outputs.version }}."
exit 1
fi
- name: Verify tag matches package version
env:
REF_NAME: ${{ github.ref_name }}
PKG_VERSION: ${{ steps.pkg.outputs.version }}
run: |
if [ "$REF_NAME" != "v$PKG_VERSION" ]; then
echo "❌ Tag $REF_NAME does not match package.json version v$PKG_VERSION."
exit 1
fi
🧰 Tools
🪛 zizmor (1.26.1)

[error] 68-68: code injection via template expansion (template-injection): may expand into attacker-controllable code

(template-injection)


[info] 68-68: code injection via template expansion (template-injection): may expand into attacker-controllable code

(template-injection)


[error] 69-69: code injection via template expansion (template-injection): may expand into attacker-controllable code

(template-injection)


[info] 69-69: code injection via template expansion (template-injection): may expand into attacker-controllable code

(template-injection)

🤖 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/publish.yml around lines 66 - 71, The tag verification
step in the publish workflow is vulnerable because github.ref_name is
interpolated directly into the shell script body. Move the tag value into an env
variable for the run step in the Verify tag matches package version block, then
compare that variable against steps.pkg.outputs.version inside the shell script
without direct template expansion. Keep the existing check logic, but reference
the env-bound value instead of github.ref_name in the script.

Source: Linters/SAST tools

@devCluna
devCluna changed the base branch from production to main July 2, 2026 18:36
@devCluna
devCluna merged commit 8a0a6af into main Jul 2, 2026
2 of 3 checks passed
@devCluna
devCluna deleted the chore/trunk-based-release branch July 2, 2026 18:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant