Summary

Updated the concurrency group configuration in the CI workflow files to include github.event_name, ensuring that merge runs (push events) and pull request runs (pull_request events) operate in separate concurrency groups and don't cancel each other.

Problem

The previous concurrency group configuration used only github.workflow and github.ref:

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: ${{ contains(github.ref, 'merge')}}

While this typically worked because merge runs and PR runs usually have different refs, it wasn't explicitly guaranteed and could lead to edge cases where different event types might interfere with each other.

Solution

Added github.event_name to the concurrency group:

concurrency:
  group: ${{ github.workflow }}-${{ github.event_name }}-${{ github.ref }}
  cancel-in-progress: ${{ contains(github.ref, 'merge')}}

This creates distinct concurrency groups for different event types:

• Pull request validation: Windows-CI-pull_request-refs/pull/123/merge
• Merge to master: Windows-CI-push-refs/heads/master
• Manual workflow dispatch: Windows-CI-workflow_dispatch-refs/heads/branch-name

Benefits

• ✅ Pull request validation runs and merge runs can execute in parallel without canceling each other
• ✅ Different event types are explicitly isolated in separate concurrency groups
• ✅ Runs of the same event type for the same ref can still cancel each other when appropriate
• ✅ Future-proof against edge cases and workflow trigger changes
• ✅ Consistent behavior across all CI platforms (Windows, Linux, macOS)

Files Changed

• .github/workflows/windows-ci.yml
• .github/workflows/linux-ci.yml
• .github/workflows/macos-ci.yml

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.