OSX Homebrew addons module not as reliable as claimed

In the documentation:

The Homebrew addon correctly handles up-to-date, outdated, and missing packages. Manual Homebrew dependency scripts are error-prone, and we recommend against using them.

However, I have found there are at least three cases where the homebrew addon fails to properly handle things

  1. When an update is needed because homebrew is out of date, the addon fails to do so automatically. This means I am forced to always specify update: yes in my configurations
  2. The homebrew addon does not handle when homebrew has a very large install that doesn’t print things for a while, and will kill the build
  3. The homebrew addon does not retry steps such as timed-out downloads, which are a very common issue with Travis’ unreliable network connections.

In addition we’re 5 years on and the homebrew addon still doesn’t do caching: https://github.com/travis-ci/travis-ci/issues/1961

We also see issues like missing features like: Support forced link in homebrew addon

1 Like

I haven’t hit that yet, but now I’m wondering if it’s going to be a problem that the addon runs its own brew update command with the output redirected to /dev/null.

It takes forever to run, recently — 316.22s, in the job I just ran — should we be worried that it’s going to start causing timeouts?

1 Like

@gdevenyi, to my knowledge, Homebrew doesn’t provide a supported way to do any of that. You can check out https://stackoverflow.com/questions/39930171/cache-brew-builds-with-travis-ci to get an idea of what kind of hoops one has to jump through to get it working. So you need to work with the upstream project in that direction. Only when there’s upstream support can Travis consider supporting any of this officially.

If you have 10+ minute package installs, you are likely using a old MacOS version that Homebrew no longer provides bottles for (and they only do that when Apple drops support for it, too) – and as such, you are on your own in this case, through no fault of Travis. You can use the library linked to on the above link to build bottles from source and cache them but you’ll probably need one or more cache stages to build everything, and Homebrew doesn’t guarantee that more modern formulae won’t break for those old OS versions (but it does accept pull requests to fix such breakages).

1 Like

And I’m sympathetic to the fact that the tool isn’t exactly well-suited to their needs. Homebrew does seem frustratingly slanted towards interactive use. Just the fact that it considers “this package you asked to install is already installed” to be a warning condition, instead of silently ignoring it as “request already met”, is a bit strange for a package manager. AFAICT there doesn’t even seem to be a commandline argument to brew install that would optionally tell it to ignore already-installed packages. There’s a lot of room for improvement, I agree.

While I agree that the Homebrew developers should be involved in any efforts to improve this situation, and I would hope that they’d be amenable to discussions along those lines, it seems to me that those discussions would be infinitely more productive if the Travis developers who’re supporting the addon were involved in them, or even initiated them.

If the Travis team goes to the Brew team and says, “Hey, we want to use your tool to support our user base, but here are some things about it that don’t meet our needs, and these other feature ideas we’ve had would really make it a much better fit for our process.” then it’s a discussion between a group of tool developers and the downstream consumers who are implementing solutions based on that tool.

If Travis users go to Homebrew, then you’ve got a bunch of someone else’s endusers asking for things which may or may not be any use to the Travis team, and may be delivered in a way that doesn’t meet their needs. I know I’d certainly rather be part of that discussion, rather than just waiting to see what comes out of it and hoping it produces what I need.

The addon is opensource, and Homebrew is actually maintained by unpaid volunteers. So you are in a prime position to gauge the tooling’s needs and suggest stuff, especially if you are using the CI for free. Nothing prevents you from CCing staff members in case they have any comments.

Related: Run stock installation logic after before_install (or other chunk of user code)
This would allow to fix up things on the fly before any addon logic runs.