Issue Description

The PR validation and main branch CI workflows currently lack concurrency controls, leading to potential inefficiencies when multiple commits are pushed in rapid succession. This issue tracks the implementation of proper concurrency management and validation that our per-commit Codecov upload approach is optimal.

Background

Current State:

• PR validation triggers on opened, synchronize, reopened events - executing on every commit
• Main branch CI triggers on every push to main
• No concurrency configuration exists in any workflow files
• Codecov uploads occur on every test run via OIDC authentication (use_oidc: true)
• fail_ci_if_error: false prevents upload failures from blocking CI

Codecov Design Validation:
Per Codecov documentation, uploading coverage on every commit is the expected and recommended pattern:

"You should upload code coverage, via CI, to Codecov on every commit in which testing is run. Codecov, in a sense, is recreating your Git tree via these commits and uploads, and is looking for changes in coverage along the branch(es)."

Both main branch AND PR uploads are required for full analysis capabilities:

• Patch coverage: Requires PR uploads to analyze new/modified code
• Project delta: Requires baseline (main) uploads for comparison
• File-level diffs: Requires uploads on both sides of the comparison

Rate Limiting Assessment:

• Codecov does not publish explicit rate limits for coverage uploads
• The architecture is explicitly designed for per-commit uploads
• Risk assessment: Low - the system is built for this usage pattern
• Current configuration includes carryforward: true to handle gaps gracefully

Problem Statement

When developers push multiple commits rapidly to a PR branch:

1. Multiple workflow runs start in parallel
2. Each run consumes GitHub Actions minutes
3. Intermediate commits may have runs that complete after the final commit
4. This can lead to confusing status checks and wasted compute

Proposed Approach

1. Add Concurrency Controls to PR Validation

Add workflow-level concurrency to .github/workflows/pr-validation.yml:

concurrency:
  group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}
  cancel-in-progress: true

Rationale:

• Groups runs by workflow name AND PR branch (github.head_ref)
• cancel-in-progress: true cancels superseded runs immediately
• Falls back to run_id for non-PR events (manual dispatch)
• Does not affect other workflows in the same repository

2. Add Concurrency Controls to Main Branch CI

Add workflow-level concurrency to .github/workflows/main.yml:

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

Rationale:

• Groups runs by workflow name AND ref (main branch)
• cancel-in-progress: false queues rather than cancels (main should complete)
• Ensures only one main branch CI runs at a time
• Prevents race conditions in release-please or artifact uploads

3. Consider Concurrency for Reusable Workflows

Evaluate whether concurrency should be added to called workflows:

• pester-tests.yml - likely not needed (inherits from caller)
• Other reusable workflows - audit for any that might benefit

Files to Modify

Acceptance Criteria

• PR validation workflow cancels in-progress runs when new commits push to the same branch
• Main branch CI queues rather than cancels (preserving coverage baseline uploads)
• Workflow syntax validated (no linting errors)
• Manual testing confirms cancellation behavior works as expected
• Codecov continues to receive uploads and function correctly

Additional Context

GitHub Actions Concurrency Reference:

• Workflow syntax - concurrency
• Concurrency groups are case-insensitive
• Maximum one running + one pending job per concurrency group

Current Codecov Configuration (codecov.yml):

• require_changes: true - Hides comment updates when coverage unchanged
• carryforward: true - Carries forward previous coverage for unflagged runs
• Patch target: 80% (informational)
• Project threshold: 1%

Alternative Approaches Considered: