Add release-please automation#101
Conversation
|
@Mario-SO is attempting to deploy a commit to the impolitecompany Team on Vercel. A member of the Team first needs to authorize it. |
📝 WalkthroughWalkthroughSets up Release Please automation by adding a GitHub Actions workflow, a ChangesRelease Please Automation Setup
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
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)
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 |
![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-please.yml:
- Line 16: The googleapis/release-please-action reference in the
release-please.yml workflow is using a mutable semantic version tag (v4) instead
of being pinned to a specific commit SHA, which creates a security risk. Replace
the `@v4` tag with the full commit SHA for v4.4.1, optionally adding a comment to
indicate the version for maintainability. If possible, consider upgrading to the
latest v5.0.0 version and pinning that to its corresponding commit SHA instead
for access to newer features.
🪄 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: 3a60fd75-05ab-4f07-91db-176b9bfa1828
📒 Files selected for processing (7)
.github/.release-please-manifest.json.github/release-please-config.json.github/workflows/release-please.ymlCONTRIBUTING.mdREADME.mdbuild.zig.zondocs/content/docs/installation.mdx
| name: Release Please | ||
| runs-on: ubuntu-latest | ||
| steps: | ||
| - uses: googleapis/release-please-action@v4 |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
What is the latest commit SHA for googleapis/release-please-action v4?
💡 Result:
As of June 14, 2026, there is no longer a v4 tag for the googleapis/release-please-action repository, as the project has progressed to version 5.0.0 [1]. The latest release associated with the v4 series was v4.4.1 [2][1], which corresponds to commit SHA 5c625bfb5d1ff62eadeeb3772007f7f66fdcf071 [2]. Following the v4.4.1 release, the repository continued to receive commits, including subsequent architectural updates such as the upgrade to Node 24 (commit 46dfc01594fc6ec99626bc73e479c52bdf554f88) [3] leading into the 5.0.0 major release [1]. Consequently, while 5c625bfb5d1ff62eadeeb3772007f7f66fdcf071 is the final commit SHA for the v4.4.1 release [2], the action's main development branch has since moved forward [4][1].
Citations:
- 1: https://github.com/googleapis/release-please-action/releases
- 2: googleapis/release-please-action@16a9c90...5c625bf
- 3: googleapis/release-please-action@46dfc01
- 4: https://github.com/googleapis/release-please-action/blob/main/CHANGELOG.md
🌐 Web query:
GitHub Actions best practices action version pinning commit SHA vs semantic version tags
💡 Result:
For optimal security and stability in GitHub Actions, the best practice is to pin actions to a full-length commit SHA [1][2][3]. Pinning by Commit SHA vs. Semantic Version Tags Pinning to a full-length commit SHA (e.g., actions/checkout@3df4ab1) is the only method that provides an immutable reference [1][4][3]. Because Git tags are mutable and can be moved or deleted by an action's maintainer (or an attacker who compromises the repository), using a tag (e.g., actions/checkout@v4) exposes your workflows to "retargeting" attacks where the code executed by your workflow could change unexpectedly without your knowledge [1][5][3]. Security Implications - Commit SHA: Protects against supply chain attacks where malicious code is pushed to an existing tag or the repository itself [1][3]. It guarantees that the exact code you audited is the code that runs in your runner [4][3]. - Semantic Version Tags: More convenient for receiving automatic updates, but inherently risky unless you strictly trust the creator [1][4]. The "Verified creator" badge in the GitHub Marketplace is a useful signal, but it does not eliminate the risk of an account compromise [1]. Best Practices for Implementation - Mandatory Pinning: Where security is the highest priority, configure organization-level policies to enforce SHA pinning [1][2][3]. This causes any workflow using non-SHA references to fail [2][3]. - Human-Readable Maintenance: To keep pins maintainable, include the version tag as a comment in the workflow file alongside the SHA [3]: - uses: actions/checkout@3df4ab1 # v4.0.0 - Automate Updates: Use dependency management tools like Renovate or Dependabot to automatically update your pinned SHAs [5][3][6]. For example, Renovate offers presets (e.g., helpers:pinGitHubActionDigestsToSemver) that manage the process of keeping SHAs up to date while maintaining a human-readable version reference, significantly reducing manual maintenance burden [5][3]. While major version binding is sometimes recommended to easily consume functional updates, the current industry standard for hardened environments is to treat third-party actions as immutable dependencies by pinning to SHAs [1][3][7].
Citations:
- 1: https://docs.github.com/en/actions/reference/security/secure-use
- 2: https://github.blog/changelog/2025-08-15-github-actions-policy-now-supports-blocking-and-sha-pinning-actions/
- 3: https://architecture.lullabot.com/adr/20260505-pin-github-actions-to-hash/
- 4: https://www.stepsecurity.io/blog/pinning-github-actions-for-enhanced-security-a-complete-guide
- 5: https://emmer.dev/blog/pin-your-github-actions-to-protect-against-mutability/
- 6: https://docs.github.com/en/enterprise-cloud@latest/actions/reference/security/secure-use
- 7: https://github.com/actions/toolkit/blob/main/docs/action-versioning.md
🌐 Web query:
googleapis/release-please-action v4 tag current status 2026
💡 Result:
As of June 14, 2026, the googleapis/release-please-action v4 tag is no longer the current version [1][2]. The project has advanced to version 5.0.0, which was released on April 22, 2026 [3][1]. This major release included a breaking change to upgrade the underlying runtime to Node.js 24 [3][1]. The last minor release within the v4 series was v4.4.1, released on February 20, 2026 [4][5].
Citations:
- 1: https://github.com/googleapis/release-please-action/releases/tag/v5.0.0
- 2: https://github.com/googleapis/release-please-action
- 3: googleapis/release-please-action@v4.4.1...v5.0.0
- 4: https://github.com/googleapis/release-please-action/releases
- 5: https://github.com/googleapis/release-please-action/blob/main/CHANGELOG.md
Pin the action to a specific commit SHA.
The action reference googleapis/release-please-action@v4 is not pinned to a commit hash, which violates the blanket pinning policy. Semantic version tags are mutable and can be redirected by the upstream repository, exposing your workflow to supply-chain attacks where the executed code could change without your knowledge.
Pin to the commit SHA for v4.4.1: googleapis/release-please-action@5c625bfb5d1ff62eadeeb3772007f7f66fdcf071 (optionally add # v4.4.1 as a comment for maintainability).
Note: The v4 series is no longer the latest version. Consider upgrading to v5.0.0 if you need newer features, then pin that version to its commit SHA as well.
🧰 Tools
🪛 zizmor (1.25.2)
[error] 16-16: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 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-please.yml at line 16, The
googleapis/release-please-action reference in the release-please.yml workflow is
using a mutable semantic version tag (v4) instead of being pinned to a specific
commit SHA, which creates a security risk. Replace the `@v4` tag with the full
commit SHA for v4.4.1, optionally adding a comment to indicate the version for
maintainability. If possible, consider upgrading to the latest v5.0.0 version
and pinning that to its corresponding commit SHA instead for access to newer
features.
Source: Linters/SAST tools
|
I found this release-please repo from google thingy, I honestly didnt know about it when you mentioned it, had to do some searching and ask AI about it to learn how it worked. Pretty cool learning this release flow. |
|
@Mario-SO thanks for this! merging now |
2 participants
Summary
Adds release-please automation for source releases.
The workflow watches pushes to
main, opens or updates a release PR from Conventional Commit history, and uses the release PR merge as the manual release decision. The release PR will bump the manifest, changelog,build.zig.zon, and install URLs together.Changes
release-type: simplebuild.zig.zonso the package version tracks the release tagValidation
jqfor release-please JSON fileszig build testSummary by CodeRabbit
Chores
Documentation