It seems impossible to prevent brew updating everything, with a disastrous consumption of credits. The documentation says it won’t update “by default”, but it does so, even when asked nicely not to.
The homebrew section is:
addons:
homebrew:
update: false
taps:
- homebrew/cask-versions # for openjdk
packages:
- ant
- openjdk@8
This may be new-ish behaviour. Or is it related to a change in the particular dependencies I need? I am running on Xcode11.6.
The build works, it just takes 19 minutes of which this is 17 I could do without:
Thanks @Montana , but AFAICT the homebrew update goes off before it gets to that section. (I cancelled it at the 7 minute mark, but well after it was obviously doing the update.)
Or have I put it in the wrong place? Is the a global hook outside the OSX job scope? If Travis CI could put such a statement in the preamble to the homebrew add-on, it would conform again to its documentation.
It’s not as simple as removing the brew update command, in a lot of ways it’s because brew is so very helpful that it implicitly runs update on the next brew install. I’m going to try and reproduce the problem and get you a working .travis.yml example as soon as possible.
I was able to skip (seemingly) brew update - I have a private repository, with some of the .travis.yml looking like this, this is a private project so I can’t post it in it’s entirety, I hope this gives you a starting foundation, your current .travis.yml is a bit messy.
I think the problem you’re having was solved sometime in 2019, look here. I understood your concern, I was just trying another fix, I’ll fix up your .travis.yml tomorrow (if you can wait that long - and this isn’t pressing).
I recommend you looking at the foundation I provided from one of my private repos that work, and the link I provided.
@Montana : thanks for your persistence. No, not pressing – I’ll be on other work for a while, except for odd hours.
The messy .travis.yml is intended to launch 5 jobs across 3 OSes. It’s the result of much trial-and-error testing. I’m happy with the Linux and Windows jobs, and the “common part” is just a smoke test while I get the setup right.
A well-written alternative with the same intention would be interesting to read, but no hurry.