4 ms·
I'm pretty sure that wasn't the point - however infrequently it occurs, it violates the principle that only changes introduced since the previous build could ha
by lamby 13y ago
I'm pretty sure that wasn't the point - however infrequently it occurs, it violates the principle that only changes introduced since the previous build could have made it fail.
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.)
- sjtgraham 13y agoTrue, but a build could fail arbitrarily fail for any unexpected reason. Pragmatism is important, I'd avoid adding an inconvenient step to my build/deploy process just to mitigate an infrequent edge case.
- byroot 13y agoInfrequent (I don't remeber that it happened to me during the hundred or thousand deploy I made with capistrano) and mostly harmless. If the deploy fail for any reason, it's aborted, you just have to run it again.
- pyre 13y agoWhat do you do if the package servers go down for a couple of days? "Oops! Guess I can't deploy. Oh well!"
- lamby 13y agoMaybe my brain is wired differently, but having to tell a new hire "Oh yeah sometimes the build randomly fails and we just press retry until it works" would just feel kinda embarrasing to me.
- sjtgraham 13y agoThat's not what I said. The point is one might as well say it never happens for how often it happens in practise. I have only had it happen once in recent memory, and even then it was because the hosted CI we use was experiencing issues.
- regularfry 13y ago> a build could fail arbitrarily fail for any unexpected reason. Good engineering is the attempt to prove that statement wrong.