fix(release): trust homebrew tap before install in test-install#483
fix(release): trust homebrew tap before install in test-install#483ZdenekSrotyr wants to merge 1 commit into
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.
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| # 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.
1 participant
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.