homebrew-cask: cloning is broken

We’re talking to GitHub about this issue and progress is being made.

Just to clarify things here, given somethings have changed since Homebrew 4.0.0:

• If you have not set HOMEBREW_NO_INSTALL_FROM_API (it is not set by default), and are not editing a cask yourself, then you don’t need a homebrew-cask clone. Most instructions referring to brew tap homebrew/cask are out-of-date.
  • For existing installs under the default configuration, if you are getting this error on a manual brew update then you can safely ignore the error as it does not impact your install as the git clone isn’t used by default. I would suggest even doing a brew untap homebrew/cask - you will still be able to install casks under the new JSON API system introduced in Homebrew 4.0.0.
• If you are getting this in GitHub Actions, then HOMEBREW_NO_INSTALL_FROM_API is set by default there. If you’re happy unsetting that then you can try that, otherwise the only recommendation I have is try Homebrew/actions/setup-homebrew@master which retries the operation 5 times (which isn’t always enough but is a little better).

GitHub has completed a rollout of a fix, and results so far indicate that the errors have stopped. I’ll continue to monitor over the weekend.

Thanks to the git systems team at GitHub who have worked all week on tracking down and fixing the root cause.

We’ve also asked the GitHub Actions team to make some changes to their images that should eliminate the impact if this issue were to ever happen again. These changes will hopefully be rolled out soon.

git fsck
git repack -adf --window=200 --depth=200
git pull

On my local copy seems to fix it for me?

Homebrew 4.0.27 contains a change for non-developers that skips homebrew-cask fetching if you don’t have HOMEBREW_NO_INSTALL_FROM_API. So most users running brew update on their local machine should see the error go away after one more brew update (which will update the update script for subsequent runs). Again remember that you don’t need to do brew tap homebrew/cask to install casks anymore under the default configuration.

This change does not apply to GitHub Actions as GitHub sets HOMEBREW_NO_INSTALL_FROM_API by default. The recommendation there for now continues to be to use Homebrew/actions/setup-homebrew@master (which now has a cask: false option if you don’t use casks), or unset the env and brew untap homebrew/core homebrew/cask (note however for this approach that the env may be set again in subsequent steps, which could cause your workflow so become significantly slower if you use brew in subsequent steps).

For other CI providers, like CircleCI, I’d like to hear more about your setup. What base image are you using? What commands are you running?

In terms of the fixing the root cause of the underlying git issue, progress has been made with GitHub on this issue and hopefully there will be more to share soon.

@Bo98 : thank you! I temporarily unblocked our release pipeline by pinning homebrew/actions version Homebrew/actions/setup-homebrew@6fef698e5a2d6da69b9b7c76ad7e9a268ae59192, but I definitely wouldn’t recommend that approach to anyone unless they know what they are doing

Would something like https://github.com/Homebrew/actions/pull/391 help your particular case?

@Groxx I don’t think git fsck is relevant at all here. If widespread corruption of local copies was actually the issue, cloning from scratch would always resolve the issue and never fail.
These cloning errors seem to come and go in waves, occasionally there is a brief time window when all the clone/pull operations succeed. My guess - that’s when traffic gets routed to a non-corrupted replica on github’s side. I don’t think git fsck does anything besides adding a delay, which increases the chances of next git operation landing on a different replica.

@Bo98 : thank you! I temporarily unblocked our release pipeline by pinning homebrew/actions version Homebrew/actions/setup-homebrew@6fef698e5a2d6da69b9b7c76ad7e9a268ae59192, but I definitely wouldn’t recommend that approach to anyone unless they know what they are doing

@SMillerDev interesting, it is constantly failing on our CI starting last week with exactly this error 😕