feat(ci): add basic release workflows#665
Conversation
📝 WalkthroughWalkthroughAdds a composite version-validation action and two GitHub Actions workflows: one to prepare release branches (validate inputs, create branch/tag, pin Rust, bump crate versions, update changelog, open PRs) and one to compute a patch and create/push an annotated release tag. ChangesRelease Automation
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes 🚥 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)
Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. 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: 5
🤖 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/prepare-release.yml:
- Around line 63-74: Make the tag and branch steps idempotent so rerunning the
workflow doesn't fail: for the tag referenced as "${{ inputs.version }}.x" check
whether the tag already exists (e.g., via git rev-parse --verify) and only
create it if missing instead of unconditionally running git tag; for the branch
"release-${{ inputs.version }}" use git checkout -B "release-${{ inputs.version
}}" to recreate/reset the local branch reliably, fetch remote refs first, and
when pushing use a safe update (git push --force-with-lease origin "release-${{
inputs.version }}" or push the tag only if newly created) so the Push internal
tag and release-${{ inputs.version }} branch step becomes rerunnable without
manual cleanup.
- Around line 123-127: The update-version job currently only depends on
validate-version, so it can run and open the next-version PR even if
prepare-release-branch fails; change its dependencies so update-version also
waits for the prepare-release-branch job to complete successfully (add
prepare-release-branch to the needs list for the update-version job), ensuring
update-version will not advance main before a release branch/tag is created.
- Around line 82-86: The checkout step always tries to fetch ref: release-${{
inputs.version }} which fails in dry-run because that remote branch isn't
pushed; replace the single checkout with two conditional steps: one
actions/checkout@v6 step that includes ref: release-${{ inputs.version }} and
runs only when inputs.dry-run is false, and a second actions/checkout@v6 step
without the ref (default checkout of the workflow commit) that runs when
inputs.dry-run is true; update the step names accordingly so later steps use the
same workspace.
In @.github/workflows/release.yml:
- Around line 51-60: The tag is constructed with undefined variable RELEASE and
PATCH isn't exported to the Push tag step; update the Create release tag step to
build the tag using the defined VERSION and the patch from
steps.patch.outputs.patch (e.g., use "${VERSION}.${{ steps.patch.outputs.patch
}}") and export or set PATCH consistently so the Push tag step pushes the exact
same ref (or change the Push tag step to push "${VERSION}.${{
steps.patch.outputs.patch }}" too); ensure both steps reference the same
variables (replace RELEASE with VERSION and either set env PATCH from
steps.patch.outputs.patch or inline the steps.patch.outputs.patch expression in
both steps) so the tag name is correct and consistent.
- Around line 29-44: Patch selection currently uses git describe --tags
--abbrev=0 which returns the nearest tag from HEAD (variable last_tag in the
"Determine patch version" step); change it to explicitly pick the latest tag
matching the requested series ${VERSION}.* (e.g. replace the last_tag assignment
with a command that lists tags filtered by pattern and sorts by version, such as
using git tag --list "${VERSION}.*" --sort=-v:refname | head -n1), then keep the
existing regex/patch logic but add a guard to fail if no matching tag is found
(empty last_tag) so the patch calculation uses the correct series tag instead of
a nearest unrelated tag.
🪄 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: Central YAML (base), Organization UI (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: 5db6a745-9ef7-4156-9be2-6df4dd8c93f0
📒 Files selected for processing (2)
.github/workflows/prepare-release.yml.github/workflows/release.yml
Molter73
force-pushed
the
mauro/ci/releaser
branch
from
21762dc to
6f8a89a
Compare
|
@CodeRabbit review |
✅ Actions performedReview triggered.
|
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
.github/workflows/release.yml (1)
17-21: ⚡ Quick winSerialize release runs per version to avoid dispatch races.
Two manual runs for the same version can overlap and contend on tag creation/push. Add job-level concurrency to make this deterministic.
Proposed refactor
jobs: release: runs-on: ubuntu-24.04 + concurrency: + group: release-${{ inputs.version }} + cancel-in-progress: false env: VERSION: ${{ inputs.version }}🤖 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.yml around lines 17 - 21, Add a job-level concurrency stanza to the "release" job so manual runs for the same VERSION serialize and avoid tag races: under the release job, add a concurrency block like concurrency: { group: "release-${{ inputs.version }}", cancel-in-progress: true } (use the env/variable VERSION or inputs.version to form the group key) so only one release per version runs at a time and in-progress duplicates are canceled.
🤖 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.yml:
- Around line 6-14: The workflow accepts an input named "version" documented as
"<Major>.<minor>" but never validated; add an early workflow step (e.g.,
"Validate version") that checks the "version" input against a strict regex like
^\d+\.\d+$ and fails the job with a clear error message if it doesn't match so
downstream ref/tag creation (where "version" is used to form release-* refs and
tag names) cannot proceed with malformed values; reference the "version" input
name and place the check before any steps that use it (see where refs/tags are
generated in the release flow around the later steps).
---
Nitpick comments:
In @.github/workflows/release.yml:
- Around line 17-21: Add a job-level concurrency stanza to the "release" job so
manual runs for the same VERSION serialize and avoid tag races: under the
release job, add a concurrency block like concurrency: { group: "release-${{
inputs.version }}", cancel-in-progress: true } (use the env/variable VERSION or
inputs.version to form the group key) so only one release per version runs at a
time and in-progress duplicates are canceled.
🪄 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: Central YAML (base), Organization UI (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: 7fc86867-2983-462e-a11d-a6e0e13560e7
📒 Files selected for processing (2)
.github/workflows/prepare-release.yml.github/workflows/release.yml
🚧 Files skipped from review as they are similar to previous changes (1)
- .github/workflows/prepare-release.yml
|
CodeRabbit chat interactions are restricted to organization members for this repository. Ask an organization member to interact with CodeRabbit, or set |
Molter73
force-pushed
the
mauro/ci/releaser
branch
from
6f8a89a to
53cfac9
Compare
|
@CodeRabbit review |
✅ Actions performedReview triggered.
|
There was a problem hiding this comment.
🧹 Nitpick comments (1)
.github/workflows/release.yml (1)
16-18: ⚡ Quick winAdd job concurrency to prevent same-version tag races.
Two manual runs for the same
versioncan compute the same next patch and race ongit tag/git push. Add a per-version concurrency group on this job.Suggested change
jobs: release: + concurrency: + group: release-${{ inputs.version }} + cancel-in-progress: false runs-on: ubuntu-24.04🤖 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.yml around lines 16 - 18, Add a concurrency block to the release job (jobs.release) so manual runs with the same version cannot race on git tag/push: add a concurrency key with a group that is unique per-version (e.g. group: release-${{ github.event.inputs.version }} or whichever input/ref holds the version) and set cancel-in-progress: true; this ensures only one run per version proceeds and others are queued/cancelled.
🤖 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.
Nitpick comments:
In @.github/workflows/release.yml:
- Around line 16-18: Add a concurrency block to the release job (jobs.release)
so manual runs with the same version cannot race on git tag/push: add a
concurrency key with a group that is unique per-version (e.g. group: release-${{
github.event.inputs.version }} or whichever input/ref holds the version) and set
cancel-in-progress: true; this ensures only one run per version proceeds and
others are queued/cancelled.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Central YAML (base), Organization UI (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: c8a335ba-2ea4-4353-82b3-b1195689bb75
📒 Files selected for processing (3)
.github/actions/validate-version/action.yml.github/workflows/prepare-release.yml.github/workflows/release.yml
✅ Files skipped from review due to trivial changes (1)
- .github/actions/validate-version/action.yml
🚧 Files skipped from review as they are similar to previous changes (1)
- .github/workflows/prepare-release.yml
|
CodeRabbit chat interactions are restricted to organization members for this repository. Ask an organization member to interact with CodeRabbit, or set |
Molter73
force-pushed
the
mauro/ci/releaser
branch
from
53cfac9 to
eb795a1
Compare
Since the repository has some pretty strict rules about pushing certain branches, we need to define some basic workflows that will allow us to push them via a robot account. While we are at it, we are also automating some of the additional steps needed for updating and pinning versions TODO: update release.md
Molter73
force-pushed
the
mauro/ci/releaser
branch
from
eb795a1 to
ca4b844
Compare
|
CodeRabbit chat interactions are restricted to organization members for this repository. Ask an organization member to interact with CodeRabbit, or set |
|
@CodeRabbit review |
✅ Actions performedReview triggered.
|
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 `@docs/release.md`:
- Around line 24-27: Add a blank line between the Note paragraph ("**Note**:
This is a fallback method... whenever possible") and the horizontal rule marker
("---") so the trailing `---` is not parsed as a setext heading underline;
alternatively remove the `---` line entirely. Update the block containing the
Note and the `---` marker to ensure there is an empty line separating the
paragraph and the rule.
🪄 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: Central YAML (base), Organization UI (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: 9e6d9e57-7bef-4e03-8e74-31e7e1832e2e
📒 Files selected for processing (4)
.github/actions/validate-version/action.yml.github/workflows/prepare-release.yml.github/workflows/release.ymldocs/release.md
🚧 Files skipped from review as they are similar to previous changes (3)
- .github/actions/validate-version/action.yml
- .github/workflows/release.yml
- .github/workflows/prepare-release.yml
|
CodeRabbit chat interactions are restricted to organization members for this repository. Ask an organization member to interact with CodeRabbit, or set |
|
CodeRabbit chat interactions are restricted to organization members for this repository. Ask an organization member to interact with CodeRabbit, or set |
Stringy
left a comment
Stringy
left a comment
There was a problem hiding this comment.
Some nits, but nothing major; otherwise LGTM
2 participants
Description
Since the repository has some pretty strict rules about pushing certain branches, we need to define some basic workflows that will allow us to push them via a robot account. While we are at it, we are also automating some of the additional steps needed for updating and pinning versions
Checklist
Automated testing
If any of these don't apply, please comment below.
Testing Performed
Since the workflows are only meant to be run manually, testing will happen once this PR is merged and the workflows become available in the
Actionstab. If any fixes are needed after testing, a follow up PR will be created.