Skip to content

feat: publish prebuilt universal macOS binary on release#660

Open
nenadvulic wants to merge 2 commits into
danger:masterfrom
nenadvulic:feat/macos-binary-release
Open

feat: publish prebuilt universal macOS binary on release#660
nenadvulic wants to merge 2 commits into
danger:masterfrom
nenadvulic:feat/macos-binary-release

Conversation

@nenadvulic

@nenadvulic nenadvulic commented Jun 4, 2026

Copy link
Copy Markdown

Problem

The existing danger/tap/danger-swift Homebrew formula works locally, but has two issues on CI runners:

  1. brew tap danger/tap requires a git clone via HTTPS — this fails silently on environments with restricted network access (e.g. Xcode Cloud), leaving danger-swift unavailable with no clear error message.

  2. The formula compiles from source (make install) — this takes ~10 minutes and requires Xcode as a build dependency on every clean CI runner.

Solution

This PR adds a release_macos_binary.yml workflow that runs on every tag and:

  1. Builds danger-swift for both arm64 and x86_64
  2. Merges them into a universal binary using lipo
  3. Uploads danger-swift-macos-universal.tar.gz + its SHA256 to the GitHub Release

It also updates Scripts/create_homebrew_tap.sh to generate a formula that installs the prebuilt binary directly — removing the Xcode build dependency and reducing install time from ~10 minutes to a few seconds.

Result

brew install danger/tap/danger-swift  # now takes ~5 seconds

The universal binary works natively on Apple Silicon and under Rosetta (x86_64) without needing arch -arm64 workarounds.

Add release_macos_binary.yml workflow that builds arm64 + x86_64 and
merges them into a universal binary via lipo, then uploads
danger-swift-macos-universal.tar.gz to the GitHub Release.

Update create_homebrew_tap.sh to generate a formula that installs the
prebuilt binary directly instead of compiling from source — reducing
brew install time from ~10 minutes to a few seconds, and removing the
Xcode build dependency from the formula.

@f-meloni f-meloni left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Thanks for the PR! Just a comment

echo "TARBALL=$TARBALL" >> "$GITHUB_ENV"
echo "VERSION=$VERSION" >> "$GITHUB_ENV"

- name: Upload to GitHub Release

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I think we already have a job to create a release today, should we add this to that one instead?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

@f-meloni Good call, i folded the macOS build into create_release.yml as a release-macos job gated on needs: build, so the binary uploads after the release is created.

This also removes a race: both workflows triggered on the same tag and each created the release (gh release create vs action-gh-release). Standalone workflow deleted.

Merge the standalone release_macos_binary.yml into the existing
create_release.yml as a release-macos job gated on needs: build.
Both workflows triggered on the same tag and each created the
release (gh release create vs action-gh-release), racing on it;
ordering the macOS job after build removes that race and keeps all
release logic in one workflow.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants