Skip to content

fix: auto-bump patch version in release workflow #4

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
rishitank merged 1 commit into from
Jan 5, 2026
Merged

fix: auto-bump patch version in release workflow #4

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 8 additions & 2 deletions .github/workflows/release.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -108,8 +108,14 @@ jobs:

# Check if this version tag already exists
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
echo "Tag v$CURRENT_VERSION already exists, auto-bumping patch version"
# Auto-bump patch version
IFS='.' read -r MAJOR MINOR PATCH <<< "$CURRENT_VERSION"
NEW_VERSION="${MAJOR}.${MINOR}.$((PATCH + 1))"
echo "Auto-bumped to: $NEW_VERSION"
echo "should_release=true" >> $GITHUB_OUTPUT
echo "version=$NEW_VERSION" >> $GITHUB_OUTPUT
echo "needs_bump=true" >> $GITHUB_OUTPUT
Comment on lines +111 to +118
Copy link

@coderabbitai coderabbitai bot Jan 5, 2026

Choose a reason for hiding this comment

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

⚠️ 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.

else
echo "New version v$CURRENT_VERSION detected, will release"
echo "should_release=true" >> $GITHUB_OUTPUT
Expand Down