> A friend of mine felt it was finger pointing when her coworker said "could you take a look at your commit `abc0123`? because it broke the test `Xyz`". I thought it was direct but professional.
IMO, it was appropriately finger pointing. The person who breaks the build should be the one to fix it - they're the one with the most context.
But also - require tests to pass before a commit is allowed. It makes development so much better.
I've softened my language a bit over the years from approximately that to something more like:
"Hey, I think commit abc0123 might have broken the build, and it looks like it was yours (link to build results). Would you mind looking at it?"
I give myself a little room for being wrong (sometimes I am), and it comes across as being less of an ass, to which people generally respond positively.
Requiring tests to pass before a commit is allowed can be a negative experience as well. For instance if you're handing off a branch to someone else to take over work in progress because you're going on vacation.
Or if you just have the (good) habit of checking in your work in progress code frequently, or daily.
Or if you have several workstations you want to share code on.
Point is that commits should be frequent and requiring tests to pass before you can commit is guaranteed to make sure that commits are infrequent.
I prefer to put "tests must pass before PR can be merged", rather than before commits can be made.
> I prefer to put "tests must pass before PR can be merged", rather than before commits can be made.
I worded it poorly, but this is largely what I meant. Although I was trying to stick to commits on main/master for the repository of record since PRs are a github (and bitbucket?) thing, whereas pre-commit hooks are a git thing.
IMO, it was appropriately finger pointing. The person who breaks the build should be the one to fix it - they're the one with the most context.
But also - require tests to pass before a commit is allowed. It makes development so much better.