It’s like when you merge a documentation PR while the tests are still running: You’re pretty sure that the tests won’t break. With this solution however you’ll still be pinged if they do break, later.
Read the article. It says:
> If the CI job remains broken for more than 72 hours, all deployments to GitHub.com are halted
Edit: it even creates the perverse incentive of trying to get your own stuff in quickly before the 72h window closes that s/o else caused.
You don’t even need to hit a 2% success rate to get people agitated. Consecutive failed builds that happen every few weeks will eventually happen when someone really needs to get something out Right Now and that incident will come to define their experience, especially if it happens two or three times. Even if it’s just to people they know instead of themselves.
Anything that happens once a day happens “all the time.” For some people, that’s true for once a week. For others, if it happened twice in two weeks and once every six weeks thereafter.
If significant numbers of devs found the whole process stressful, I wonder if it would help to make the reversion happen automagically after, say, 24 hours, if the dev hasn't committed anything in that time
Devs who have called in sick or over the weekend or attending a wedding or long-planned vacation don't have to think about it.
Stopping the world seems like an automated process. So should reverting be. In fact, there should be no stopping the world at all, just reverting if the dev can't fix it within 72 hours. There might be cases where automatic reverting doesn't work, but those should still be managed through organizational processes, not by stopping the world.
I'm an unusual American, in that I consider healthy work-life balance to be top priority, at least for everyday employees (founders and such have a different path).
I do try to make room for the idea that my understanding of this is likely superficial, and that there may be things that I am missing, here.
I would guess that this wouldn't introduce more or less build breaks. People will do as they've been doing. The psychological argument can be made that people could be either less safe with their commits, since they have 72 hours to fix any problem breaking a long-running CI job, or they could be more safe with their commits, fearing they'll break a long-running CI job. Personally, I don't think that either position has a lot of strength.