feat: Cancel pending deployments on successful production deployment

[BenjaminMichaelis]

Description

Implements automatic cancellation of pending GitHub Actions workflow runs when a production deployment succeeds. This resolves the issue where multiple concurrent deployments could pile up and waste CI/CD resources.

Why This Matters

When developers push code frequently, GitHub Actions queues up multiple workflow runs. Previously, if older code deployed to production while newer code was still building, both would complete—wasting resources and potentially causing confusion about which version is deployed.

With this change, once a production deployment succeeds (confirmed by the smoke test), any pending workflow runs are automatically cancelled, ensuring only necessary CI/CD work runs.

How It Works

1. Developer pushes commits → GitHub Actions triggers workflow
2. Build, test, and dev deployment stages complete
3. Production deployment begins
4. Smoke test validates the deployment is healthy
5. [NEW] Cancel pending workflow runs step:
   • Lists all queued runs of the same workflow
   • Skips the current run (prevents self-cancellation)
   • Cancels each queued run with proper error handling
   • Reports cancellation count in logs
6. Git tag marks successful production deployment

Key Features

• ✅ Only cancels after successful deployment validation (post-smoke test)
• ✅ Safe pagination for handling 100+ queued runs
• ✅ Multiple levels of error handling (transient API failures don't block deployment)
• ✅ Comprehensive logging with commit info for debugging
• ✅ Uses GitHub context variables (resilient to config changes)
• ✅ Excludes current run from cancellation

Code Review History

This implementation was reviewed by independent agents (GPT 5.5 and Opus 4.6) and addresses all critical findings:

• ✅ Replaced hardcoded workflow filename with context.workflow (resilient to renames)
• ✅ Added outer try-catch around API calls (deployment succeeds even if cancellation fails)
• ✅ Fixed pagination logic for correctness
• ✅ Added comprehensive logging for observability
• ✅ Validated YAML syntax

Testing Recommendations

• Push two commits rapidly; verify the first run gets cancelled when the second deploys
• Monitor logs for proper commit info in cancellation messages
• Verify deployment completion is not blocked by API failures

Closes #149

[Copilot]

Pull request overview

Adds post-deployment cleanup to the production deployment workflow so that, after a successful smoke test, older queued workflow runs are cancelled to reduce wasted CI/CD work and avoid deployment confusion.

Changes:

• Grants actions: write permission to enable cancelling workflow runs via the GitHub Actions API.
• Adds a GitHub Script step after the production smoke test to enumerate and cancel queued runs of the same workflow.
• Logs cancellation attempts and continues deployment even if cancellation fails.

Comments suppressed due to low confidence (2)

.github/workflows/Build-Test-And-Deploy.yml:251

• workflow_id for listWorkflowRuns must be a workflow numeric id or the workflow file name/path (e.g. Build-Test-And-Deploy.yml), but context.workflow is the workflow name (here: "Build, Test, and Deploy EssentialCSharp.Web"). This will return 404/no results and prevent cancellations. Consider resolving the workflow id via listRepoWorkflows (matching by context.workflow) or parsing the workflow file from GITHUB_WORKFLOW_REF/context.workflowRef.

                  owner: context.repo.owner,
                  repo: context.repo.repo,
                  workflow_id: context.workflow,
                  status: 'queued',
                  per_page: 100,

.github/workflows/Build-Test-And-Deploy.yml:283

• Pagination here is vulnerable to skipping runs because the script cancels runs while paginating by page. Since cancelling changes each run’s status from queued, the queued-run list shrinks and later items can shift to earlier pages; incrementing page can then miss remaining queued runs (especially when there are >100). Prefer collecting all queued run ids across pages first (read-only), or repeatedly fetching page: 1 until no queued runs remain.

                // Last page has fewer results than requested (pagination)
                if (runs.length < 100) {
                  break;
                }
                page++;
              }