fix(ci): simplify version handling in release workflow

[odysa]

User description

Summary

Fixes the version extraction error in the release workflow.

Changes:

• Forced version: Use ${{ inputs.force_version }} directly - no file parsing needed
• Automatic version: Use Python's tomllib to parse version after semantic-release modifies it
• Remove redundant "Get version" step that was causing the grep pattern matching issue

Test plan

• Merge and run release workflow with forced version 0.2.0

🤖 Generated with Claude Code

---

PR Type

Bug fix, Enhancement

---

Description

• Simplify version extraction by removing redundant "Get version" step

• Use direct input for forced version instead of file parsing

• Use Python's tomllib to parse version after semantic-release modifies it

• Consolidate version output handling with conditional environment variable

---

Diagram Walkthrough

flowchart LR
  A["Bump version<br/>automatic/forced"] --> B["Extract version<br/>tomllib or input"]
  B --> C["Set step output<br/>version variable"]
  C --> D["Commit and tag<br/>using VERSION env"]
  D --> E["Create GitHub Release<br/>with version tag"]

Loading

File Walkthrough

Relevant files

Bug fix

release.yaml Refactor version extraction and output handling                    .github/workflows/release.yaml Removed redundant "Get version" step that used grep pattern matching Added id: auto_version to automatic version bump step with tomllib parsing Added id: forced_version to forced version bump step with direct output Consolidated version output using conditional environment variable VERSION Updated "Commit and tag" and "Create GitHub Release" steps to use unified version variable +10/-9

---

---

Important

Simplifies version handling in release workflow by using tomllib and removing redundant steps.

• Version Handling:
  • Use ${{ inputs.force_version }} directly for forced versioning, eliminating file parsing.
  • Use Python's tomllib to extract version after semantic-release modifies it.
• Workflow Changes:
  • Remove redundant "Get version" step that caused grep pattern matching issues.
  • Update release.yaml to reflect these changes in version handling and commit/tag steps.

^{This description was created by for 520fcd2. You can customize this summary. It will automatically update as commits are pushed.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to 520fcd2 in 7 seconds. Click for details.

• Reviewed 47 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 0 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

Workflow ID: wflow_R7u3aSFUslbbHIiw

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[qodo-code-review]

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
⚪	Shell injection risk Description: Potential shell command injection: the workflow interpolates ${{ inputs.force_version }} directly into a single-quoted sed expression (sed -i 's/.../version = "${{ inputs.force_version }}"/'), so a malicious value containing a single quote (e.g., 1.2.3' && curl ... #) could break out of quoting and execute arbitrary commands on the runner. release.yaml [48-53] Referred Code - name: Bump version (forced) if: ${{ inputs.force_version }} id: forced_version run: | sed -i 's/^version = ".*"/version = "${{ inputs.force_version }}"/' pyproject.toml echo "version=${{ inputs.force_version }}" >> $GITHUB_OUTPUT
Ticket Compliance
⚪	🎫 No ticket provided Create ticket/issue
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
🟢	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Logging Practices Objective: To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
🔴	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: Missing failure guards: The workflow does not validate that VERSION was successfully extracted/non-empty (e.g., tomllib failure or missing project.version), which can lead to tagging/publishing with an empty or invalid version. Referred Code VERSION=$(python -c "import tomllib; print(tomllib.load(open('pyproject.toml', 'rb'))['project']['version'])") echo "version=$VERSION" >> $GITHUB_OUTPUT - name: Bump version (forced) if: ${{ inputs.force_version }} id: forced_version run: | sed -i 's/^version = ".*"/version = "${{ inputs.force_version }}"/' pyproject.toml echo "version=${{ inputs.force_version }}" >> $GITHUB_OUTPUT - name: Commit and tag env: VERSION: ${{ steps.forced_version.outputs.version || steps.auto_version.outputs.version }} run: | git add pyproject.toml CHANGELOG.md 2>/dev/null || git add pyproject.toml git commit -m "chore(release): bump version to $VERSION" || echo "No changes to commit" git tag -a "v$VERSION" -m "Release v$VERSION" git push origin main --tags Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: Unvalidated input injection: The external input inputs.force_version is written into a single-quoted sed script and to $GITHUB_OUTPUT without sanitization/format-safe handling, enabling quote/newline injection and malformed outputs. Referred Code sed -i 's/^version = ".*"/version = "${{ inputs.force_version }}"/' pyproject.toml echo "version=${{ inputs.force_version }}" >> $GITHUB_OUTPUT Learn more about managing compliance generic rules or creating your own custom rules

Compliance status legend

🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

[qodo-code-review]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
General	Simplify version retrieval from semantic-release Simplify the "Bump version (automatic)" step by using the --print flag with semantic-release version to directly capture the new version number. .github/workflows/release.yaml [40-46] - name: Bump version (automatic) if: ${{ !inputs.force_version }} id: auto_version run: | - semantic-release version --no-push --no-commit - VERSION=$(python -c "import tomllib; print(tomllib.load(open('pyproject.toml', 'rb'))['project']['version'])") + VERSION=$(semantic-release version --no-push --no-commit --print) echo "version=$VERSION" >> $GITHUB_OUTPUT Apply / Chat Suggestion importance[1-10]: 6 __ Why: The suggestion simplifies the workflow by using the --print flag of semantic-release, which is more direct and robust than re-parsing the pyproject.toml file with a separate Python command.	Low
	Improve git add command robustness Refactor the git add command to handle a potentially missing CHANGELOG.md file more cleanly by adding files individually and using --ignore-errors. .github/workflows/release.yaml [55-62] - name: Commit and tag env: VERSION: ${{ steps.forced_version.outputs.version || steps.auto_version.outputs.version }} run: | - git add pyproject.toml CHANGELOG.md 2>/dev/null || git add pyproject.toml + git add pyproject.toml + git add CHANGELOG.md --ignore-errors git commit -m "chore(release): bump version to $VERSION" || echo "No changes to commit" git tag -a "v$VERSION" -m "Release v$VERSION" git push origin main --tags Apply / Chat Suggestion importance[1-10]: 5 __ Why: The suggestion improves the robustness and readability of the git add command by handling the potential absence of CHANGELOG.md more gracefully and explicitly.	Low
	Reuse VERSION env for release tag Reuse the VERSION environment variable in the "Create GitHub Release" step to avoid duplicating the version-selection logic. .github/workflows/release.yaml [72-75] - name: Create GitHub Release + env: + VERSION: ${{ steps.forced_version.outputs.version || steps.auto_version.outputs.version }} uses: softprops/action-gh-release@v2 with: - tag_name: v${{ steps.forced_version.outputs.version || steps.auto_version.outputs.version }} + tag_name: v$VERSION Apply / Chat Suggestion importance[1-10]: 4 __ Why: This suggestion improves consistency and maintainability by reusing the VERSION environment variable, thus avoiding code duplication.	Low
	Use coalesce for fallback Replace the || operator with the coalesce() function for better readability when defining the VERSION environment variable. .github/workflows/release.yaml [56-57] env: - VERSION: ${{ steps.forced_version.outputs.version || steps.auto_version.outputs.version }} + VERSION: ${{ coalesce(steps.forced_version.outputs.version, steps.auto_version.outputs.version) }} Apply / Chat Suggestion importance[1-10]: 3 __ Why: The suggestion improves readability by using the coalesce() function, which is the idiomatic way to handle fallbacks in GitHub Actions expressions.	Low
More