Use github-release-actions for CI/CD - #557
Merged
Merged
Conversation
danielemery
added
the
semver:patch
|
Warning Review limit reached
More reviews will be available in 34 minutes and 47 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (5)
📝 WalkthroughWalkthroughThe PR replaces the old ChangesRelease pipeline overhaul
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)
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 |
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #557 +/- ##
=======================================
Coverage 36.30% 36.30%
=======================================
Files 28 28
Lines 942 942
Branches 188 188
=======================================
Hits 342 342
Misses 548 548
Partials 52 52 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Documented the migration from the manual tag-push release model to the semver, label-driven flow from danielemery/github-release-actions (pinned to v0.5.1), adapted for this repo's three artifacts (docker image, helm chart, sentry release). Covers the five-workflow shape, the build-inline-then-retag promotion pattern, resolved design decisions (sentry deploy model, helm re-package, checkout map, monotonic promotion, first-rc), bot self-labelling for Renovate and Dependabot, and a commit/rollout sequence. Co-Authored-By: Claude <noreply@anthropic.com>
First step of the github-release-actions semver migration (PR 1 of the plan in TASKS.md). Splits the old validate-pr.yaml into focused PR checks and prepares the bots for the upcoming required label gate. - validate-pr.yml: gates each PR on exactly one semver:* label via github-release-actions/validate-semver-label - ci.yml: lint + unit tests + Codecov on pull requests - docker-build.yml: builds the image with push:false so Dockerfile or build breakage surfaces at PR time - renovate.json: labels every Renovate PR semver:patch - dependabot.yml: keeps Dependabot for security updates only (open-pull-requests-limit: 0) and labels them semver:patch main.yml is kept as-is for the Codecov badge / base coverage. The label gate is not made a required check here; that is an admin step (F2) taken after the semver:* labels exist. Checked off Phase A (A1-A7) in TASKS.md. Co-Authored-By: Claude <noreply@anthropic.com>
danielemery
force-pushed
the
use-github-release-actions
branch
from
June 16, 2026 15:19
21a2a82 to
23ab9d3
Compare
danielemery
marked this pull request as ready for review
June 16, 2026 15:20
![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
🧹 Nitpick comments (1)
.github/workflows/release-stable.yml (1)
11-14: ⚡ Quick winEnforce “latest RC only” promotion in workflow logic (not docs-only).
Right now an operator can promote an older RC and move
:latestbackwards. Add a pre-check inpre_releasethat rejects promotion unless the provided RC is the highest-rc.Nfor that base 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-stable.yml around lines 11 - 14, Add validation logic in the `pre_release` step of the workflow to enforce that the provided prerelease_version parameter is the highest RC for its base version. Extract the base version and RC number from the provided prerelease_version input, query existing RC tags or releases to determine the highest RC for that base version, and fail the workflow if the provided RC is not the latest. This check should occur before any promotion logic executes, preventing operators from promoting older RCs that would move the latest tag backwards.
🤖 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/ci.yml:
- Line 19: Replace all mutable GitHub Actions version tags with their
corresponding full commit SHAs to eliminate the risk of tag retargeting by
maintainers. In .github/workflows/ci.yml, update the uses entries at lines 19,
22, and 36 for actions/checkout@v6.0.2, actions/setup-node@v6.4.0, and
codecov/codecov-action@v6.0.1 respectively to use their full commit SHAs. In
.github/workflows/docker-build.yml, update the uses entries at lines 20, 23, and
34 for actions/checkout@v6.0.2, actions/setup-node@v6.4.0, and
docker/build-push-action@v7.2.0 respectively to use their full commit SHAs. In
.github/workflows/validate-pr.yml, update the uses entry at line 14 for
danielemery/github-release-actions/validate-semver-label@v0.5.1 to use its full
commit SHA. This ensures deterministic and tamper-resistant workflow runs.
In @.github/workflows/release-candidate.yml:
- Around line 15-17: Change the top-level permissions in the release-candidate
workflow to be read-only by removing `contents: write` and `packages: write`
from the permissions block at lines 15-17, leaving only read permissions. Then
add job-level permissions that grant `contents: write` and `packages: write`
only to the specific jobs that require write access, such as docker-publish and
release creation jobs. Apply the same permission-scoping fix to
`.github/workflows/release-stable.yml` where the identical overly-broad
top-level write permissions exist.
- Line 38: Replace all version tag references in the `uses:` directives with
immutable full commit SHAs to prevent supply-chain drift. In
`.github/workflows/release-candidate.yml`, update the `uses:` action on line 38
(danielemery/github-release-actions/calculate-prerelease-version) and the
corresponding entries on lines 173 and 181 by replacing the mutable version tags
(such as `@v0.5.1`) with their full commit SHA equivalents. Apply the same fix
to all corresponding `uses:` entries in `.github/workflows/release-stable.yml`
that currently use version tags instead of commit SHAs.
In @.github/workflows/release-stable.yml:
- Around line 59-66: Replace all usages of the raw workflow_dispatch input
`inputs.prerelease_version` with the canonicalized output from the `pre_release`
job to eliminate injection risks and ensure consistent formatting. In
.github/workflows/release-stable.yml at line 59, change the RC_TAG environment
variable assignment from using `inputs.prerelease_version` to
`needs.pre_release.outputs.release-tag`. Apply the same fix at lines 75-75 and
103-104 where `inputs.prerelease_version` is referenced directly in shell
commands or other contexts, using the appropriate pre_release job output (either
release-tag or release-version as applicable to each location).
- Around line 1-4: The top-of-file comments in the release-stable workflow
incorrectly state that stable promotion performs "no sourcemap re-upload," but
the sentry-stable step actually downloads and re-uploads sourcemaps under the
stable release name. Update the header comments to accurately reflect this
current behavior by removing or correcting the statement about sourcemap
handling to match what the sentry-stable step actually does.
---
Nitpick comments:
In @.github/workflows/release-stable.yml:
- Around line 11-14: Add validation logic in the `pre_release` step of the
workflow to enforce that the provided prerelease_version parameter is the
highest RC for its base version. Extract the base version and RC number from the
provided prerelease_version input, query existing RC tags or releases to
determine the highest RC for that base version, and fail the workflow if the
provided RC is not the latest. This check should occur before any promotion
logic executes, preventing operators from promoting older RCs that would move
the latest tag backwards.
🪄 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: 60e9bc64-2156-4883-a369-239314054001
📒 Files selected for processing (10)
.github/dependabot.yml.github/workflows/ci.yml.github/workflows/docker-build.yml.github/workflows/release-candidate.yml.github/workflows/release-stable.yml.github/workflows/validate-pr.yaml.github/workflows/validate-pr.ymlCONTRIBUTING.mdREADME.mdrenovate.json
💤 Files with no reviewable changes (1)
- .github/workflows/validate-pr.yaml
danielemery
force-pushed
the
use-github-release-actions
branch
from
June 16, 2026 19:22
23ab9d3 to
5d673d9
Compare
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 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-candidate.yml:
- Around line 59-69: The `.dockerignore` file is a hidden file (starts with `.`)
and will be excluded from the artifacts by default when using
`actions/upload-artifact@v7.0.1` since it excludes hidden files by default.
Either remove `.dockerignore` from the path list in the Upload build artifacts
action if it is not needed in the downloaded artifacts, or add
`include-hidden-files: true` to the `with:` section of the upload-artifact step
if `.dockerignore` is necessary for the build process and should be included.
- Around line 17-19: The release-candidate.yml and release-stable.yml workflows
use different concurrency groups (main and prod-deployment respectively),
allowing RC version calculations and stable promotion cleanup to interleave, and
without queue: max, GitHub Actions skips older pending runs during merge bursts.
In .github/workflows/release-candidate.yml lines 17-19, change the concurrency
group from main to a shared release-specific group name and add queue: max. In
.github/workflows/release-stable.yml lines 23-24, make the identical change to
use the same shared group name and add queue: max. This ensures all release
mutations (version calculation, tag creation, and RC cleanup) serialize through
a single queued lane.
In @.github/workflows/release-stable.yml:
- Around line 66-75: The "Retag prerelease image as stable" step applies both
the stable version tag and the mutable `latest` tag before the `helm-stable` and
`sentry-stable` jobs complete, creating a risk that `latest` points to an
incompletely released version if those jobs fail. Remove the `--tag
"${REGISTRY}/${IMAGE_NAME}:latest"` line from the docker buildx imagetools
create command in this step so it only tags the stable version. Then create a
new `retag-latest` job that depends on `retag-image`, `helm-stable`, and
`sentry-stable`, and have it apply the `latest` tag to the stable image.
Finally, update `post_release` to depend on this new `retag-latest` job to
ensure the latest tag is only applied after all release steps succeed.
🪄 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: ec3756da-ad6f-4690-a04c-04d3b54bd435
📒 Files selected for processing (5)
.github/workflows/publish.yml.github/workflows/release-candidate.yml.github/workflows/release-stable.ymlCONTRIBUTING.mdREADME.md
💤 Files with no reviewable changes (1)
- .github/workflows/publish.yml
✅ Files skipped from review due to trivial changes (1)
- README.md
🚧 Files skipped from review as they are similar to previous changes (1)
- CONTRIBUTING.md
Cut the merge-triggered prerelease pipeline: a labelled PR merge to main now builds and pushes the vX.Y.Z-rc.N docker, helm and sentry-stg artifacts, then tags last via create-prerelease. Deleted the old tag-push publish.yml and its check-version-format usage; no push:tags triggers remain. Co-Authored-By: Claude <noreply@anthropic.com>
Manual workflow_dispatch that promotes a chosen rc to stable without rebuilding: perform-pre-release promotes, the prerelease docker image is retagged to :<stable>+:latest via imagetools, helm is re-packaged from the rc commit, and the rc's persisted sourcemaps are re-uploaded under the stable Sentry release with a prod deploy. perform-post-release publishes the release and cleans up the -rc.N intermediates. Co-Authored-By: Claude <noreply@anthropic.com>
Rewrote the README Deployment section to describe label -> merge -> staging rc -> manual promote-to-stable, replacing the old manual tag-push instructions. Added CONTRIBUTING.md with a Releasing section covering PR labelling, cutting a candidate, promoting via the Release Stable dispatch, and the operator rules (promote the latest rc; pinned infra deploys an exact version, never :latest). Removed the branch's TASKS.md migration plan now that the work is complete. Co-Authored-By: Claude <noreply@anthropic.com>
danielemery
force-pushed
the
use-github-release-actions
branch
from
June 16, 2026 19:48
5d673d9 to
7840dbc
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary by CodeRabbit
Release Notes
New Features
Chores
Documentation