The not so obvious value of build passing
dplyr monday, week 2
Yesterday was my second iteration of
#dplyrmondays, a schedule I’m trying to respect to give clarity about when I’m working on
The insidious build-passed
The thing I wanted to do first is to bring the repo back to a travis badge. This is a nice way to motivate users who want to give a shot at testing the development version, and it’s a nice reward.
However, that’s not why I wanted to work on this first. The reason is that having a is a perfect back door for more problems down the line.
I survived all of last week’s monday with a on the master branch, I did not pay too much attention and wanted to start fixing things that were already
reprexed in issues so nicely crafted by the community 🙏.
First of all, you keep receiving these Still failing emails from Travis, and sometimes I can’t help it but interpret this as an allegory of life. I just spent some time fixing a problem, I don’t want a reminder that I’m still failing.
The real problem however is that because you know it was broken already, you just don’t pay attention so you don’t have a way to quickly assert if you have just added a new 🐞, and then you live in fear.
This is also a problem for the person who reviews the contribution, might be you, might not be you, that’s irrelevant. The last thing you want is to give more work to someone, especially if that someone is you.
Keep your repo travis green
It turns out the problem was trivial enough, it was just a matter of finding the information in the travis logs and follow R’s recommendation for the interface that
Great, now dplyr has its badge again and I can break things again, or at least we can quickly identify when I do so.
Other things happened yesterday, but that’s enough words about it.
I might start to think about ways to make it easier to extract information from travis. It’s a lot of scrolling right now and it might be the reason why sometimes we don’t fix things quickly enough.