Run the macOS binaries job on macos-latest-xlarge

[Bencheng21]

One line: run goreleaser-binaries on macos-latest-xlarge.

macos-latest has 3 vCPUs and GoReleaser sizes its build semaphore from
runtime.GOMAXPROCS(0), so the fourth darwin target queues behind the first
three. macos-latest-xlarge is a 6-core M1, so all four build at once.

Measurements

goreleaser-binaries wall-clock in baton-github-test, successful runs only:

runner	n	avg	min	max
macos-latest-xlarge	2	3.99 min	205s	274s
macos-latest (current)	34	5.29 min	218s	462s
macos-latest-large (Intel)	1	6.87 min	412s	412s
macos-26-intel	1	12.82 min	769s	769s

~24% faster. Both Intel tiers are worse than the standard runner.

Why this is safe

macos-latest-xlarge is Apple Silicon, the same architecture as macos-latest
today. The codesigning host and Homebrew prefix are unchanged — that was the
concern with the Intel macos-latest-large label, not this one. The label has
already run green twice in baton-github-test.

Cost

This is not free. Larger runners get no free-minutes allowance on public repos,
so the 77% of macOS release minutes that currently cost nothing become billable.

From the August usage report, org-wide release.yaml:

	minutes	cost
today, macos-latest	2,239	$138.82 gross → $31.31 net (1,734 min free)
macos-latest-xlarge @ $0.16/min	~1,690 (24% faster)	~$270/mo, none free

goreleaser-binaries is 40% of goreleaser wall-time but 84% of its cost, being
the only job on macOS. Worth weighing against the ~1.3 min/release saved.

Blast radius

All 244 baton repos pin @v4. This reaches them only when the floating v4
tag is moved to a release containing it — a separate, deliberate step.

🤖 Generated with Claude Code

[Bencheng21]

1. Bottleneck

I identified goreleaser-binaries as the main bottleneck in our release workflow.

Analysis:
https://claude.ai/code/artifact/8b700e89-d49e-41db-91bd-139c8577dcee?sk=YU2Rq3X6EflpQra5Bv9I4Q

2. Current Runner Limitation

The current runner has 3 cores, but we're building 4 binaries in parallel. This means one of the builds has to wait for a core to become available, depending on which of the other builds finishes first.

macos-latest-xlarge has 5 cores, so all four binary builds should be able to run in parallel without competing for CPU cores.

3. Expected Benefits

Based on my testing, upgrading the runner could reduce the overall release time by approximately 18.2%–35%, depending on the connector.

For example, for baton-servicenow:

• goreleaser-binaries: 7m 30s → 5m 24s
• Total release time: 11m 45s → 9m 40s
• Overall improvement: approximately 18.2%

Workflow run:
https://github.com/ConductorOne/baton-servicenow/actions/runs/35888202348

I expect baton-datadog to see an even more significant improvement because its binary build is currently a larger portion of the overall release time.

4. Cost

Based on our current GitHub Actions usage:

https://github.com/enterprises/ductone/billing/usage?period=4&group=2&customer=24277160&query=product:actions

I estimate that the annual cost would increase from approximately $270 to $870 ( from Jan 2026- present ), which works out to roughly $70/month for the upgraded runner.

Overall, we'd be spending roughly $900 more per year in exchange for an estimated 18%–35% reduction in release time.