ci: add concurrency groups to prevent duplicate workflow runs

[mkb79]

Problem

The test and release workflows were executed multiple times:

• When pushing to a new branch
• When creating a pull request
• When merging the pull request

This led to unnecessary resource waste and longer CI run times.

Solution

Add concurrency groups with cancel-in-progress: true to both workflows:

• tests.yml
• release.yml

[claude]

Pull Request Review

Summary

This PR adds concurrency groups to the GitHub Actions workflows to prevent duplicate workflow runs. The implementation is clean and follows GitHub Actions best practices.

✅ Positives

1. Correct Implementation

• The concurrency configuration is properly structured and uses the recommended pattern
• Both workflows now have consistent concurrency settings

2. Resource Optimization

• Prevents wasteful duplicate workflow runs when pushing multiple commits rapidly
• Reduces CI queue times and infrastructure costs
• Particularly beneficial for the test workflow which runs a matrix of 14 different job combinations

3. Configuration Choice
The group: ${{ github.workflow }}-${{ github.ref }} pattern is appropriate:

• Creates separate concurrency groups per workflow and branch/PR
• Allows different branches/PRs to run simultaneously while preventing duplicates within the same ref

⚠️ Considerations

1. Release Workflow Cancellation Behavior

For release.yml, there's a potential concern with cancel-in-progress: true:

• The release workflow only triggers on pushes to main/master branches (.github/workflows/release.yml:3-7)
• If multiple commits are pushed to main rapidly (e.g., during a merge train or batch merges), earlier release workflows will be cancelled
• Potential issue: If commit A starts building/releasing but commit B is pushed before A completes, commit A's release will be cancelled and potentially never completed
• This could lead to missing releases or gaps in the release history

Recommendation: Consider using cancel-in-progress: false for the release workflow to ensure every push to main completes its release process:

# .github/workflows/release.yml
concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: false  # Ensure all releases complete

This is especially important since the workflow:

• Detects and tags new versions (.github/workflows/release.yml:41-47)
• Publishes to PyPI (.github/workflows/release.yml:91-94)
• Creates release notes (.github/workflows/release.yml:67-74)

2. Tests Workflow Cancellation

For tests.yml, cancel-in-progress: true is the right choice:

• Test results from outdated commits are not useful
• Cancelling obsolete test runs saves significant resources given the 14-job matrix
• No risk of losing important state

🔒 Security & Performance

Security: ✅ No security concerns

• The concurrency configuration uses only built-in GitHub context variables
• No exposure of secrets or sensitive data

Performance: ✅ Significant improvement

• Reduces redundant test runs
• Faster feedback for developers when pushing multiple commits
• Lower infrastructure costs and CI queue times

📋 Test Coverage

This change is infrastructure-only and doesn't require additional tests. The functionality will be validated through normal workflow execution.

Final Recommendation

Approve with suggestion: The implementation is correct and beneficial. However, I recommend reconsidering cancel-in-progress: false for the release workflow to ensure all releases complete, even if it takes slightly longer. This prevents potential gaps in release history or incomplete PyPI publications.

The test workflow implementation is perfect as-is.

---

Changes needed: Optional - evaluate whether release workflow should use cancel-in-progress: false

Severity: Low - The current implementation will work but may skip releases in edge cases

[claude]

Pull Request Review: CI Concurrency Groups

Summary

This PR adds concurrency groups to prevent duplicate workflow runs in both tests.yml and release.yml. The implementation is sound and addresses a common CI/CD inefficiency.

Code Quality: ✅ Good

Positive Aspects:

1. Clean implementation: The concurrency configuration is correctly placed and follows GitHub Actions best practices
2. Consistent approach: Both workflows use identical concurrency patterns, making maintenance easier
3. Appropriate grouping: Using ${{ github.workflow }}-${{ github.ref }} ensures proper isolation between branches/PRs while preventing duplicates on the same ref

Implementation Details:

The changes add this configuration to both workflows:

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

This means:

• Each workflow run is grouped by workflow name + git reference
• New runs cancel in-progress runs for the same group
• Different branches/PRs run independently

Potential Issues: ⚠️ Minor Consideration

Release Workflow Cancellation

The release.yml workflow runs only on pushes to main/master branches. With cancel-in-progress: true, if commits are pushed to master in quick succession, earlier release builds will be cancelled.

Consideration: Is this the desired behavior for releases? Typically:

• ✅ For tests, cancelling stale runs saves resources (good!)
• ⚠️ For releases, you might want ALL commits to master to complete their release workflow

Recommendation: Consider if release.yml should have cancel-in-progress: false to ensure every commit to master completes its release process. However, if rapid-fire commits to master are rare, the current approach is fine.

Alternative for Release Workflow:

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: false  # Ensure all release builds complete

Security: ✅ No Concerns

No security issues. The concurrency configuration is a standard GitHub Actions feature with no security implications.

Performance: ✅ Improvement

This PR improves performance by:

• Preventing duplicate test runs when pushing multiple commits quickly
• Reducing CI queue time and runner usage
• Cancelling stale runs that are no longer relevant

Testing: ⚠️ Runtime Verification Needed

The changes cannot be unit tested but should be verified by:

1. Pushing multiple commits rapidly to a PR branch
2. Confirming older workflow runs are cancelled
3. Ensuring only the latest run completes

Additional Notes

.claude/settings.json Addition

The PR includes a new .claude/settings.json file that whitelists GitHub CLI commands. This appears to be tooling configuration for Claude Code and is harmless, though it's unrelated to the PR's stated purpose.

Question: Was this file intentionally included, or should it be removed/added in a separate commit?

Verdict: ✅ Approve with Minor Suggestion

The PR successfully addresses the stated problem and follows best practices. The only consideration is whether release workflows should complete all runs rather than cancelling in-progress ones.

Recommended Actions:

1. ✅ Merge as-is if rapid commits to master are rare
2. ⚠️ Consider cancel-in-progress: false for release.yml if you want guaranteed completion of all release builds
3. 🤔 Clarify if .claude/settings.json should be included in this PR

Great work on optimizing the CI pipeline! 🚀

[claude]

Code Review Summary

This PR adds concurrency groups to the tests.yml and release.yml workflows to prevent duplicate runs. Overall, this is a solid improvement that will reduce CI resource usage. Here's my detailed feedback:

✅ Strengths

1. Correct Implementation: The concurrency configuration is properly structured with appropriate group and cancel-in-progress settings.

2. Clear Problem Statement: The PR description clearly articulates the issue (multiple workflow executions) and the solution.

3. Resource Efficiency: This change will significantly reduce wasted CI minutes by canceling outdated workflow runs.

🔍 Analysis

Configuration Review

tests.yml:7-9 and release.yml:9-11

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

Behavior:

• For PRs: Each new push to the same PR will cancel previous runs (✅ desired)
• For pushes to branches: Each new push will cancel previous runs (✅ desired)
• For main/master: Each push will cancel previous runs (⚠️ see consideration below)

⚠️ Considerations

1. Release Workflow Cancellation

For release.yml, which triggers on pushes to main/master, using cancel-in-progress: true could be risky if:

• Multiple commits are pushed to main in quick succession
• A release is in progress when another commit arrives
• The workflow performs critical operations like version tagging or PyPI publishing

Recommendation: Consider whether cancel-in-progress: false might be safer for the release workflow to ensure every main/master commit gets fully processed. Alternatively, if rapid successive commits to main are rare, the current approach is acceptable.

2. Coverage Job Dependency

The tests.yml workflow has a coverage job that depends on the tests job completing. When a workflow is canceled:

• In-progress test matrix jobs will be canceled
• The coverage job won't run (expected behavior)
• This is fine for PR iterations but ensures final PR merges complete fully

3. Consistency with Other Workflows

I noticed other workflows in the repository don't have concurrency controls:

• claude-code-review.yml (triggers on PR open/synchronize)
• uv-lock-maintenance.yml (triggers on pyproject.toml changes)

Suggestion: Consider adding concurrency groups to these workflows as well:

# For claude-code-review.yml
concurrency:
  group: ${{ github.workflow }}-${{ github.event.pull_request.number }}
  cancel-in-progress: true

# For uv-lock-maintenance.yml
concurrency:
  group: ${{ github.workflow }}-${{ github.event.pull_request.number }}
  cancel-in-progress: true

🛡️ Security & Quality

• ✅ No security concerns
• ✅ Follows GitHub Actions best practices
• ✅ Proper YAML syntax and formatting
• ✅ No sensitive data exposed

📊 Test Coverage

This is a workflow configuration change that:

• Cannot be unit tested
• Should be validated through actual CI runs
• Low risk since it only affects workflow scheduling

🎯 Recommendation

APPROVE with suggestions:

1. For immediate merge: The current implementation is safe and will work well for most scenarios.

2. For future consideration:

   • Review whether cancel-in-progress: false is more appropriate for release.yml
   • Add concurrency controls to claude-code-review.yml and uv-lock-maintenance.yml for consistency
   • Monitor the first few CI runs after merge to ensure expected behavior

📝 Minor Notes

• The commit message follows conventional commits format (✅)
• Generated with Claude Code attribution is present (✅)
• PR description is clear and well-structured (✅)

Great work on identifying and fixing this CI efficiency issue!

[claude]

Security Review

Critical Issue Found

Dangerous use of cancel-in-progress: true in release workflow (.github/workflows/release.yml:11)

Problem: The release workflow uses cancel-in-progress: true which creates a race condition vulnerability. If two rapid commits are pushed to main/master, the first release job will be cancelled mid-execution.

Impact: This can cause partial releases where:

• Package artifacts may be uploaded but release notes incomplete
• PyPI publish may be interrupted during upload
• Release tags may be created but builds incomplete
• Inconsistent package versions on PyPI

Recommendation: Remove cancel-in-progress: true from release.yml. Release workflows should complete atomically to ensure consistency. The tests.yml cancellation is appropriate (duplicate test runs can be safely cancelled), but release operations should not be interrupted.

Suggested fix: Set cancel-in-progress: false or remove the line entirely (defaults to false).

---

Note: The tests.yml changes are fine - cancelling duplicate test runs is a safe optimization.