Private tap with private Go based projects

[Okeanos]

Output of brew config

HOMEBREW_VERSION: 5.0.8-26-g69f832a
ORIGIN: https://github.com/Homebrew/brew
HEAD: 69f832a71ae13a560236da5dacba2d6b6d3fd83d
Last commit: 11 hours ago
Branch: main
Core tap HEAD: 83674b6c84e3e471ef2ed039dc245e78fd60f655
Core tap last commit: 5 hours ago
Core tap JSON: 02 Jan 15:47 UTC
Core cask tap JSON: 02 Jan 15:47 UTC
HOMEBREW_PREFIX: /usr/local
HOMEBREW_CASK_OPTS: []
HOMEBREW_DOWNLOAD_CONCURRENCY: 32
HOMEBREW_EDITOR: vim
HOMEBREW_FORBID_PACKAGES_FROM_PATHS: set
HOMEBREW_MAKE_JOBS: 16
HOMEBREW_SORBET_RUNTIME: set
Homebrew Ruby: 3.4.8 => /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/3.4.8/bin/ruby
CPU: 16-core 64-bit kabylake
Clang: 17.0.0 build 1700
Git: 2.52.0 => /usr/local/bin/git
Curl: 8.7.1 => /usr/bin/curl
macOS: 15.7.3-x86_64
CLT: 26.2.0.0.1.1764812424
Xcode: N/A

Output of brew doctor

Please note that these warnings are just used to help the Homebrew maintainers
with debugging if you file an issue. If everything you use Homebrew for is
working fine: please don't worry or file an issue; just ignore this. Thanks!

Warning: Some installed casks are deprecated or disabled.
You should find replacements for the following casks:
  <snip>

Warning: Some installed formulae are deprecated or disabled.
You should find replacements for the following formulae:
  icu4c@77
  node@20

Warning: Putting non-prefixed coreutils in your path can cause GMP builds to fail.

Warning: Putting non-prefixed findutils in your path can cause python builds to fail.

Warning: You have unlinked kegs in your Cellar.
Leaving kegs unlinked can lead to build-trouble and cause formulae that depend on
those kegs to fail to run properly once built. Run `brew link` on these:
  gnupg

Description of issue

I would like to create a private tap that contains formulae using Go to build the resulting binaries. The involved repositories for dependencies are partially private as well.

A simplified example with fake data:

class Example < Formula
    desc "Example showing private tap usage"
    homepage "https://github.com/example/example"
    url "https://github.com/example/example.git", tag: "v1.0.0"
    license "Proprietary"
    head "https://github.com/example/example.git", branch: "main"

    depends_on "go" => :build

    def install
        with_env(
            "GONOPROXY" => "github.com/example",
            "GONOSUMDB" => "github.com/example",
            "GONPRIVATE" => "github.com/example",
    ) do
        ldflags = %W[
            -s -w
            -X main.version=#{version}
            -X main.commit=#{Utils.git_short_head(length: 7)}
            -X main.date=#{time.xmlschema}
        ]
        
        system "go", "build", *std_go_args(ldflags:), "./cmd/example"
    end

    test do
        assert_match /Example #{version}.*/, shell_output("#{bin}/example --version")
    end
end

Please note that the Go dependencies specified in the go.mod file are not vendored and may look something like this:

module github.com/example/example

go 1.24.1

toolchain go1.24.5

require (
    github.com/example/example-2 v2.0.0
)

where github.com/example/example-2 is its own private repository on GitHub (or any other host for that matter).

Some minimal setup on a client with brew assumed:

• Git on the host system running brew install has credentials for the target repositories (plural!) tap, formula source & dependencies
• Including a potential insteadOf redirect for Git to use SSH connections (git config set --global url."[email protected]:".insteadOf "https://github.com/") instead of HTTPS or vice versa
• Including Git Credential Manager otherwise?
• In any case Git on the host is allowed to access the repositories in an unattended fashion that does NOT require user interaction when brew install runs.

Now after setting up the tap brew tap example/tap https://github.com/example/homebrew-tap and then running install brew install example/tap/example the following happens:

• Tap downloaded: works
• Formula download (i.e. source code as specified): works
• Formula building: nope, doesn't work

The Formula invokes go build and Go will then attempt to resolve the dependencies. Publicly available dependencies resolve just fine, however, the private dependencies fail.

According to the docs Brew will (understandably!) create a self-contained environment for the build process to execute in. However, this means that the user's Git settings are also not available, specifically the credentials to access the private repositories.

There appears to be a way to inject some environment variables into the local build process according to the docs but nothing related to authentication for Git/Go/build systems. I also found a few potentially relevant discussions that somewhat touch on my question but no solution.

Other discussions that might be related / similar are:

• Maintaining an internal homebrew tap.
• How to inject an envvar into a formula?
• Passing a secret during build
• Setting custom registry for node
• How to pass --trusted-host or get brew to use corporate certificate passed to pip via $PIP_CERT?
• Authentication for private formulae

Private casks (or bottles I guess also need this access to automatically build?) are sadly out of the question for me. Or at least I don't think I can make them work reasonably because they would trigger Gatekeeper issues that need resolving and I would like to avoid that by providing the means to locally self-build instead.

So my question is: how do I provide brew with access to the private repositories needed to resolve & download the dependencies during a local brew install (requiring a build)?

If this isn't possible / supported behaviour, I'll have to live with it but I just wanted to make sure I am not overlooking anything that would make this work.

[SMillerDev]

I think it would be much easier to use goreleaser for this. You can make binaries and distribute them as casks.

They also have recommendations on how to sidestep gatekeeper issues

[Okeanos]

Yes, the projects are actually released that way, too, so pre-built binaries technically exist. I'll have to have a look into goreleaser and how they work around the Gatekeeper issue when shipping unsigned binaries. Thanks for the pointer – they have a large feature set and I forgot to check their documentation for this detail.

Because I assume goreleaser also only does some "wonky" workaround when dealing with pre-built binaries I would still much rather build locally from source and not deal with it at all :/