Switch to doing version bumps as commits instead of PRs

[justindbaur]

🎟️ Tracking

📔 Objective

@withinfocus this will require us to convert the default branch protection to be a ruleset (if it's not already) and to allow an exclusion for the github actions bot (github-actions[bot]). But I think we can apply the rules to both the default branch and to release/*/* I want to start having the same or more security on the release branches that the default branch has.

⏰ Reminders before review

• Contributor guidelines followed
• All formatters and local linters executed and passed
• Written new unit and / or integration tests where applicable
• Protected functional changes with optionality (feature flags)
• Used internationalization (i18n) for all UI strings
• CI builds passed
• Communicated to DevOps any deployment requirements
• Updated any necessary documentation (Confluence, contributing docs) or informed the documentation team

🦮 Reviewer guidelines

• 👍 (:+1:) or similar for great changes
• 📝 (:memo:) or ℹ️ (:information_source:) for notes or general info
• ❓ (:question:) for questions
• 🤔 (:thinking:) or 💭 (:thought_balloon:) for more open inquiry that's not quite a confirmed issue and could potentially benefit from discussion
• 🎨 (:art:) for suggestions / improvements
• ❌ (:x:) or ⚠️ (:warning:) for more significant problems or concerns needing attention
• 🌱 (:seedling:) or ♻️ (:recycle:) for future improvements or indications of technical debt
• ⛏ (:pick:) for minor or nitpick changes

[claude]

Claude finished @justindbaur's task —— View job

---

PR Review: Switch to doing version bumps as commits instead of PRs

Todo List

• Read repository guidelines (CLAUDE.md)
• Examine the modified workflow files
• Review the git diff to understand exact changes
• Analyze security implications of bypassing PR requirements
• Check workflow logic and best practices
• Provide comprehensive review feedback

---

Review Summary

This PR changes the version bump process from creating pull requests to making direct commits to the target branch. The changes are focused and well-implemented, but there are important security and process considerations to address.

📝 Key Changes

.github/workflows/version-bump.yml:

• ❌ Removed: PR creation logic (35 lines removed)
  • Branch creation (git checkout -b ${versionBumpBranch})
  • Remote branch checking logic
  • PR creation via GitHub REST API
  • Force push to separate branch
• ✅ Added: Direct commit and push to current branch (3 lines added)
  • Simplified to git push instead of git push --force --set-upstream
• ✅ Cleaned up: Removed unused environment variables (_EVENT_REF, _INPUT_TYPE, _SENDER_LOGIN)

.github/workflows/pack-and-release.yml:

• 🔧 Fixed: Added missing git fetch --tags command (line 87)
  • This appears to be a bug fix rather than part of the main change

⚠️ Security Implications

This change has significant security implications that need careful consideration:

1. ⚠️ Branch Protection Bypass: The workflow now requires the github-actions[bot] to have permission to push directly to protected branches, bypassing normal PR review processes.

2. ⚠️ Reduced Review Visibility: Version bumps will no longer go through the standard PR review process, reducing visibility into what versions are being released.

3. ⚠️ Potential for Silent Failures: If the version bump logic has issues, they may not be caught without the PR review step.

Recommendation: As mentioned in the PR description, this requires converting branch protection to rulesets with explicit exclusions for github-actions[bot]. Ensure this is implemented before merging.

🎨 Code Quality & Best Practices

Positive aspects:

• ✅ Clean removal of unused code and variables
• ✅ Simplified workflow logic
• ✅ Consistent error handling maintained
• ✅ Git configuration properly set up

Areas for improvement:

• 📝 Line 87 in pack-and-release.yml: There's a syntax error - missing closing backtick in the git fetch --tags command:

  await exec.exec(`git fetch --tags");  // Should be: `git fetch --tags`);

🤔 Process Considerations

1. Rollback Strategy: With direct commits, rolling back problematic version bumps becomes more complex compared to simply closing a PR.

2. Audit Trail: Consider whether the reduced visibility of version changes aligns with your compliance and audit requirements.

3. Testing: Ensure the version bump script (./scripts/UpdatePackageVersion.ps1) is thoroughly tested since failures will now directly impact the main/release branches.

❓ Questions

1. Branch Strategy: How will this work with release branches (release/*/*)? The workflow currently pushes to the current branch - will this work correctly for both main and release branches?

2. Rollback Process: What's the plan for handling cases where a version bump needs to be reverted?

3. Notification: How will team members be notified of version bumps without the PR mechanism?

🔧 Recommended Fixes

Critical:

1. Fix the syntax error in pack-and-release.yml:87
2. Implement branch protection rulesets before merging

Minor:

1. Consider adding a step to create a GitHub issue or discussion for tracking version bumps
2. Add workflow run summaries to improve visibility

Overall Assessment

The implementation is technically sound and achieves the stated goal of streamlining the version bump process. However, the security implications require careful attention to branch protection configuration. The syntax error needs to be fixed before merging.

Recommendation: ⚠️ Request changes to fix the syntax error and confirm branch protection ruleset implementation.

---

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 39.56%. Comparing base (49044aa) to head (46bb264).
⚠️ Report is 6 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #181   +/-   ##
=======================================
  Coverage   39.56%   39.56%           
=======================================
  Files          40       40           
  Lines        1049     1049           
  Branches       85       85           
=======================================
  Hits          415      415           
  Misses        605      605           
  Partials       29       29           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[github-actions]

Checkmarx One – Scan Summary & Details – 56b14217-4aee-4019-b689-acd1bab3c27e

Great job! No new security vulnerabilities introduced in this pull request

[justindbaur]

This is because I want to start putting in more effort for the release notes on these packages and discovered that this was never printing off tags.

[claude]

Claude finished @justindbaur's task —— View job

---

PR Review: Switch to doing version bumps as commits instead of PRs

Todo List

• Read repository guidelines (CLAUDE.md)
• Examine the modified workflow files
• Review the git diff to understand exact changes
• Check if previous syntax error was fixed
• Analyze security implications of bypassing PR requirements
• Check workflow logic and best practices
• Provide comprehensive review feedback

---

Review Summary

This PR successfully changes the version bump process from creating pull requests to making direct commits to the target branch. The implementation is clean and the syntax error from the previous review has been fixed.

✅ What Works Well

Clean Implementation:

• ✅ Fixed Syntax Error: The syntax error in pack-and-release.yml:87 has been resolved in commit c078c1f
• ✅ Simplified Logic: Removed 35 lines of complex PR creation code, replacing with simple git push
• ✅ Proper Cleanup: Removed unused environment variables (_EVENT_REF, _INPUT_TYPE, _SENDER_LOGIN)
• ✅ Maintained Error Handling: Git commit error handling is preserved
• ✅ Consistent Git Config: Proper git user configuration maintained

Workflow Structure:

• ✅ Permissions: Correct permissions maintained (contents: write, pull-requests: write)
• ✅ Action Versions: Uses pinned action versions with SHA hashes (good security practice)
• ✅ Environment Variables: Proper environment variable handling

⚠️ Security & Process Considerations

Branch Protection Impact:

• ⚠️ Critical: This change requires github-actions[bot] to bypass branch protection rules on both main and release/*/* branches
• ⚠️ Ruleset Required: As mentioned in PR description, branch protection must be converted to rulesets with explicit bot exemptions
• ⚠️ Audit Trail: Version bumps will no longer have PR review visibility, reducing the audit trail

Recommendations for Security:

1. Implement Branch Rulesets: Convert branch protection to rulesets before merging this PR
2. Bot Permissions: Ensure github-actions[bot] has minimal necessary permissions
3. Monitor Commits: Set up monitoring/notifications for direct commits to protected branches
4. Testing: Thoroughly test the PowerShell script (./scripts/UpdatePackageVersion.ps1) since failures now directly impact protected branches

📝 Technical Notes

Version Bump Flow (.github/workflows/version-bump.yml:42-86):

• Removed branch creation and PR opening logic (lines 61-119 in original)
• Simplified to direct commit and push (lines 84-86)
• Maintains proper error handling for git operations

Pack and Release Flow (.github/workflows/pack-and-release.yml:87):

• ✅ Bug Fix: Fixed quotes in git fetch --tags command
• Author's note: This enables better release notes generation by ensuring tags are available

Release Process Alignment:

• ✅ Aligns with CLAUDE.md guidelines: "Version bumps happen automatically via workflows"
• ✅ Maintains the established branch strategy (main and release/[Package]/X.Y)

🤔 Process Impact Questions

1. Rollback Strategy: How will problematic version bumps be rolled back without the PR mechanism?
2. Team Notifications: How will team members be notified of version bumps?
3. Release Branch Testing: Has this been tested with release branches (release/*/*)?

📋 Pre-Merge Checklist

Critical (Must Complete):

• Convert branch protection to rulesets with github-actions[bot] exemption
• Test the workflow on a release branch to ensure git push works correctly
• Verify PowerShell script robustness under various scenarios

Recommended:

• Set up monitoring for direct commits to protected branches
• Document the new process in team runbooks
• Consider adding workflow run summaries for better visibility

Overall Assessment

Code Quality: ✅ Excellent - Clean, well-structured changes with proper error handling
Security: ⚠️ Requires careful branch protection configuration
Functionality: ✅ Achieves the stated goal of streamlining version bumps
Process Impact: ⚠️ Significant change to release workflow requiring team alignment

Recommendation: ✅ Approve with conditions - The implementation is solid, but the branch protection ruleset configuration mentioned in the PR description must be completed before merging to ensure security.

---

[claude]

Claude finished @justindbaur's task —— View job

---

PR Review: Switch to doing version bumps as commits instead of PRs

Todo List

• Read repository guidelines (CLAUDE.md)
• Examine the current state of modified workflow files
• Review the git diff to understand exact changes
• Check if previous syntax error was addressed
• Analyze security implications and workflow logic
• Provide comprehensive updated review feedback

---

Review Summary

This PR successfully transitions the version bump process from creating pull requests to making direct commits. The implementation is clean and the previous syntax error has been resolved. However, there are critical security considerations that must be addressed before merging.

✅ What's Working Well

Clean Implementation:

• ✅ Syntax Error Fixed: The syntax error in pack-and-release.yml:87 has been properly resolved (commit c078c1f)
• ✅ Simplified Logic: Removed 35 lines of complex PR creation code, replacing with simple git push
• ✅ Proper Cleanup: Removed unused environment variables (_EVENT_REF, _INPUT_TYPE, _SENDER_LOGIN)
• ✅ Maintained Error Handling: Git commit error handling is preserved
• ✅ Consistent Git Configuration: Proper git user configuration maintained

Technical Quality:

• ✅ Good Commit Structure: Two focused commits addressing specific changes
• ✅ Action Security: Uses pinned action versions with SHA hashes
• ✅ Permission Structure: Maintains appropriate workflow permissions
• ✅ Environment Variable Handling: Clean removal of unused variables

🎯 Key Changes Analysis

version-bump.yml (.github/workflows/version-bump.yml:67-109):

• Removed: Branch creation (git checkout -b ${versionBumpBranch})
• Removed: Remote branch checking logic
• Removed: PR creation via GitHub REST API (35 lines)
• Simplified: git push --force --set-upstream origin HEAD:${versionBumpBranch} → git push
• Added: Direct commit message with clearer success logging

pack-and-release.yml (.github/workflows/pack-and-release.yml:87):

• Fixed: Quote syntax in git fetch --tags command
• Purpose: Enables better release notes generation by ensuring tags are available (as clarified by author)

⚠️ Critical Security Implications

Branch Protection Bypass:

• ⚠️ High Priority: This workflow now requires github-actions[bot] to bypass branch protection on both main and release/*/* branches
• ⚠️ Configuration Required: As mentioned in the PR description, branch protection must be converted to rulesets with explicit bot exclusions
• ⚠️ Risk: If not properly configured, this could either fail or create security vulnerabilities

Process Changes:

• ⚠️ Reduced Visibility: Version bumps no longer go through PR review, reducing audit trail
• ⚠️ Direct Impact: Failures in the PowerShell script (./scripts/UpdatePackageVersion.ps1) now directly affect protected branches
• ⚠️ Rollback Complexity: Rolling back problematic version bumps becomes more complex without PR mechanism

🔧 Required Pre-Merge Actions

Critical (Must Complete Before Merge):

1. Branch Protection Configuration: Convert branch protection to rulesets with github-actions[bot] exemption
2. Test on Release Branch: Verify the workflow works correctly on release branches (release/*/*)
3. Script Validation: Ensure PowerShell version bump script is robust under various scenarios

Recommended:

1. Monitoring Setup: Implement monitoring for direct commits to protected branches
2. Documentation Update: Document the new process in team runbooks
3. Notification Strategy: Plan how team members will be notified of version bumps

📝 Technical Notes

Workflow Logic (.github/workflows/version-bump.yml:73-111):

• Maintains proper error handling for git operations
• Uses GitHub Actions script context correctly
• Proper environment variable passing
• Clean success/failure reporting

Repository Alignment:

• ✅ Aligns with CLAUDE.md: "Version bumps happen automatically via workflows"
• ✅ Supports established branch strategy (main and release/[Package]/X.Y)
• ✅ Maintains semantic versioning approach

🤔 Outstanding Questions

1. Branch Strategy Confirmation: Has this been tested with release branches to ensure git push works correctly?
2. Rollback Process: What's the established procedure for rolling back problematic version bumps?
3. Team Communication: How will the team be notified of version bump commits?

Overall Assessment

Code Quality: ✅ Excellent - Clean, focused changes with proper error handling
Functionality: ✅ Achieves Goals - Successfully streamlines the version bump process
Security: ⚠️ Requires Action - Critical branch protection configuration needed
Process Impact: ⚠️ Significant - Major workflow change requiring team alignment

Recommendation

✅ Approve with Critical Conditions

The implementation is technically sound and achieves the stated objective of simplifying version bumps. However, this PR must not be merged until the branch protection ruleset configuration mentioned in the PR description is completed. The security implications of bypassing branch protection are too significant to overlook.

Action Items for @withinfocus:

1. Convert default branch protection to rulesets
2. Add github-actions[bot] exclusion for version bump commits
3. Apply similar rules to release/*/* branches
4. Test the configuration in a safe environment before applying to production

Once the branch protection configuration is confirmed, this PR will provide a cleaner, more efficient version bump process while maintaining the automated workflow benefits outlined in the repository guidelines.

---

[addisonbeck]

I love how much simpler this is

[withinfocus]

Let's try it out ... usually we find a bug or two once it runs 😜