fix: auto-bump patch version in release workflow

[rishitank]

Problem

When the Release workflow is triggered by workflow_run (after CI completes on main), it previously skipped the release if the current version tag already existed. This required manual version bumps before each release, which is what happened with PR #3.

Solution

Now, when triggered by workflow_run:

• If current version tag doesn't exist → release with current version (no bump needed)
• If current version tag exists → auto-bump patch version, update Cargo.toml, then release

How It Works

# Before (lines 110-112)
if git tag -l "v$CURRENT_VERSION" | grep -q .; then
  echo "Tag v$CURRENT_VERSION already exists, skipping release"
  echo "should_release=false" >> $GITHUB_OUTPUT

# After (lines 110-118)
if git tag -l "v$CURRENT_VERSION" | grep -q .; then
  echo "Tag v$CURRENT_VERSION already exists, auto-bumping patch version"
  IFS='.' read -r MAJOR MINOR PATCH <<< "$CURRENT_VERSION"
  NEW_VERSION="${MAJOR}.${MINOR}.$((PATCH + 1))"
  echo "should_release=true" >> $GITHUB_OUTPUT
  echo "version=$NEW_VERSION" >> $GITHUB_OUTPUT
  echo "needs_bump=true" >> $GITHUB_OUTPUT

Result

After this change, releases will be fully automatic after merging PRs to main:

1. PR merged to main
2. CI runs and succeeds
3. Release workflow triggered via workflow_run
4. If tag exists → auto-bump patch version in Cargo.toml
5. Build binaries, generate changelog, create release

No more manual version bumps needed!

---

Pull Request opened by Augment Code with guidance from the PR author

Summary by CodeRabbit

Chores

• Enhanced release workflow to automatically increment patch version when an existing version tag is detected, ensuring uninterrupted release automation.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

The release workflow now automatically bumps the patch version when an existing version tag is encountered during workflow runs, rather than skipping the release. The logic parses the current version, increments the patch component, and sets the appropriate release and bump flags accordingly.

Changes

Cohort / File(s)	Summary
Release Workflow Version Bumping Logic .github/workflows/release.yml	Modified the existing version tag handling to auto-bump the patch version (MAJOR.MINOR.PATCH+1) and proceed with release instead of aborting; sets should_release and needs_bump flags accordingly.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

🐰 A version once stuck, now hops with delight,
Patches bump up, the release shines bright,
No more roadblocks when tags collide—
The workflow leaps forward with rabbit-like pride! ✨

Pre-merge checks

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately summarises the main change: auto-bumping the patch version in the release workflow when a version tag already exists, which is the core modification described in the raw summary and PR objectives.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

---

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

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 24e05d6 and 3958928.

📒 Files selected for processing (1)

• .github/workflows/release.yml

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: build

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🏁 Script executed:

cat -n .github/workflows/release.yml | head -150

Repository: rishitank/context-engine

Length of output: 6379

---

🏁 Script executed:

cat -n .github/workflows/release.yml | tail -100

Repository: rishitank/context-engine

Length of output: 4105

---

🏁 Script executed:

cat Cargo.toml | head -20

Repository: rishitank/context-engine

Length of output: 582

---

🏁 Script executed:

# Check if there are any other version validations in the codebase
grep -r "version" .github/workflows/ --include="*.yml" | grep -E "(validate|regex|match|semver)" || echo "No regex-based version validation found"

Repository: rishitank/context-engine

Length of output: 107

---

🏁 Script executed:

# Verify the complete auto-bump logic in both workflow_dispatch and workflow_run contexts
cat -n .github/workflows/release.yml | sed -n '71,92p'

Repository: rishitank/context-engine

Length of output: 1009

---

🏁 Script executed:

# Check how release job handles version tag creation and potential conflicts
cat -n .github/workflows/release.yml | sed -n '433,449p'

Repository: rishitank/context-engine

Length of output: 859

---

Validate version format and prevent concurrent auto-bump conflicts.

The auto-bump logic contains confirmed critical and major issues:

1. Pre-release version handling: If CURRENT_VERSION contains pre-release identifiers (e.g., 1.2.3-beta.1), the version parsing at lines 113 and 73 will fail silently. The IFS='.' split assigns "3-beta" to PATCH, and bash arithmetic treats the non-numeric "3-beta" as 0, resulting in an incorrect version 1.2.1 instead of 1.2.4-beta.1. The workflow supports pre-release versions via inputs.prerelease, making this a real vulnerability.

2. Missing NEW_VERSION validation: After computing NEW_VERSION at line 114, there is no check to verify that tag v$NEW_VERSION does not already exist. Only CURRENT_VERSION is checked at line 110.

3. Race condition with concurrent workflow_run: Multiple workflow_run instances triggered by rapid commits will both read the same CURRENT_VERSION from line 57 before the first job's bump-version step completes, causing both to compute and attempt to push the identical NEW_VERSION. Although the release job at line 441 skips tag creation if it exists, the check job has already output should_release=true for both instances, creating an inconsistent state.

Add version format validation and NEW_VERSION tag existence check before computing the bump.