fix: version bump missing update-sources

[ruromero]

PR Type

Bug fix

---

Description

• Fix version bump workflow missing update-sources step

• Extract and output release version from branch name

• Checkout correct release tag instead of branch

• Add process-resources step after version update

---

Diagram Walkthrough

flowchart LR
  A["Read release branch"] --> B["Extract version from branch name"]
  B --> C["Output version and tag refs"]
  C --> D["Checkout correct release tag"]
  D --> E["Bump to next dev version"]
  E --> F["Process resources"]
  F --> G["Commit and push"]

Loading

File Walkthrough

Relevant files

Bug fix

publish.yaml Extract version from branch and fix checkout ref                  .github/workflows/publish.yaml Extract release version from branch name using parameter expansion Output both version and tag reference as workflow outputs Use extracted tag reference for checkout instead of branch name Add explanatory comments about version derivation logic +8/-2      release.yaml Add process-resources step to release workflow                      .github/workflows/release.yaml Add mvn -B process-resources step after version update Ensures resources are processed during release version bump +1/-0

---

[qodo-code-review]

ⓘ You are approaching your monthly quota for Qodo. Upgrade your plan

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
⚪	Actions output injection Description: The workflow writes untrusted file content (BRANCH from releasebranch.txt) directly into $GITHUB_OUTPUT via echo "branch=$BRANCH" >> "$GITHUB_OUTPUT" (and derived version/ref), which can enable GitHub Actions output injection if the value contains newlines or crafted key/value pairs (e.g., setting additional outputs that influence later steps such as actions/checkout ref selection). publish.yaml [85-91] Referred Code BRANCH=$(cat releasebranch.txt) echo "branch=$BRANCH" >> "$GITHUB_OUTPUT" # Derive release version and tag from branch (e.g. release/v2.0.5 -> 2.0.5, ref v2.0.5) # Checkout the tag so we publish the release version (2.0.5), not the branch tip (2.0.6-SNAPSHOT) VERSION="${BRANCH#release/v}" echo "version=$VERSION" >> "$GITHUB_OUTPUT" echo "ref=v$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 validation: The workflow derives VERSION/ref from releasebranch.txt without validating the branch format or handling missing/empty content, which can cause incorrect refs or hard-to-debug failures. Referred Code BRANCH=$(cat releasebranch.txt) echo "branch=$BRANCH" >> "$GITHUB_OUTPUT" # Derive release version and tag from branch (e.g. release/v2.0.5 -> 2.0.5, ref v2.0.5) # Checkout the tag so we publish the release version (2.0.5), not the branch tip (2.0.6-SNAPSHOT) VERSION="${BRANCH#release/v}" echo "version=$VERSION" >> "$GITHUB_OUTPUT" echo "ref=v$VERSION" >> "$GITHUB_OUTPUT" rm releasebranch.txt - name: Checkout uses: actions/checkout@v5 with: ref: ${{ (github.event_name == 'workflow_run' && steps.releasebranch.outputs.ref) || github.ref }} fetch-depth: 0 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 external input: The branch value read from releasebranch.txt is treated as trusted input and used to construct a git ref (v$VERSION) without sanitization/allowlisting, enabling unexpected ref checkout if the file content is malformed. Referred Code BRANCH=$(cat releasebranch.txt) echo "branch=$BRANCH" >> "$GITHUB_OUTPUT" # Derive release version and tag from branch (e.g. release/v2.0.5 -> 2.0.5, ref v2.0.5) # Checkout the tag so we publish the release version (2.0.5), not the branch tip (2.0.6-SNAPSHOT) VERSION="${BRANCH#release/v}" echo "version=$VERSION" >> "$GITHUB_OUTPUT" echo "ref=v$VERSION" >> "$GITHUB_OUTPUT" rm releasebranch.txt - name: Checkout uses: actions/checkout@v5 with: ref: ${{ (github.event_name == 'workflow_run' && steps.releasebranch.outputs.ref) || github.ref }} fetch-depth: 0 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]

ⓘ You are approaching your monthly quota for Qodo. Upgrade your plan

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
General	Use proper Maven resources goal Replace the ineffective mvn -B process-resources command, which writes to the untracked target/ directory, with mvn -B resources:resources for in-place changes, or remove it. .github/workflows/release.yaml [90] -mvn -B process-resources +mvn -B resources:resources Apply / Chat Suggestion importance[1-10]: 9 __ Why: The suggestion correctly identifies that the mvn -B process-resources command as used is ineffective because it writes to the .gitignore'd target directory, and its changes will not be committed. This points out a fundamental flaw in the PR's logic.	High
	Validate branch name format Validate that the BRANCH variable matches the release/v pattern before extracting the version, and exit with an error if it doesn't. .github/workflows/publish.yaml [89] +if [[ ! $BRANCH =~ ^release/v[0-9]+\.[0-9]+\.[0-9]+$ ]]; then + echo "Error: invalid release branch name '$BRANCH'" >&2 + exit 1 +fi VERSION="${BRANCH#release/v}" Apply / Chat Suggestion importance[1-10]: 7 __ Why: This suggestion correctly identifies a potential failure point and proposes adding validation to make the workflow more robust and provide clearer error messages, which is a good practice for error handling.	Medium
	Specify bash shell for script Explicitly set shell: bash for the multi-line script to ensure Bash parameter expansion works reliably across all runners. .github/workflows/publish.yaml [84-91] +shell: bash run: | BRANCH=$(cat releasebranch.txt) echo "branch=$BRANCH" >> "$GITHUB_OUTPUT" # Derive release version and tag from branch... VERSION="${BRANCH#release/v}" echo "version=$VERSION" >> "$GITHUB_OUTPUT" echo "ref=v$VERSION" >> "$GITHUB_OUTPUT" [To ensure code accuracy, apply this suggestion manually] Suggestion importance[1-10]: 6 __ Why: The suggestion correctly points out that using shell: bash ensures consistent behavior of shell-specific syntax across different runners, improving the workflow's portability and reliability.	Low
More