Automate "Best Practices" Enforcement on Pull Requests

[omgitsbillryan]

The Problem

Some common mistakes are made when starting pull requests:

1. The PR is too long
2. The PR changes code in /db/migration & /app at the same time (changes to /db/migration should be done in a standalone PR)
3. (Any more ideas?)

Work to Be Done

• [x] Discover a tool that best is a best fit to check for PR size & code changes
  • Ideas:
  • codeclimate since we already use this tool
  • danger ruby since it looks like it may provide exactly what we need
• [x] Implement tool to provide adequate warning messaging and/or fails builds if either of the aforementioned rules are broken

[kfrz]

This is awesome. :) :pray:

• We could add a linter for checking comments and terms used throughout codebase. Not huge but a nice-to-have and low lift.

• There might be a few obstacles to implementing this particular tool, but git-cop is highly functional. It offers optionally configured cops for many commit-related styles, including blacklisting phrases in messages to encourage concision, etc... fit-commit is another option I've seen.

<soapbox>

---

I've ranted on this before but I would love to see us improve our overall commit message quality. A quick git log -a shows tenses interchanging, un-squashed messages w/ meaningless information, and variant strategies for writing said messages.

I think the value in maintaining a highly-readable git log acts more like an insurance policy. This is hand-in-hand with making atomic commits that can be rolled back or cherry picked if needed. We hopefully don't need to spelunkdebug via git log all too often, but it's made easier by taking a bit of care when crafting the message.

When in doubt, consult the master himself, Linus. These commit messages are the pinnacle of excellence, and we should aim for excellence in all things.

---

</soapbox>

• We might also explore any options for enforcing things like warning on rebase, etc. IIRC we encourage squash commits, but there's not anything stopping a git rebase master && git push -f (I think).

[omgitsbillryan]

git-cop requires Ruby 2.6 or higher 😢 . fit-commit seems like a reasonable alternative that does pretty much the same thing, albeit slightly lesser adopted. this would be a nice addition IMO.

master is configured as a protected branch, which I'm pretty sure means that commits directly to it are not allowed. vets-api is also configured to disallow merge and rebase commits to master - it will only allow squash commits.

[omgitsbillryan]

No longer blocked since our jenkins jobs are now "Pull Request" discovered.