Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Track rollback safeness in shipit #889
On undeployed commits list:
In this case,
Imo we should always give developers the option to rollback a commit even if it's marked as unsafe, because it's possible that it was marked as unsafe wrongly. At the same time, we should raise sufficient alarms so that these actions are performed with the right information. Any thoughts on the above ui/experience? Should we make it louder?
It'll render in the github UI exactly as the screenshot above, the screenshotted page was rendered with github's stylesheet that we inject :)
also yeah, I ran into a snag with
Also added the experience on rollbacks - Logic and the associated screenshots are documented in the pr summary.
casperisfine left a comment
I'm still uneasy with the nullable boolean, but I don't have all the context so if you feel it's the way
Apart from that:
I'm really tired and my head is full of conference things so I apologise in advance for the half baked thoughts.
I'm worried about unintended consequences / perverse incentives with this change, and want to make sure we're aligned on what we want to achieve. The way I see it there are 2 big areas we want a better story on:
If we're agreed there / I haven't missed anything, I wonder if we shouldn't actually have a default set either way, and have people deliberately pick - and refuse to merge without a choice. On the plus side it cant be ignored, and we sidestep the risk that we don't trust the boolean because people never set it. On the downside, shipping an unrollbackable change should be extremely exceptional, and so for the vast majority of PR's we're introducing unnecessary friction. I'm keen to get everyone's thoughts on this.
Thanks for the comments everybody, I think we can make the "Add to Merge Queue" a two step process like this:
This change will also fix the polling/state problem.
We can make it so that clicking the initial "Add to merge queue" button pauses the polling. Once Yes/No are selected, we can resume the polling. We could also put the second step here on a timer, so that if Yes/No is not selected within a certain time, the polling kicks in again (which will reset the ui back to "add to merge queue). Maybe a timer bar at the bottom can communicate this. This will make it so that there's a maximum time drift between Shipit's state and the user's UI