On Sun, 21 Jun 2020 17:15:44 +0000, Johnny Billquist wrote:
...
Even when you have unit tests (which you should), there are still plenty
of errors not caught by that. However, automatically running unit tests
on all code to be committed, *before* it is committed, is also very
valuable.
In git, commits are not final, and you can undo or 'modify' them.[1]
Therefore there is no reason to require running tests before committing,
but it rather makes sense to run tests on the *committed* state. For
one, this way you see if you actually committed everything that is
needed, and you still can replace the commit by a modified one if
tests failed.
E.g. on our primary product the developers can take the current
commit in their workspace (repo), and run the CI tests on them
on a server. The command that triggers this takes the current
local commit, pushes it to a test repo, and a host in the
test server farm picks that up. You can do that before even
pushing to your branch in the central repo, i.e. before anybody
seeing your commit.
- Andreas
[1] Still, on your central repo and branches you will disable
removal of commits for the obvious reasons.