Add compare-branch option to paver run_quality

[kluo]

Pretty self explanatory. @benpatterson

[openedx-webhooks]

Thanks for the pull request, @kluo! I've created OSPR-238 to keep track of it in JIRA. JIRA is a place for product owners to prioritize feature reviews by the engineering development teams.

Feel free to add as much of the following information to the ticket:

• supporting documentation
• edx-code email threads
• timeline information ('this must be merged by XX date', and why that is)
• partner information ('this is a course on edx.org')
• any other information that can help Product understand the context for the PR

All technical communication about the code itself will still be done via the Github pull request interface. As a reminder, our process documentation is here.

[benpatterson]

the docstring above this line describes the 'p' parameter. Could you add some doc on this comare-branch param? also, while you're there, you'll need to update some verbage in the 'p' description itself, because it assumes a comparison against master. it will probably make more sense to list the compare-branch param first.

[benpatterson]

Curious, what if someone passes in a non-existent branch?

[kluo]

paver run_quality -b nonexistent_branch

returns

diff_cover.git_diff.GitDiffError: fatal: ambiguous argument 'nonexistent_branch...HEAD': unknown revision or path not in the working tree.

[benpatterson]

Hey @kluo sorry for the delay on my end. It's a relatively small change, but I'd actually prefer it if you took a similar pattern to how the 'percentage' limit is used. That is, only pass in the --compare-branch to diff-quality when it's passed in from paver.

When it's not passed in, then the switch is not used on diff-quality, and that uses the diff-quality default (of origin/master). I realize it's not functionally different than what you've already put together---and has not been implemented everywhere like this---but is a better pattern for handling switches that are passed to an underlying utility. For your reference, I mean we should do something like this:
https://github.com/edx/edx-platform/blob/master/pavelib/quality.py#L145

I was originally going to do it for you and attach it to this PR (likely with another PR), but it doesn't look like I'll have time to get to that in the next few days, so I'm asking you.

I've also been looking at tests in this area. I was originally going to ask you to include tests with your change (another area that we're improving under pavelib), but that is not a small task for the compare-branch change at this point, so I think we can defer that.

[kluo]

@benpatterson when you have a chance, thanks!

[benpatterson]

Looks good, @kluo. Thanks for putting it together. This will be very useful!