Avoid golint's:
rules/danglingwhitespace/rule.go:22:1: exported function ValidateDanglingWhitespace should have comment or be unexported
Signed-off-by: W. Trevor King <wking@tremily.us>
Before this commit:
$ ./git-validation -run DCO -range HEAD^^..foo
2017/03/21 13:00:30 exit status 128
With this commit:
$ ./git-validation -run DCO -range HEAD^^..foo
ERRO[0000] [git] cmd: "git --no-pager log --no-merges --pretty=format:%H HEAD^^..foo"
2017/03/21 13:16:43 exit status 128
You can get similar output with -D, but folks are unlikely to set that
in production. With the new error logs, Travis output and similar is
more likely to contain some useful information.
Signed-off-by: W. Trevor King <wking@tremily.us>
Master builds only have a 'git clone ...' [1] so FETCH_HEAD isn't
defined and git-validation crashes [2]. This commit partially reverts
8a12a8fc (main: default travis commit range is unreliable, 2017-03-21,
#13) to avoid that crash. If TRAVIS_COMMIT_RANGE is unset [3],
falling back to TRAVIS_COMMIT may be fine.
The ... -> .. replacement works around travis-ci/travis-ci#4596 until
that is fixed upstream [4]. This avoids pulling in commits from the
base tip that aren't reachable from the head tip (e.g. if master has
advanced since the PR branched off, and the PR is against master). We
only want to check commits that are in the head branch but not in the
base branch (more details on the range syntax in [5]).
Once the Travis bug does get fixed, the shell replacement will be a
no-op. So we don't have to worry about checks breaking once the bug
gets fixed, and can periodically poll the bug and remove the
workaround at out leisure after the fix.
[1]: 213508696 (L243)
[2]: 213508696 (L347)
[3]: https://github.com/opencontainers/runc/pull/1378#issuecomment-287903471
[4]: https://github.com/travis-ci/travis-ci/issues/4596
[5]: http://git-scm.com/docs/gitrevisions#_specifying_ranges
Signed-off-by: W. Trevor King <wking@tremily.us>
Partially reverting ca825225 (git: do not include merges in the commit
range, 2017-03-21, #16). I've kept the unrelated --no-pager addition
from that commit.
I think merges in the commit range should be checked against whatever
criteria the caller is asking for. If the caller does not want to
check a machine-generated commit, they shouldn't include it in the
commit range.
And we already have special-cases for merges. For example, we skip
DCO checks for merge commits. I'd be happier without that special
case, because human-generated merge commits can still add novel code
(and therefore should have Signed-off-by), etc. But I don't think we
want a blanket pass for merge commits.
Signed-off-by: W. Trevor King <wking@tremily.us>
If someone went through the trouble to set -range, they probably don't
want you clobbering their value with something from a TRAVIS_*
environment variable.
ideally `-q` would be only return code of 0 or non-zero, but it already
had some output. This adds only failed tests per commit.
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
