sk-
Add --commits command line option
For CI, it would be great to have a --commits options that allows one to specify a comma separated list of commits id to track.
I'd like to use this feature. I'm willing to contribute, but would probably need some pointers on what would be the best way to approach this.
Hi I am interested in this, more specifically in allowing the user to pass in a range of commits.
I have a version of the code which works with a new argument --since-commit so git lint can be invoked as git lint --since-commit master to lint all the changes between a given commit/branch/tag and HEAD.
@sk- I don't have much knowledge of mercurial so I am not adding that feature there. If you still take PRs I'll send you one in a couple days.
@YBadiss mind sharing your solution? I'm looking for something that will fail CI builds if there's lint in the changeset.
@mistercrunch I found a supremely kludgy approach to using git-lint to fail CI if there's new lint in a PR. I accomplished it by means of a Make target which stores the current commit hash, does a git soft reset back to the latest common ancestor of the branch in the PR and origin/master, runs the linter (since all the changes from the commits in the PR are now staged), then resets back to the current commit.
.PHONY: lint
lint:
CURRENT_COMMIT=$$(git rev-parse HEAD) ;\
CURRENT_BRANCH_NAME=$$(git rev-parse --abbrev-ref HEAD) ;\
ANCESTOR=$$(git merge-base $$CURRENT_BRANCH_NAME origin/master) ;\
git reset --soft $$ANCESTOR ;\
pipenv run git lint ;\
EXIT_CODE=$$? ;\
git reset --soft $$CURRENT_COMMIT ;\
exit $$EXIT_CODE
This works on CI (tested on CircleCI), and locally as well. I'm still a little suspicious of what I'm doing with the git resets, but in my testing, it seems to be just fine. Let me know if this approach works for you!
Also, @YBadiss if you wouldn't mind sharing your --since-commit solution, that'd be super helpful, because with it perhaps ^ would no longer be necessary :)
For the ones looking on how to integrate git-lint in a CI environment, I just integrated it into Travis CI, (see the .travis.yml config).
Basically you do:
git reset --soft ${TRAVIS_COMMIT_RANGE%...*} && git lint
A similar approach could be done in Circle CI using the environment variable CIRCLE_COMPARE_URL
The feature of accepting commits or a commit range is feasible and most of the infrastructure is already there.
The last-commit flag is implemented by passing around a single commit value, however that can also be a commit range.
The main change required would be to change git.modified_lines to expand the commit range into a list of commit ids.
Also we would need to double check whether the same approach applies for mercurial, if not the flag should work only for git.
@jombooth just saw this, since then a lot happened and somehow I never pushed that change anywhere. Will look into it again soon.
@sk- I've got something working that uses git rev-list to get the commits/diff in a variety of manners.
If you wanted everything on branch a but not branch b (for example, a PR) you'd do something like
git lint --git-diff 'a ^b'
If you wanted a commit range
git lint --git-diff 'aeb273ab9..8203bce9089'
Basically if it works with git diff-tree and git rev-list it'll work. If you'd like I can clean it up, write some tests, and submit a PR
