1

I'm trying to design a pre-push git hook for some kind of static code analysis. I've read about the topic and seems that some people go down the route of executing a maven/gradle goal and then checking the exit code but haven't found one that's a bit more insert software management tool here agnostic (or able to detect one for that matter and handle accordingly). Mainly, I'm looking for suggestions of what would be the best approach of writing a hook like that from people who have done it in the past. Thanks in advance!

AdamekOwns
  • 33
  • 4
  • Usually today people do not use hooks to prevent checkins. Usually people working on branches which do any kind of checking for example static code analysis, checking the coverage of unit tests and of course checking the checkstyle....until the branch has not reached a level of quality this branch will not being merged into master ...I would strongly recommend to prevent going the path of hook scripts and prevent people of checking in....apart from many other things...but let people work... – khmarbaise Feb 10 '19 at 15:37
  • I see your point but often it's difficult to enforce this in practice. It saves code reviewers from constant comments about it, or just allowing it to the be merged unnoticed. Also, in practice in takes a simple keyboard shortcut to correct so it doesn't really get in the way of a developer's job – AdamekOwns Feb 10 '19 at 17:17
  • The team should enforce that by itself not from outside...You seemed to be misunderstanding code reviews...the team is responsible for the master which should be changed only by merges which should be done only, maybe with tools, if two members have acknowledged a merge ..? unnoticed ? Hm...and no it's not difficult to enforce in practice cause in the end it prevents many bugs, issues, technical debt etc. – khmarbaise Feb 10 '19 at 18:20
  • Typically, one enforces this using CI infrastructure during the pull request stage. Code which does not meet automated standards (formatting, lint checks, etc.) cannot be merged (except maybe by an administrator), and the user sees the failure as part of the pull request automation and has to fix it. – bk2204 Feb 10 '19 at 18:53
  • @khmarbaise If you let developers let loose too much, you will not be able to enforce practices. Code reviews focus more on the general design, testing and coding standards in the gran scheme of things. They are not there for developers to point out you've missed a space between your 'if' and your '('... – AdamekOwns Feb 11 '19 at 09:07
  • @brianm.carlson So I quite like this except the feedback loop for this is quite slow. You require your CI to run before the developer can know that something is wrong so this might get frustrating. Git hooks are quick because it's all done locally – AdamekOwns Feb 11 '19 at 09:08

0 Answers0