Offer a rake/bash script to generate pre-commit hook that will error or warn if debt increases via commit

[bglusman]

Might leverage pre-commit gem, but want script to make it easy to install a hook that runs debt_ceiling binary against old and new code during hook, and depending on a config flag either error or print a warning. Same flag can probably also be used to detect when test suite is run if this pre-commit hook is not in place, so a team can standardize on everyone having it if they want. Should also add a post-install message with instructions on running script (we don't want to install hooks automatically on install, and its really hard anyway)

@rhgraysonii as discussed, feel free to comment or tackle if you're motivated. @seanmarcia curious for your opinion also.

[ybur-yug]

@seanmarcia would love to get your two cents on this --
Since most commits to master are merge commits, I think it would be beneficial to add another feature that goes along the lines of this. With this script:

( set -e && git rev-list --reverse master -3  | while read rev; do git checkout $rev; bundle exec rspec spec/; done )

I am able to checkout the last 3 commits to master, run all the specs, and it will fail catastrophically if there is an error rather than keep running the loop (set -e). I think this would be beneficial because while it may not be beneficial to add directly to the debt value, I think it would be valuable to know if rehashing/merging/anything that alters history has made it so a commit in the current tree will not pass all specs.

Thoughts?

[ybur-yug]

I think a sane number to have it at would be the last ~30-50 commits (assuming youre a good rubyist and your test suite doesnt take more than a couple seconds to run)

[bglusman]

In my experience, that's semi-practical for a pure ruby test suite, and harder to acheive in rails (a few seconds for test suite). Currently debt_ceiling's takes more than a few seconds because of rubycritic, and it not having a clean way to avoid churn analysis every run, though also because its effectively integration tests only, running the whole process on every test.

Also , if we want to discuss that idea it should probably get its own issue, not be tacked on here.

[ybur-yug]

My bad! I'll open a separate one if it ends up warranting discussion. I agree with the Ruby/Rails point partially. But I'm an ass about stuff when it comes to Rails testing and get really anal about test suite speed.

[bglusman]

Possibly instead of doing this as install script inside the repo, it should be a plug-in for the pre-commit gem. This mostly involves some conventions in a new gem I think, theres some examples in a seperate pre-commit-plugins repo. I was going to do this for outlaw a year or so ago and never got around to it, but I think this may be cleanest solution, and can still mention (or even offer a rake task) that partly automates this, but I think the logic of checking for existing hooks and merging them together or whatever might be prohibitive and doesn't belong in this project.