Nevertheless, she persisted

I have a "homebrew tap" (package repository for the homebrew package manager).

I have a github workflow on the repository that checks for outdated packages and opens PRs with updated versions. All this functionality is built into homebrew itself, so the github workflow delegates to brew. This has the added convenience that I can test everything locally without needing to simulate the github actions environment.

For a month now, the workflow has been failing.

brew bump --open-pr kdeconnect
Error: No available formula with the name "kdeconnect". Did you mean kt-connect?

My casks (packages for gui and prebuilt software) were not being detected. Attempting to upgrade these packages simply reported that they didn’t exist. I was unable to reproduce the failure on my machine (a mac). Every step succeeded locally: checking for an updated version, editing the package manifest to refer to it, and opening a pr with the change.

Unfortunately, homebrew’s intelligence (and it truly is the smartest package manager ever) got in the way here. Out of desperation, I attempted to reproduce the issue using the homebrew docker image. This succeeded. It was here I remembered that Casks are invariably macos specific software, and homebrew smartly ignores these on linux. This allows the same package repositories to be used on mac and linux (formulas, the other package type, can detect the os and alter their build logic accordingly). The github workflow was running on ubuntu linux, so homebrew ignored my casks. Fine, makes sense. Switching the os that the github workflow ran on from linux to macos solved the issue.

Just one problem with this hypothesis. Why did it break now? Prior to this one month of breakage, the workflow had been running on linux just fine for 5-6 months. None of the github actions I was using made any breaking or major changes (if any). Did something change with the github actions environment? Did homebrew’s behavior change?

I suspected the later. I used the docker images to track this down to homebrew version 3.6.5 (which was very expensive, each was 1.1gb in size). Searching the changelogs yielded a PR that implicitly added the --formula flag when running on linux (limiting all actions to just formula). This PR was merged into version 3.6.5. I found the PR by searching the changelog for the keywords "bump" and "cask". The height of technological achievement. The PR mentions some of homebrew’s CI tests broke (gee).

Given this, I’m going to open an issue myself. I don’t expect a reversal of the PR. I hope maybe there is some override I’m unaware of, or maybe a better way. I want bumping cask versions to be possible on linux because none of the functionality appears to be macos specific.

I’m concerned that switching the github runner os to macos might have other side effects on the github workflow. It also feels strange running CI on macos, although I should’ve expected given that almost everything on my tap is macos software (and homebrew was a macos package manager first). Most likely, its me that needs to change and get over this discomfort.

And now for stream of consciousness garbage.


I can have different preferences between my local machine and CI!


Well, doesn’t github charge for macos minutes in CI or something?


Fine. fine. I’ll keep the github issue open so they know they hurt my feelings. But I wont make a scene or ask anything of the homebrew maintainers.

#Homebrew #Dev