@patrickhulce Unfortunately I don't know 100% that it's the root cause, but it's my strong suspicion - basically I think the Travis cache stage gets stalled thanks to the GPG agent process. It fits the behavior pattern, and initially this PR passing also seems to support it working. But it'd probably take more builds and repeat evidence to confirm whether this is making a real difference.

@patrickhulce As an outsider I guess I don't have a strong opinion, but for some reason, master builds do seem relatively reliable (and actually, that's probably strong-ish evidence that maybe something else is going on?) -- and verifying the yarn install files seems like good practice if possible. I wouldn't love hearing that there'd been some kind of yarn security issue down the line and then be the person responsible for having turned off GPG verification in master builds :)

@patrickhulce Alright, yep - it looks like gpg --import starts a gpg-agent daemon process under linux platforms as well. Time to look into fixes there, and I may open a PR/issue against yarnpkg/website.

but for some reason, master builds do seem relatively reliable

not anymore! :)

@paulirish an upstream fix might be ready from yarnpkg/website#1030 soon - maybe it's worth holding off temporarily? I'm a bit wary of disabling all GPG verification here (although yep, there's a tradeoff vs getting builds back in good shape for sure)

WHELP.. that didn't work. :/

It's really interesting that it's not happening to lighthouse-ci and that it's even before yarn is installed, so I'm not sure the GPG is to blame here.

Based on the fact that it's hanging on adding the yarn directory to the cache and the master cache just ballooned to 6GB, maybe we try that?

Well, that seemed to work at least and the cache is back down to ~900MB on master, maybe we just need to periodically clear them and/or prune unused yarn cruft? 🤷‍♂

https://travis-ci.org/GoogleChrome/lighthouse/builds/621861205?utm_medium=notification&utm_source=github_status

@patrickhulce Great, ok - caching being the real root cause does sound like it fits the behaviour patterns and would make sense.

In that case I think I'll close this PR for now, and I'll continue discussing the yarnpkg PR to see whether it's worth landing that change (definitely seems less important if it has no impact here, but perhaps good to reduce their install script side-effects anyway).

I haven't looked too far into this (and don't have much experience with TravisCI), but why do you need to install Yarn fresh for every single build? Usually the better and faster approach is to use a Docker container with all your build tools already installed, and just rebuild the Docker container every so often to upgrade the tools.

If you disable GPG I'd recommend at least checking a SHA256 checksum of the file.

@Daniel15 It looks like Travis-CI auto-detects and installs yarn by default under certain conditions -- there's no explicit configuration (or need) in the lighthouse project to reinstall it fresh, as far as I know.

@.patrickhulce's theory (which I think matches the evidence) is that the GPG agent isn't really the cause of the recent lighthouse Travis build failures; instead it may be that the size of the build cache (which contains the ~/.yarn directory and other filesystem contents) is causing problems somehow.

It's possible Travis does create & re-use 'build-ready environments' the way you mention via container images, avoiding the need to run the install.sh script for all builds, but the Windows issue reports would suggest it does invoke the script 'live' during at least some builds.