Skip to content

Run the macOS binaries job on macos-latest-xlarge #128

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Bencheng21 merged 1 commit into from
Sep 25, 2026
Merged

Run the macOS binaries job on macos-latest-xlarge #128

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion .github/workflows/release.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -303,7 +303,7 @@ jobs:

goreleaser-binaries:
needs: [determine-workflows-ref, release-preflight]
runs-on: macos-latest
runs-on: macos-latest-xlarge

@Bencheng21 Bencheng21 Sep 23, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

permissions:
contents: read
id-token: write # <-- needed for cosign keyless (OIDC)
Expand Down