> How many times did your build break because it had a glitch downloading the package?
This happens very infrequently in my experience, but it's simple on most CI servers to restart a build.
This happens very infrequently in my experience, but it's simple on most CI servers to restart a build.
It's really easy to write these kinds of things off as rare occurrences, but this is exactly the kind of thing that causes us to talk about "fear" when deploying.
Edit: solution was to run 'rvm osx-ssl-certs update all' on OSX, which is unsettling, as it installs certs all over the disk. Then on Ubuntu it was "yum update openssl", I believe.
I remember my first brush with this when Maven first started getting popular. Apache had to move their servers to a new datacenter and the server that had the drives for the main maven repo was lost in transit. It took five days to bring everything back up. During that whole time, nobody could build anything unless they had local copies.
Ever since then, I'm pathological about ensuring that I have a local mirror of all my dependencies.
In practical terms, this means that you never know whether change X is faulty or simply the world is temporarily faulty.
(Of course, this may or may not be not useful to you to know.)
If the deploy fail for any reason, it's aborted, you just have to run it again.
Good engineering is the attempt to prove that statement wrong.