Add default release patch+1 to release workflow#48
Conversation
|
Warning Review limit reached
Next review available in: 41 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughAdds a reusable workflow that resolves a release version from git tags or input, and updates the release workflow to use that resolved version across Docker, Helm, and GitHub Release steps. ChangesReusable Version Resolution Workflow
Estimated code review effort: 2 (Simple) | ~10 minutes Sequence Diagram(s)sequenceDiagram
participant workflow_dispatch
participant version job
participant version.yml
participant build jobs
participant release job
workflow_dispatch->>version job: trigger with inputs.version
version job->>version.yml: call reusable workflow
version.yml->>version.yml: resolve version from tags or input
version.yml-->>version job: output resolved version
version job-->>build jobs: needs.version.outputs.version
build jobs-->>release job: needs.version.outputs.version
release job->>release job: set tag_name, name, VERSION
Related Issues: None found in provided context. Related PRs: None found in provided context. Suggested labels: ci, github-actions Suggested reviewers: None identified from provided context. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ 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 |
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/release.yml (1)
143-152: 🎯 Functional Correctness | 🔴 Critical | ⚡ Quick winHelm chart tag still uses stale
inputs.versioninstead of resolved version.Line 148 (
tag: ${{ inputs.version || '9.9.9' }}) wasn't updated to useneeds.version.outputs.version, unlike the Docker metadata tag at line 98 which was. Wheninputs.versionis left empty (the new default patch-bump flow), this will push the Helm chart with tag9.9.9instead of the resolved auto-bumped version, breaking the core feature this PR introduces and causing the Helm chart tag to diverge from the Docker image tag and the GitHub Release tag.🐛 Proposed fix
- name: Push Chart uses: appany/helm-oci-chart-releaser@v0.5.0 with: name: meshcentral repository: ${{ github.repository }}/helm-charts - tag: ${{ inputs.version || '9.9.9' }} + tag: ${{ needs.version.outputs.version || '9.9.9' }}🤖 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 143 - 152, The Push Chart step is still using the stale inputs.version fallback, so update the Helm OCI releaser in the release workflow to use the resolved version output from the version job instead. Replace the tag value in the appany/helm-oci-chart-releaser step with needs.version.outputs.version so the Helm chart tag matches the Docker metadata and GitHub Release tag, and remove the 9.9.9 fallback from this path.
🧹 Nitpick comments (1)
.github/workflows/release.yml (1)
166-166: 🔒 Security & Privacy | 🔵 Trivial | 💤 Low valueTemplate expansion of job output into shell script (flagged by zizmor).
VERSION="${{ needs.version.outputs.version || 'latest' }}"interpolates directly into the run script. Risk is mitigated sinceversion.ymlvalidates the value against^[0-9]+\.[0-9]+\.[0-9]+$before exporting it, but for defense-in-depth consider passing it viaenv:instead of template interpolation.🛡️ Suggested defense-in-depth fix
- name: Generate release header + env: + RELEASE_VERSION: ${{ needs.version.outputs.version || 'latest' }} run: | - VERSION="${{ needs.version.outputs.version || 'latest' }}" + VERSION="${RELEASE_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 at line 166, The release workflow step is interpolating the version output directly into the shell script, which should be hardened even though it is validated upstream. Update the job in the release workflow to pass needs.version.outputs.version through env: and then reference that environment variable inside the run step instead of template expansion; use the version-related step in the release job as the fix location.Source: Linters/SAST tools
🤖 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/version.yml:
- Around line 23-25: The checkout step in the version workflow is persisting
credentials unnecessarily, which leaves the token available to later steps.
Update the existing actions/checkout configuration in the version job to set
persist-credentials to false alongside fetch-depth, since this job only reads
tags and does not need git credentials after checkout.
---
Outside diff comments:
In @.github/workflows/release.yml:
- Around line 143-152: The Push Chart step is still using the stale
inputs.version fallback, so update the Helm OCI releaser in the release workflow
to use the resolved version output from the version job instead. Replace the tag
value in the appany/helm-oci-chart-releaser step with
needs.version.outputs.version so the Helm chart tag matches the Docker metadata
and GitHub Release tag, and remove the 9.9.9 fallback from this path.
---
Nitpick comments:
In @.github/workflows/release.yml:
- Line 166: The release workflow step is interpolating the version output
directly into the shell script, which should be hardened even though it is
validated upstream. Update the job in the release workflow to pass
needs.version.outputs.version through env: and then reference that environment
variable inside the run step instead of template expansion; use the
version-related step in the release job as the fix location.
🪄 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 Plus
Run ID: 367da9d5-c6f8-499a-8b19-079b6f23d541
📒 Files selected for processing (2)
.github/workflows/release.yml.github/workflows/version.yml
Implements default patch bump for the release workflow.
Description
versioninput is now optional — leave it empty to auto-bump0.0.24 → 0.0.25)resolve-versioncomposite actionNote
Version read from the latest GitHub Release (not
git tag) — tags here contain upstream/fork placeholders thatsort -Vwould mispick.gh release viewreturns the real Latest. Built-ingithub.token, no new secrets.Task
Add Default Release Patch+1 at Every Repository
Summary by CodeRabbit