fix(release): trust homebrew tap before install in test-install - #483
Conversation
The v0.66.1 release run (first one to actually reach this step, since homebrew/chocolatey were broken on every prior tag -- fixed in #476) failed here: `brew install keboola-cli2` refuses to load a formula from a third-party tap until the tap is explicitly trusted. Add `brew trust` right after `brew tap`, matching the remedy brew itself prints on failure. Verified locally: `brew tap` + `brew trust` + `brew install keboola-cli2` against the real keboola/homebrew-keboola-cli2 tap succeeds (arm64 linuxbrew container). The subsequent `kbagent --version` glibc mismatch seen in that local run is specific to arm64 bottles on this machine, not the amd64 ubuntu-latest CI runner -- the same binary already passes `kbagent --version` via the apt/rpm legs of this job on that runner.
| # explicitly trusted ("Refusing to load formula ... from untrusted tap ..."). | ||
| # First observed on the v0.66.1 run (github.com/keboola/cli, release-kbagent | ||
| # #29430278032) -- this is a real end-user install step too, not CI-only. | ||
| brew trust keboola/keboola-cli2 |
There was a problem hiding this comment.
🔍 Validity of brew trust subcommand cannot be verified from repo context
The added brew trust keboola/keboola-cli2 at .github/workflows/release-kbagent.yml:492 is not a Homebrew subcommand that existed in widely-known Homebrew versions (up to ~early 2025). The homebrew/brew Docker image at line 485 is unpinned (uses latest), so the exact Homebrew version depends on when the workflow runs. The PR comment references a real CI failure on v0.66.1 (run #29430278032) with the error "Refusing to load formula ... from untrusted tap", which suggests this is a newer Homebrew feature. If brew trust does not exist in the image version pulled at runtime, set -e (line 486) will cause the entire Homebrew test leg to fail — but since this is a smoke-test step (not a publish step), the blast radius is limited to a red CI check rather than a broken release. Worth confirming that brew trust is the correct invocation (vs. e.g. brew tap --trust or another syntax) by checking Homebrew's current docs or the referenced CI run logs.
Was this helpful? React with 👍 or 👎 to provide feedback.
…2.35 compatibility (#504) A PyInstaller binary requires the build machine's glibc (or newer) at runtime, so the freeze runner sets the compatibility floor for every end user. ubuntu-latest moved the linux amd64 leg to 24.04 (glibc 2.39): the v0.71.0 binary failed with "GLIBC_2.38 not found" on Ubuntu 22.04-era systems -- caught by test-install's Homebrew leg (run 29752342509) once the earlier 'brew trust' failure (#483) stopped masking it. Pin both linux legs to the oldest GA runners (ubuntu-22.04 / ubuntu-22.04-arm, glibc 2.35) so Ubuntu 22.04 / Debian 12 stay installable, and document why -latest must never be used for freeze.
Why
The
v0.66.1release run (https://github.com/keboola/cli/actions/runs/29430278032) failed thetest-installjob's Homebrew leg:This is the first release run that actually reaches this step — homebrew/chocolatey were broken on every prior tag (v0.63.3 through v0.66.0) and fixed only in #476, merged after v0.66.0 was cut. So this "untrusted tap" gate was never exercised before now.
Note the actual
homebrewpublish job (pushing the formula to the tap) succeeded — this only affects thetest-installsmoke-test leg that verifiesbrew installworks end to end.What changed
Add
brew trust keboola/keboola-cli2right afterbrew tap, matching the remedybrewitself prints on failure.Verification
Ran the fixed sequence locally against the real tap (arm64 linuxbrew container, Docker Desktop):
brew installcompletes successfully. The container image ishomebrew/brew, andkbagent --versionfails there with an arm64-bottle/glibc mismatch that's specific to my local (arm64) test container — not indicative of a problem on the actualubuntu-latest(amd64) CI runner, where the same v0.66.1 binary already passeskbagent --versionvia this job's apt/rpm legs.No
make checkchanges needed — this is a workflow-only fix (no Python/CLI behavior change), andrelease-kbagent.ymlonly triggers onv*.*.*tag pushes, so it can't be exercised by this PR's own CI. Next real verification is the next tag push.