travis fail on "push" vs passing on "pr"

[vbatts]

perhaps https://docs.travis-ci.com/user/pull-requests/ is the relevant info needed to work with this

[vbatts]

on the pr CI-build, the following env:

TRAVIS_EVENT_TYPE=pull_request
TRAVIS_BRANCH=master
TRAVIS_COMMIT_RANGE=e6a550d472b994461303a619168928ef878356a1...cf71a3046ba6830d93cecc79d747959c6b68a511
TRAVIS_PULL_REQUEST_BRANCH=fix_push_ci
TRAVIS_COMMIT=3e4f844fd3b63686685ad285fc670ee6cbf2afb4

but on push CI-build, the following env:

TRAVIS_EVENT_TYPE=push
TRAVIS_BRANCH=fix_push_ci
TRAVIS_COMMIT_RANGE=
TRAVIS_PULL_REQUEST_BRANCH=
TRAVIS_COMMIT=cf71a3046ba6830d93cecc79d747959c6b68a511

[vbatts]

i don't like the push tests. Not even enough information to do a git merge-base master without making an assumption that the commits are tracking master branch. I may rather roll these tests into a make target to only run in a non-push (pr only) ci-build.

[vbatts]

This might be an interesting flag to add to auto skip validation when [ "$TRAVIS_PULL_REQUEST" = "false" ]

[wking]

On Thu, Apr 27, 2017 at 10:34:45AM -0700, v1.0.0.batts wrote: i don't like the `push` tests. Not even enough information to do a `git merge-base master` without making an assumption that the commits are tracking `master` branch.

Can you look at @{upstream} or @{upstream}@{1} or some such to see what's changing in the new branch?

[wking]

On Thu, Apr 27, 2017 at 10:45:47AM -0700, W. Trevor King wrote: On Thu, Apr 27, 2017 at 10:34:45AM -0700, v1.0.0.batts wrote: > i don't like the `push` tests. Not even enough information to do a > `git merge-base master` without making an assumption that the > commits are tracking `master` branch. Can you look at @{upstream} or @{upstream}@{1} or some such to see what's changing in the new branch?

Looks like we get that branch in a single clone [1], so the only thing I can think of is: All of the commits in the current branch that are not in a origin branch besides @{upstream}. That would probably be implemented as: The union of all commits in ${other_branch}..HEAD for ${other_branch} != @{upstream}. A somewhat tedious approach to collecting commits to test, and it would break if someone pushed a second branch that advanced the @{upstream} commit (e.g. carrying a broken commit into a followup PR). But it might be better than skipping the push tests altogether. On the other hand, it would be complicated, so I'm fine with a -skip-travis-push flag that adjusts the TRAVIS_COMMIT fallback. I'm also OK making the TRAVIS_COMMIT fallback a single commit, replacing the current: commitRange = os.Getenv("TRAVIS_COMMIT") with: commitRange = os.Getenv("TRAVIS_COMMIT") + "^.." + os.Getenv("TRAVIS_COMMIT") [1]: https://travis-ci.org/vbatts/git-validation/jobs/226496023#L110

[vbatts]

@wking not sure what to say about that right now

[wking]

On Thu, Apr 27, 2017 at 11:07:06AM -0700, v1.0.0.batts wrote: @wking not sure what to say about that right now

I'm fine with the flag you landed in #29. If somebody ends up needing some push tests we can come back and look at the other options I'd floated.