Skip to content

fix(build): migrate deprecated brews config to homebrew_casks#2

Merged
howar31 merged 1 commit into
mainfrom
feat/homebrew-formula
Jul 4, 2026
Merged

fix(build): migrate deprecated brews config to homebrew_casks#2
howar31 merged 1 commit into
mainfrom
feat/homebrew-formula

Conversation

@howar31

@howar31 howar31 commented Jul 4, 2026

Copy link
Copy Markdown
Owner

Follow-up to #1: goreleaser's check now fails on the deprecated brews property (main CI is currently red because of it). This migrates the tap publishing to homebrew_casks — the supported path for pre-built binaries:

  • cask lands in the tap's Casks/ directory; skip_upload: auto still keeps prereleases out
  • post-install hook strips the macOS quarantine attribute (release binaries are unsigned)
  • README notes Homebrew support is macOS-only (Linux users: npm / go / release binaries)

Validated locally: goreleaser check passes with no deprecation warnings.

🤖 Generated with Claude Code

goreleaser check now fails on the deprecated brews property; casks are
the supported path for pre-built binaries. The cask strips the macOS
quarantine attribute post-install since release binaries are unsigned.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@howar31
howar31 merged commit bc78181 into main Jul 4, 2026
2 checks passed
@howar31
howar31 deleted the feat/homebrew-formula branch July 4, 2026 08:36

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Code Review

This pull request transitions the Homebrew distribution from a formula to a cask in .goreleaser.yaml, updates the target directory to Casks, and adds a post-install hook to strip the macOS quarantine attribute from the unsigned binary. The README is also updated to clarify that Homebrew is for macOS. The feedback suggests simplifying the post-install hook by using OS.mac? instead of checking for the existence of /usr/bin/xattr via system_command, which is unnecessary on macOS and could clutter logs or cause crashes.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

Comment thread .goreleaser.yaml
Comment on lines +40 to +42
if system_command("/usr/bin/xattr", args: ["-h"]).exit_status == 0
system_command "/usr/bin/xattr", args: ["-dr", "com.apple.quarantine", "#{staged_path}/dscrd"]
end

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

medium

Using system_command to check for the existence of /usr/bin/xattr by running it with -h is unnecessary and can cause issues. On macOS, /usr/bin/xattr is a standard system utility that is guaranteed to exist. Furthermore, running /usr/bin/xattr -h prints help/usage text to the console, which clutters the Homebrew installation logs. If the command were somehow missing or failed to execute, system_command would raise an exception (such as Errno::ENOENT) rather than returning a non-zero exit status, causing the installation to crash.

Using the standard OS.mac? check is the idiomatic and recommended approach in Homebrew Casks (and GoReleaser's documentation) to guard macOS-specific commands.

          if OS.mac?
            system_command "/usr/bin/xattr", args: ["-dr", "com.apple.quarantine", "#{staged_path}/dscrd"]
          end

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.

1 participant