3 ms·
I agree with the one of the author's points: Running tests pre-commit is the answer. What I don't see is how this translates to getting rid of git and Jenkins.
by theamk 5y ago
I agree with the one of the author's points: Running tests pre-commit is the answer.
What I don't see is how this translates to getting rid of git and Jenkins.
It seems that (1) setting up a command/script to run the test locally and (2) having CI run this command/script and nothing else will be enough to fix all of the author's problems.
Additionally, I can imagine nice IDE integration that continuously runs the tests in the background and indicates if the code is ready to be committed or not.
Of course we'd still need git for code history/code review; and CI, just in case someone does changes without using IDE.
(Also, I'd like to comment on this phrase: "How often have you or a coworker pushed an empty commit to "re-trigger" the CI?" -- dude, your tests are broken. The CI is not supposed to be flaky. Fix your tests, or if you cannot do this, add a "retry" block to your Jenkinsfile. And if you don't want to do this, at least give developers permission to re-run failed jobs, so they don't have to keep pushing empty commits!)