ci: stop cancelling in-flight macOS native-image builds on main

[nielspardon]

Problem

The macOS native-image workflow shares one concurrency group across all pushes to main with cancel-in-progress: true:

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

Because the macOS build is the long pole (~20-25 min), any newer merge to main cancels the in-flight build. When merges cluster (e.g. a dependabot batch, or two PRs landing close together) the earlier runs get cancelled. GitHub folds the resulting cancelled check-run into the commit's checks summary and renders it as a red ✗ 0 / 1 — visually identical to a genuine failure — so main appears to fail intermittently.

This also contradicts the workflow's own documented goal of a "per-merge signal": with cancellation, only the head of a burst actually gets built.

Fix

Drop the concurrency group entirely. Every push to main now builds to completion and produces its own macOS native-image signal. No run is ever cancelled, so each commit shows a real ✓ (or a genuine ✗ only if the native build actually breaks).

Note: cancel-in-progress: false would not fully fix this — with a concurrency group, GitHub keeps only the newest pending run, so bursts of 3+ merges would still cancel the intermediate ones. Removing the group is what eliminates cancellations.

Trade-off

When merges cluster, macOS builds can now run in parallel on the shared GitHub-hosted macOS runner pool rather than collapsing to just the head commit. For this public repo those runners are free; the cost is heavier pool usage during bursts. The weekly backstop and workflow_dispatch triggers are unchanged.

🤖 Generated with AI