feat: update version to 0.2.0 and add release configuration files#121
feat: update version to 0.2.0 and add release configuration files#121
Conversation
|
Caution Review failedThe pull request is closed. 📝 WalkthroughWalkthroughAdds GitHub Actions release workflow and release-please configuration/manifest; bumps the Rust package version from 0.1.0 to 0.2.0. Changes
Sequence Diagram(s)sequenceDiagram
participant Dev as Developer
participant GH as GitHub
participant Runner as Actions Runner
participant RP as release-please-action
participant Repo as Repository (manifest/Cargo)
Dev->>GH: push to main
GH->>Runner: trigger "Release" workflow
Runner->>RP: run googleapis/release-please-action (token, config, manifest)
RP->>Repo: read `release-please-config.json` and `.release-please-manifest.json`
RP->>Repo: read extra-file `packages/typescript/package.json` ($.version)
RP->>GH: create/update release PR or tag (via token)
GH->>Repo: persist changes (manifest/Cargo) or open PR
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 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 |
Codecov Report✅ All modified and coverable lines are covered by tests.
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Pull request overview
This PR sets up automated release management using Google's release-please action, bumping the project version from 0.1.0 to 0.2.0 across both the Rust crate and TypeScript SDK.
Changes:
- Updated version to 0.2.0 in Cargo.toml, Cargo.lock, and verified consistency with packages/typescript/package.json
- Added release-please configuration files to enable automated release PR generation and version management
- Created a GitHub Actions workflow that will automatically manage releases on pushes to main branch
Reviewed changes
Copilot reviewed 4 out of 5 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| Cargo.toml | Updated version from 0.1.0 to 0.2.0 |
| Cargo.lock | Updated version from 0.1.0 to 0.2.0 (lockfile sync) |
| release-please-config.json | Configured release-please for Rust release type with TypeScript package version syncing |
| .release-please-manifest.json | Set initial version tracking at 0.2.0 |
| .github/workflows/release.yml | Added automated release workflow (missing required checkout step) |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (4)
.github/workflows/release.yml (2)
15-18: Missingtokeninput —GITHUB_TOKENprevents downstream workflow triggers.Without an explicit
token, the action uses the built-inGITHUB_TOKEN. GitHub intentionally prevents events (push, release) generated byGITHUB_TOKENfrom triggering further workflow runs to avoid recursive loops. The official documentation demonstrates using a PAT configured as a repository secret (e.g.MY_RELEASE_PLEASE_TOKEN) as thetokeninput. If you have — or plan to add — a CI/build/publish workflow triggered byon: pushtomainoron: release, it will not fire on release-please's automated commits/tags without a PAT.💡 Suggested fix
- uses: googleapis/release-please-action@v4 with: + token: ${{ secrets.RELEASE_PLEASE_TOKEN }} config-file: release-please-config.json manifest-file: .release-please-manifest.json🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release.yml around lines 15 - 18, The release-please action invocation (googleapis/release-please-action@v4) is missing the token input so it falls back to GITHUB_TOKEN and prevents downstream workflows from being triggered; update the action block to include a token input that references a repository secret containing a GitHub PAT (for example token: ${{ secrets.MY_RELEASE_PLEASE_TOKEN }}) and ensure that the secret holds a PAT with repo permissions so automated commits/tags from release-please can trigger subsequent push/release workflows.
15-15: Pin the action to a commit SHA instead of the mutable@v4tag.The
@v4tag is mutable — it can be force-pushed to point to a different (potentially malicious) commit. Pinning to the full commit SHA of a specific release is the standard supply-chain hardening approach for third-party Actions.🔒 Example
- - uses: googleapis/release-please-action@v4 + - uses: googleapis/release-please-action@16a9c90856f42705d54a6fda1823352bdc62cf38 # v4.4.0🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release.yml at line 15, Replace the mutable tag reference "googleapis/release-please-action@v4" with a pinned full commit SHA for the googleapis/release-please-action action; locate the workflow step using the string "googleapis/release-please-action@v4" and update it to the specific commit SHA for the desired release to ensure the action is immutable and supply‑chain hardened.release-please-config.json (2)
1-15: Consider addingbootstrap-shato anchor the initial release scan.Without
bootstrap-sha, release-please scans up to the last 250 commits to build the first changelog. You can add a top-level"bootstrap-sha": <full sha value>key/value entry to the config, which will cause release-please to stop there for collecting changelog commits. Without it, the first release PR may include an unexpectedly large changelog from prior work.💡 Suggested addition
{ "$schema": "https://raw.githubusercontent.com/googleapis/release-please/main/schemas/config.json", + "bootstrap-sha": "<SHA of the commit just before the first commit to include>", "packages": {🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@release-please-config.json` around lines 1 - 15, Add a top-level "bootstrap-sha" entry to the release-please configuration to anchor the initial changelog scan; update the JSON in release-please-config.json by adding a "bootstrap-sha": "<full commit SHA>" property at the root so release-please stops collecting commits before that SHA when building the first release PR, preventing an unexpectedly large changelog.
2-2:$schemaURL is pinned to the mutablemainbranch.The
$schemareference resolves live from themainbranch, so schema changes upstream can silently alter IDE validation. Pinning to a tagged release URL is more stable (e.g.,https://raw.githubusercontent.com/googleapis/release-please/v16.x.x/schemas/config.json). This only affects local editor tooling, not the action's runtime behaviour.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@release-please-config.json` at line 2, The $schema entry currently points to the mutable "main" branch; update the "$schema" value to a version-pinned raw URL (for example replace "main" with a release tag such as "v16.x.x") so the schema used by IDEs is stable—locate the "$schema" key in release-please-config.json and change the URL to the tagged release URL (e.g., https://raw.githubusercontent.com/googleapis/release-please/v16.x.x/schemas/config.json).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In @.github/workflows/release.yml:
- Around line 15-18: The release-please action invocation
(googleapis/release-please-action@v4) is missing the token input so it falls
back to GITHUB_TOKEN and prevents downstream workflows from being triggered;
update the action block to include a token input that references a repository
secret containing a GitHub PAT (for example token: ${{
secrets.MY_RELEASE_PLEASE_TOKEN }}) and ensure that the secret holds a PAT with
repo permissions so automated commits/tags from release-please can trigger
subsequent push/release workflows.
- Line 15: Replace the mutable tag reference
"googleapis/release-please-action@v4" with a pinned full commit SHA for the
googleapis/release-please-action action; locate the workflow step using the
string "googleapis/release-please-action@v4" and update it to the specific
commit SHA for the desired release to ensure the action is immutable and
supply‑chain hardened.
In `@release-please-config.json`:
- Around line 1-15: Add a top-level "bootstrap-sha" entry to the release-please
configuration to anchor the initial changelog scan; update the JSON in
release-please-config.json by adding a "bootstrap-sha": "<full commit SHA>"
property at the root so release-please stops collecting commits before that SHA
when building the first release PR, preventing an unexpectedly large changelog.
- Line 2: The $schema entry currently points to the mutable "main" branch;
update the "$schema" value to a version-pinned raw URL (for example replace
"main" with a release tag such as "v16.x.x") so the schema used by IDEs is
stable—locate the "$schema" key in release-please-config.json and change the URL
to the tagged release URL (e.g.,
https://raw.githubusercontent.com/googleapis/release-please/v16.x.x/schemas/config.json).
Summary by CodeRabbit
Chores
Version