[ReadMe] Remove extraneous blank line

[RobDolinMS]

Submitting this commit to see if sign-off checks are fixed

Signed-off-by: Rob Dolin (MSFT) robdolin@microsoft.com

[caniszczyk]

Hey @wking, is the same issue that was happening before?

[wking]

On Wed, Jan 25, 2017 at 01:38:15PM -0800, Rob Dolin (MSFT) wrote: Submitting this commit to see if sign-off checks are fixed

PullApprove looks happy [1] and Travis' /pr tests pass [2]. It looks like the Travis' /pull tests still have some issues (e.g. they're looking at the ancient ca0803d [3]), but I'm not clear on why (that commit is not part of $(EPOCH_TEST_COMMIT)..HEAD). [1]: https://pullapprove.com/opencontainers/runtime-spec/pull-request/671/ [2]: https://travis-ci.org/opencontainers/runtime-spec/builds/195342572 [3]: https://travis-ci.org/opencontainers/runtime-spec/jobs/195342449#L1959

[mikebrow]

Looks like the rules changed and now some of the older commits have issues?

[mikebrow]

@wking in the makefile commit the other day did you want:

ifdef TRAVIS_COMMIT_RANGE
  	git-validation -q -run DCO,short-subject,dangling-whitespace
  else
  	git-validation -v -run DCO,short-subject,dangling-whitespace -range $(EPOCH_TEST_COMMIT)..HEAD

or ifndef?

[wking]

On Thu, Jan 26, 2017 at 11:12:49AM -0800, Mike Brown wrote: Looks like the rules changed and now some of the older commits have issues?

But the troublesome commits are from before our EPOCH_TEST_COMMIT [1]. In the failing test, Travis is setting TRAVIS_COMMIT_RANGE to an empty string, but you can tell it's still (appropriately) using the EPOCH_TEST_COMMIT-based range [2]. What I'm not clear on is why 78e6667..HEAD is turning up old commits like ca0803d. [1]: #671 (comment) [2]: https://travis-ci.org/opencontainers/runtime-spec/jobs/195342449#L322

[wking]

On Thu, Jan 26, 2017 at 11:45:04AM -0800, Mike Brown wrote: @wking in the makefile commit the other day did you want: ``` ifdef TRAVIS_COMMIT_RANGE git-validation -q -run DCO,short-subject,dangling-whitespace else git-validation -v -run DCO,short-subject,dangling-whitespace -range $(EPOCH_TEST_COMMIT)..HEAD ``` or ifndef?

ifdef is right (and the empty-string TRAVIS_COMMIT_RANGE doesn't seem to be tripping it up). The idea is that if TRAVIS_COMMIT_RANGE is set (to something meaningful), we use git-validation's internal logic [1] (and this works for /pr tests [2]). And when TRAVIS_COMMIT_RANGE is not set (to something meaningful), we use $(EPOCH_TEST_COMMIT)..HEAD. So the failing /push tests are using the right git-validation invocation, but for some reason they are hitting old commits with the (appropriate) explicit ‘-range 78e6667..HEAD’. I don't have a handle on how *that* is going wrong. [1]: https://github.com/vbatts/git-validation/blob/206708c3bd34a36270d62fa803b0a4cb8385f8a9/main.go#L52 [2]: https://travis-ci.org/opencontainers/runtime-spec/jobs/195342573#L330

[mikebrow]

Ok.. was wondering if the "" empty string was tripping it up the logic, wasn't sure if it was doing what you wanted.

So the range includes commits we don't expect? Or the rules have changed for the validation and now we have merged commits that can't pass?

[wking]

On Thu, Jan 26, 2017 at 12:05:31PM -0800, Mike Brown wrote: So the range includes commits we don't expect?

This is what's happening. And I can't reproduce the Travis failure locally with: $ git checkout -qf 5fa1642 # [1] $ export TRAVIS_COMMIT_RANGE= # [2] $ TRAVIS_COMMIT_RANGE="${TRAVIS_COMMIT_RANGE/.../..}" make .gitvalidation # [3] git-validation -v -run DCO,short-subject,dangling-whitespace -range 78e6667..HEAD …nothing from ca0803d… $ echo $? 0 despite running apparently the same commands. [1]: https://travis-ci.org/opencontainers/runtime-spec/jobs/195342449#L228 [2]: https://travis-ci.org/opencontainers/runtime-spec/jobs/195342449#L296 [3]: https://travis-ci.org/opencontainers/runtime-spec/jobs/195342449#L321

[wking]

On Thu, Jan 26, 2017 at 12:31:00PM -0800, W. Trevor King wrote: Thu, Jan 26, 2017 at 12:05:31PM -0800, Mike Brown: > So the range includes commits we don't expect? This is what's happening. And I can't reproduce the Travis failure locally with: $ git checkout -qf 5fa1642 # [1] $ export TRAVIS_COMMIT_RANGE= # [2] $ TRAVIS_COMMIT_RANGE="${TRAVIS_COMMIT_RANGE/.../..}" make .gitvalidation [3] …nothing from ca0803d… $ echo $? 0 despite running apparently the same commands.

Ah, the problem is that git-validation is clobbering the value from -range when TRAVIS=true and either TRAVIS_COMMIT_RANGE or TRAVIS_COMMIT is non-empty. So we were setting -range, and then git-validation was ignoring it. I hadn't turned that up locally, because I hadn't realized git-validation was looking at TRAVIS directly. I've filed vbatts/git-validation#13 to fix this.

[wking]

I've filed vbatts/git-validation#13 to fix this.

That's landed, so this dummy PR should be green if @RobDolinMS or a maintainer closes and re-opens it (to trigger a fresh Travis run).

[vbatts]

@RobDolinMS this commit is empty. There is some wild git magic at play here. Where was the extraneous blank line? I'll carry your change, but this PR is in a wonky place.

[wking]

On Fri, Jan 27, 2017 at 12:49:26PM -0800, Vincent Batts wrote: @RobDolinMS this commit is empty.

This PR was a dummy to test Travis/PullApprove with @RobDolinMS's workflow [1]. [1]: #671 (comment)