feat: autoversioned releases via release-please#11
Conversation
Replaces "type a version number" with conventional-commits-driven version computation. Maintainer keeps the merge gate; bot does the bookkeeping. How the loop changes: - Merge PRs with conventional titles (feat:, fix:, chore:, ...) - Bot opens "release: vX.Y.Z" PR with package.json bump + CHANGELOG - Review the PR, merge → tag + GitHub Release auto-created - Major-version pointer (v1, v2) auto-moved so consumers pinning @v1 get non-breaking upgrades Files added: - .github/workflows/release-please.yml — release-please-action v4 + a follow-up job that force-pushes the v<major> moving tag (the action does not move it by default). - .github/workflows/lint-pr-title.yml — amannn/action-semantic-pull- request@v5 as a non-blocking status check, so non-conventional titles surface visibly (they would silently skip CHANGELOG entries). - release-please-config.json — single-package config (root is source of truth; workspaces stay at 0.0.0 since they are private and never published). bump-minor-pre-major: true so 0.x stays 0.x until the Release-As: 1.0.0 graduation commit. - .release-please-manifest.json — bootstrap state at "0.0.0"; the bot will write the released version back here on each release. README has a new "Releasing (maintainers)" section explaining: - Conventional commit prefixes and what they bump - The release-please review-and-merge loop - How to graduate 0.x -> 1.0.0 via Release-As: 1.0.0 in a commit body - Branch-protection gotcha for the default GITHUB_TOKEN
|
Caution Review failedPull request was closed or merged during review 📝 WalkthroughWalkthroughAdds CI/CD infrastructure: a release-please automated release workflow (with tag management), a PR-title linting workflow, Release Please config/manifest, Dependabot config for GitHub Actions, and expanded "Releasing (maintainers)" docs in README. ChangesRelease Infrastructure Setup
Sequence Diagram(s)sequenceDiagram
participant Dev as Developer
participant GH as GitHub Actions
participant RP as release-please action
participant Repo as Repository
Dev->>GH: merge PR / push to main
GH->>RP: run release-please with config & manifest
RP->>GH: outputs (release_created, tag_name, major)
alt release_created == "true"
GH->>Repo: checkout full history (move-major-tag)
GH->>Repo: force-update `v<major>` -> `tag_name`
Repo->>GH: push updated `v<major>` tag to origin
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 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 unit tests (beta)
Review rate limit: 9/10 reviews remaining, refill in 6 minutes. Comment |
![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 the current code and only fix it if needed.
Inline comments:
In @.github/workflows/release-please.yml:
- Around line 13-15: The workflow's permissions block is missing the required
issues permission; update the permissions mapping by adding the key "issues:
write" alongside "contents: write" and "pull-requests: write" under the
permissions section so the release-please action can create/link issues
correctly (modify the permissions block to include the "issues" entry).
🪄 Autofix (Beta)
❌ Autofix failed (check again to retry)
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: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 920c092d-2a6c-49ad-be93-0250868d8f77
📒 Files selected for processing (5)
.github/workflows/lint-pr-title.yml.github/workflows/release-please.yml.release-please-manifest.jsonREADME.mdrelease-please-config.json
|
Note Autofix is a beta feature. Expect some limitations and changes as we gather feedback and continue to improve it. ⛔ CodeRabbit does not have permission to push changes to this repository. Please ensure CodeRabbit has Contents: Read and write permission. |
release-please-action needs issues: write to manage release-related issues (label management, issue linking on PR-only releases). Documented in the action's README under permissions; without it some flows that comment on issues silently fail. Refs #11 (comment)
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-please.yml:
- Line 33: Replace the use of the built-in GITHUB_TOKEN in the release-please
job by using a dedicated bot token secret (e.g., change the token entry that
currently reads token: ${{ secrets.GITHUB_TOKEN }} to reference a repo secret
like token: ${{ secrets.RELEASE_PLEASE_TOKEN }}), ensure that the specified
secret exists and contains a Personal Access Token or app token with repo
permissions, and keep the job name/uses (release-please) intact so downstream CI
can be triggered by the created release PRs.
- Line 30: Replace the loose tag "uses: googleapis/release-please-action@v4"
with an immutable commit SHA for the release-please action in both occurrences
so the workflow is pinned to a specific commit (find the latest commit SHA on
the googleapis/release-please-action repo and substitute it into the "uses:"
value); update both instances of the string
"googleapis/release-please-action@v4" and add/ensure Dependabot or Renovate is
configured to automatically propose updates when you want to rotate the pinned
SHAs.
🪄 Autofix (Beta)
❌ Autofix failed (check again to retry)
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: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: bc97a45a-0cf0-4f24-a38a-0a63e37394b0
📒 Files selected for processing (1)
.github/workflows/release-please.yml
| tag_name: ${{ steps.rp.outputs.tag_name }} | ||
| major: ${{ steps.rp.outputs.major }} | ||
| steps: | ||
| - uses: googleapis/release-please-action@v4 |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
What is GitHub’s current guidance on pinning third-party GitHub Actions by full-length commit SHA versus major tags (e.g., @v4) for supply-chain security?
💡 Result:
GitHub's current guidance strongly recommends pinning third-party GitHub Actions to full-length commit SHAs for optimal supply-chain security, rather than using major version tags like @v4. This is because SHAs provide immutability, preventing attacks where tags are rewritten to point to malicious commits (e.g., incidents like tj-actions/changed-files and aquasecurity/trivy-action). Tags are mutable and can be force-pushed by maintainers or attackers with repo access. For first-party GitHub actions (e.g., actions/checkout), major tags may be acceptable if the creator is trusted, but SHA pinning is still the most secure and recommended practice universally. GitHub provides org/repo policies to enforce SHA pinning, and tools like Dependabot for updates. Add version comments (e.g., # v4) for maintainability. Example: uses: actions/checkout@93cb6ef # v5
Citations:
- 1: https://docs.github.com/en/actions/reference/security/secure-use
- 2: https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions?learn=getting_started&learnProduct=actions
- 3: https://github.blog/security/supply-chain-security/securing-the-open-source-supply-chain-across-github
- 4: https://github.blog/changelog/2025-08-15-github-actions-policy-now-supports-blocking-and-sha-pinning-actions/
- 5: https://github.blog/changelog/2025-08-15-github-actions-policy-now-supports-blocking-and-sha-pinning-actions
🏁 Script executed:
cat -n .github/workflows/release-please.yml | head -50Repository: znat/gitpulse
Length of output: 1803
🏁 Script executed:
rg "uses:" .github/workflows/release-please.ymlRepository: znat/gitpulse
Length of output: 141
Pin GitHub Actions to immutable commit SHAs.
On lines 30 and 44, actions are pinned only to @v4. This leaves the release pipeline exposed to upstream tag retargeting risk, where tags can be rewritten to point to malicious commits. Pin to full commit SHAs and rotate via Dependabot/Renovate for automatic updates.
Suggested fix
- - uses: googleapis/release-please-action@v4
+ - uses: googleapis/release-please-action@<full_commit_sha>
...
- - uses: actions/checkout@v4
+ - uses: actions/checkout@<full_commit_sha>🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/release-please.yml at line 30, Replace the loose tag
"uses: googleapis/release-please-action@v4" with an immutable commit SHA for the
release-please action in both occurrences so the workflow is pinned to a
specific commit (find the latest commit SHA on the
googleapis/release-please-action repo and substitute it into the "uses:" value);
update both instances of the string "googleapis/release-please-action@v4" and
add/ensure Dependabot or Renovate is configured to automatically propose updates
when you want to rotate the pinned SHAs.
| - uses: googleapis/release-please-action@v4 | ||
| id: rp | ||
| with: | ||
| token: ${{ secrets.GITHUB_TOKEN }} |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
For github.com/googleapis/release-please-action@v4, does using GITHUB_TOKEN prevent workflows from triggering on release PR create/update events, and is a PAT/app token recommended when CI must run on release PRs?
💡 Result:
Yes, using the default GITHUB_TOKEN with github.com/googleapis/release-please-action@v4 prevents workflows from triggering on events from the release PRs (create/update) that it creates. This is due to GitHub's default behavior where events triggered by GITHUB_TOKEN do not create new workflow runs to prevent recursive loops. A Personal Access Token (PAT) is recommended in the official documentation if CI workflows must run on those release PRs. Configure the PAT as a repository secret and pass it to the action via the token input (e.g., token: ${{ secrets.MY_RELEASE_PLEASE_TOKEN }}). GitHub App tokens are also an option (similar to PATs for triggering workflows), though the docs primarily highlight PATs.
Citations:
- 1: http://github.com/GoogleCloudPlatform/release-please-action
- 2: https://github.com/googleapis/release-please-action
- 3: https://github.com/marketplace/actions/release-please-action
- 4: https://github.com/googleapis/release-please-action?tab=readme-ov-file
Use a non-GITHUB_TOKEN bot token for release-please PR creation.
On line 33, release-please uses ${{ secrets.GITHUB_TOKEN }}. GitHub prevents workflows from triggering on events created by GITHUB_TOKEN (a default anti-recursion behavior), which will block downstream CI workflows that need to run on release PRs.
Suggested fix
- token: ${{ secrets.GITHUB_TOKEN }}
+ token: ${{ secrets.RELEASE_PLEASE_TOKEN }}Use a Personal Access Token or GitHub App token configured as a repository secret instead.
📝 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.
| token: ${{ secrets.GITHUB_TOKEN }} | |
| token: ${{ secrets.RELEASE_PLEASE_TOKEN }} |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/release-please.yml at line 33, Replace the use of the
built-in GITHUB_TOKEN in the release-please job by using a dedicated bot token
secret (e.g., change the token entry that currently reads token: ${{
secrets.GITHUB_TOKEN }} to reference a repo secret like token: ${{
secrets.RELEASE_PLEASE_TOKEN }}), ensure that the specified secret exists and
contains a Personal Access Token or app token with repo permissions, and keep
the job name/uses (release-please) intact so downstream CI can be triggered by
the created release PRs.
|
Note Autofix is a beta feature. Expect some limitations and changes as we gather feedback and continue to improve it. ⛔ CodeRabbit does not have permission to push changes to this repository. Please ensure CodeRabbit has Contents: Read and write permission. |
|
| Filename | Overview |
|---|---|
| .github/workflows/release-please.yml | Introduces release-please automation with two jobs; third-party action is SHA-pinned but actions/checkout@v4 in move-major-tag (which has contents: write) is still a mutable tag. |
| .github/workflows/lint-pr-title.yml | Adds PR title linting via amannn/action-semantic-pull-request SHA-pinned; minimal permissions (pull-requests: read); clean. |
| .github/dependabot.yml | Configures weekly Dependabot updates for GitHub Actions with chore prefix; straightforward and correct. |
| release-please-config.json | Single-package node config with bump-minor-pre-major: true and bump-patch-for-minor-pre-major: true; correctly matches README docs for pre-1.0 versioning behavior. |
| .release-please-manifest.json | Bootstrap manifest at "0.0.0"; correct starting point for release-please to track version state. |
| README.md | Replaces manual release steps with dual-path release docs (release-please + hotfix manual flow); accurately describes both paths and the GITHUB_TOKEN downstream-trigger trade-off. |
Sequence Diagram
sequenceDiagram
participant Dev as Developer
participant GH as GitHub (main)
participant RP as release-please-action
participant Bot as release-please bot
participant Tag as move-major-tag job
Dev->>GH: Push feat:/fix: commit to main
GH->>RP: Trigger release-please workflow
RP->>Bot: Compute version bump from commits
Bot->>GH: Open/update "chore(main): release vX.Y.Z" PR
Dev->>GH: Review & merge release PR
GH->>RP: Trigger release-please workflow (merge commit)
RP->>GH: Create vX.Y.Z tag + GitHub Release
RP-->>Tag: release_created=true → trigger move-major-tag
Tag->>GH: git tag -f vX vX.Y.Z && git push --force
Reviews (3): Last reviewed commit: "Merge remote-tracking branch 'origin/mai..." | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
…ken trade-off Addresses review feedback from CodeRabbit (#11 review 4214872615) and Greptile (#11 issuecomment 4363712934): - Pin googleapis/release-please-action and amannn/action-semantic-pull- request to immutable commit SHAs. v-tags are mutable and a moved tag could ship malicious code without warning. SHAs paired with Dependabot give us reproducibility + automated rotation PRs. - Add .github/dependabot.yml with weekly github-actions ecosystem updates so the pinned SHAs don't go stale. Renovate-style rotation via PRs that we can review. - Flip release-please-config.json `bump-patch-for-minor-pre-major` to true so `fix:` commits trigger patch bumps in 0.x — matches what the README documents. Greptile correctly flagged the contradiction between config and README. - Document the GITHUB_TOKEN trade-off inline in release-please.yml: using the default token means the release PR's merge and the created GitHub Release won't trigger downstream `push` / `release: published` workflows. Acceptable for a simple setup; users who care can swap in a fine-grained PAT with contents:write + pull-requests:write. - Document why issues:write is required (release-please writes the autorelease:* labels via the issues API). CodeRabbit suggested adding it; Greptile flagged it as unnecessary — the doc resolves the apparent conflict. It is required for label management. Refs: - #11 (review) - #11 (comment)
|
Pushed CodeRabbit (review):
Greptile (summary):
Tests still 94/94 green; no code changed. |
There was a problem hiding this comment.
♻️ Duplicate comments (1)
.github/workflows/release-please.yml (1)
37-43:⚠️ Potential issue | 🟠 Major | ⚡ Quick win
GITHUB_TOKENat Line 43 blocks downstream release-triggered workflows.If you need self-deploy/CI to run from release-please-created
push/releaseevents, switch to a PAT/App token secret; otherwise the current setup won’t trigger those workflows.Suggested fix
- token: ${{ secrets.GITHUB_TOKEN }} + token: ${{ secrets.RELEASE_PLEASE_TOKEN }}References:
- https://docs.github.com/en/actions/how-tos/writing-workflows/choosing-when-your-workflow-runs/triggering-a-workflow
- https://github.com/googleapis/release-please-action
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release-please.yml around lines 37 - 43, The workflow is using the default GITHUB_TOKEN which prevents downstream workflows from being triggered; replace token: ${{ secrets.GITHUB_TOKEN }} with a repository secret holding a fine-grained PAT or App token (e.g. token: ${{ secrets.RELEASE_PAT }}), ensure that secret has the required scopes/permissions (contents: write and pull-requests: write or equivalent app permissions), and document the secret name and required scopes in the workflow comment so maintainers can create the token in repo settings.
🤖 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-please.yml:
- Around line 37-43: The workflow is using the default GITHUB_TOKEN which
prevents downstream workflows from being triggered; replace token: ${{
secrets.GITHUB_TOKEN }} with a repository secret holding a fine-grained PAT or
App token (e.g. token: ${{ secrets.RELEASE_PAT }}), ensure that secret has the
required scopes/permissions (contents: write and pull-requests: write or
equivalent app permissions), and document the secret name and required scopes in
the workflow comment so maintainers can create the token in repo settings.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 81771b26-1f76-445d-b982-9fa6b2e7a90a
📒 Files selected for processing (4)
.github/dependabot.yml.github/workflows/lint-pr-title.yml.github/workflows/release-please.ymlrelease-please-config.json
# Conflicts: # README.md
1 participant
Replaces "type a version number" with conventional-commits-driven version computation. Maintainer keeps the merge gate; bot does the bookkeeping.
How the loop changes
Both paths can coexist. PR #9's `release.yml` (manual) stays as a hotfix escape hatch.
What's added
What gets bumped
`package.json` (root) — `version` field updated by the bot in its release PR. Workspaces (`action/package.json`, `site/package.json`) intentionally stay at `0.0.0` because they're `private: true` and never published. CHANGELOG.md is created on first release.
Conventional commit prefixes
Going from 0.x to 1.0.0
Add a commit on `main` whose body contains `Release-As: 1.0.0`. Next release-please run uses that exact version.
Test plan
Summary by CodeRabbit
Chores
Documentation