Skip to content

Add default release patch+1 to release workflow#48

Merged
ivan-flamingo merged 9 commits into
masterfrom
hotfix/release-auto-patch-bump
Jul 8, 2026
Merged

Add default release patch+1 to release workflow#48
ivan-flamingo merged 9 commits into
masterfrom
hotfix/release-auto-patch-bump

Conversation

@yaroslavmokflmg

@yaroslavmokflmg yaroslavmokflmg commented Jul 6, 2026

Copy link
Copy Markdown

Implements default patch bump for the release workflow.

Description

  • version input is now optional — leave it empty to auto-bump
  • Empty input → patch+1 from the latest release (e.g. 0.0.24 → 0.0.25)
  • Provided input → used as-is (format-validated only)
  • Version resolution via reusable resolve-version composite action

Note

Version read from the latest GitHub Release (not git tag) — tags here contain upstream/fork placeholders that sort -V would mispick. gh release view returns the real Latest. Built-in github.token, no new secrets.

Task

Add Default Release Patch+1 at Every Repository

Summary by CodeRabbit

  • New Features
    • Release builds now automatically determine the next version when one isn’t provided.
    • Manual release runs can now proceed without entering a version upfront.
    • Docker images, Helm charts, and release tags now use the same resolved version for consistency.
  • Bug Fixes
    • Improved release job coordination so packaging and publication steps wait for version resolution before running.

@yaroslavmokflmg yaroslavmokflmg self-assigned this Jul 6, 2026
@coderabbitai

coderabbitai Bot commented Jul 6, 2026

Copy link
Copy Markdown

Review Change Stack

Warning

Review limit reached

@yaroslavmokflmg, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 41 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 31fc0949-9681-4352-aa56-24f057344edf

📥 Commits

Reviewing files that changed from the base of the PR and between e3640e5 and 295966a.

📒 Files selected for processing (2)
  • .github/workflows/release.yml
  • .github/workflows/version.yml
📝 Walkthrough

Walkthrough

Adds 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.

Changes

Reusable Version Resolution Workflow

Layer / File(s) Summary
New version resolution workflow
.github/workflows/version.yml
Adds a reusable workflow with an optional version input and a version output; a job checks out full git history and runs a script that finds the latest semver tag, auto-increments the patch if no input is given, or validates a supplied x.y.z version.
Release workflow wiring to version job
.github/workflows/release.yml
Makes the workflow_dispatch version input optional, adds a version job that calls the reusable workflow, and updates the Docker build, Helm chart build, and release creation jobs to depend on version and use needs.version.outputs.version instead of inputs.version for tags, release headers, and release names.

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
Loading

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)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately reflects the main change: the release workflow now defaults to patch+1 version resolution when no version is provided.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch hotfix/release-auto-patch-bump

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 win

Helm chart tag still uses stale inputs.version instead of resolved version.

Line 148 (tag: ${{ inputs.version || '9.9.9' }}) wasn't updated to use needs.version.outputs.version, unlike the Docker metadata tag at line 98 which was. When inputs.version is left empty (the new default patch-bump flow), this will push the Helm chart with tag 9.9.9 instead 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 value

Template 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 since version.yml validates the value against ^[0-9]+\.[0-9]+\.[0-9]+$ before exporting it, but for defense-in-depth consider passing it via env: 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

📥 Commits

Reviewing files that changed from the base of the PR and between a320fcf and ba09c8d.

📒 Files selected for processing (2)
  • .github/workflows/release.yml
  • .github/workflows/version.yml

Comment thread .github/workflows/version.yml Outdated
ivan-flamingo
ivan-flamingo previously approved these changes Jul 7, 2026
@ivan-flamingo ivan-flamingo enabled auto-merge (squash) July 7, 2026 18:04
@ivan-flamingo ivan-flamingo merged commit 4bdbc2e into master Jul 8, 2026
5 checks passed
@ivan-flamingo ivan-flamingo deleted the hotfix/release-auto-patch-bump branch July 8, 2026 14:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants