Seems that invoking brew update on travis’s docker images for macos takes around 2 minutes on each invoke which is annoying to say the least…
How should this be resolved?
Seems that brew update is invoking cleanup procedure which is taking this much time… Should i just use HOMEBREW_NO_INSTALL_CLEANUP assuming that said cleanup is performed by travis?
I’ve been facing the same issue for a few years. I updated images a few times and started using xcode12.2 originally since at least Nov 2019 in this repo. In the short term it seemed to help. Yet, over time it seems like the brew update command was taking longer and longer (last one was 6 min 44 sec!).
I saw someone mention TravisCI support recommended switching to the xcode12.5 image to speed up the build. However, when I tried that it resulted in an even longer build! ( brew update = 7 min 2 sec. The full build was 10 min 40 sec!)
This obviously isn’t sustainable given the situation with the new credits system and travis-ci.org => travis-ci.com migration. So far I’ve had no luck with getting the mythical “OSS-only credits”, which they seem to be reluctant to grant.
My usual next step would be to try caching like this, the usual CI optimizing “duct tape”. 
Yet, given the problem with non-replenishing paid credits… it’s not worth wasting them on testing & iteration for optimizing and speeding up a build step controlled by TravisCI themselves. TravisCI docs also state the following:
Large files that are quick to install but slow to download do not benefit from caching, as they take as long to download from the cache as from the original source
[…SNIP…]
Travis CI saves an archive of all the directories listed in the configuration and uploads it to a storage provider, using a secure and protected URL, ensuring security and privacy of the uploaded archives.Note that this makes our cache not network-local, it is still bound to network bandwidth and DNS resolutions. That impacts what you can and should store in the cache. If you store archives larger than a few hundred megabytes in the cache, it is unlikely that you’ll see a big speed improvement.
So, it’s not 100% clear whether caching will actually result in significant build time savings or not. I would usually try this if the build time wasn’t being charged for, but as it stands it’s a 100% risk of losing credits and my own development time on debugging a situation that I’m not in full control of.
I’m still going to try following up with support again. If that doesn’t work then I suppose screaming into the void of an uncaring universal abyss could at least be cathartic. 
¯\(ツ)/¯ … 
At least Red Green has our back… 