TRAVIS_COMMIT is not the commit initially checked out

1

I’ve been debugging some CI issues that came up today (after the repo lay dormant for some months so no CI ran), and I noticed something odd: the commit shown by git show is not the same as the one in TRAVIS_COMMIT! For some examples for this, check this or this or this.

I did not push to the PR between the job being created and the job running, so that’s not the problem. Instead there seem to be two merge commits merging the same two parent commits: This one and this one, and it uses one for TRAVIS_COMMIT but checks out the other. Hu?

I’ve added git checkout $TRAVIS_COMMIT to our build scripts and that in fact fixed (one of) the issues we had.

1 Like
2

It is getting even better at https://travis-ci.org/wlanslovenija/tunneldigger/builds/548248377: an initial git checkout $TRAVIS_COMMIT is failing, seems like the very commit being tested is not even present in the repository…?

3

For pull request builds, Travis checks out a “merge preview” commit provided by Github. You can see that if you expand the git clone fold in build log.

4

So TRAVIS_COMMIT is supposed to be the “head” of the PR, while the checked-out commit is the head merged into current master?

I guess that makes sense. But then it is still a bug if TRAVIS_COMMIT is not even present in the repo, right?

5

I don’t know the details of how this is implemented at Github side, you can take a look at Checking out pull requests locally - GitHub Help to try to figure that out.

What I do know is that this most probably has nothing to do with Travis and everything to do with git and/or Github machinery. Most probably, the commit hash that TRAVIS_COMMIT is set from is sent by Github in the push webhook event payload; and you can view the contents of this commit at Github by clicking its hash in the build info banner at the build page.

6

I’m experiencing the same exact problem.
In a TravisCI job for a push event, I have that

TRAVIS_COMMIT=7532041bd7151db5a162afe61cc815df87dc4cd1

But running git log --format=oneline --max-count=3 in the same job prints out

12f94b7cbbe691427c614186cf07d0ca647279e5 (HEAD) Merge a8a14627bb73b46af5b4d3e6087fe549bcc679a1 into ec7684e4fe112e596dd8046be76db005e6c0a576
a8a14627bb73b46af5b4d3e6087fe549bcc679a1 Use 'cron' instead of 'scheduled' to identify scheduled events
ec7684e4fe112e596dd8046be76db005e6c0a576 (origin/master, origin/HEAD, master) [skip ci] Update README.md

I’d expect that TRAVIS_COMMIT contain 12f94b7cbbe691427c614186cf07d0ca647279e5 instead of 7532041bd7151db5a162afe61cc815df87dc4cd1

PS: both 12f94b7 and 7532041 commits seem to be same “merge” commit, the two patch files are exactly the same but still they have two different SHA-1.

8

It seems that it’s not the case: see the following commands, which always display the same merge commit SHA-1:

$ git ls-remote https://github.com/mlocati/ci-info.git refs/pull/10/merge
69825df7c60b46c8849a1818df05e19de95513cd        refs/pull/10/merge
$ git ls-remote https://github.com/mlocati/ci-info.git refs/pull/10/merge
69825df7c60b46c8849a1818df05e19de95513cd        refs/pull/10/merge
$ git clone --quiet --depth=50 https://github.com/mlocati/ci-info.git tmp
$ git -C tmp fetch --quiet origin +refs/pull/10/merge:
$ git -C tmp checkout -qf FETCH_HEAD
$ git -C tmp log --max-count=1 --format=format:%H HEAD
69825df7c60b46c8849a1818df05e19de95513cd
$ rm -rf tmp
$ git clone --quiet --depth=50 https://github.com/mlocati/ci-info.git tmp
$ git -C tmp fetch --quiet origin +refs/pull/10/merge:
$ git -C tmp checkout -qf FETCH_HEAD
$ git -C tmp log --max-count=1 --format=format:%H HEAD
69825df7c60b46c8849a1818df05e19de95513cd
$ rm -rf tmp
$ git ls-remote https://github.com/mlocati/ci-info.git refs/pull/10/merge
69825df7c60b46c8849a1818df05e19de95513cd        refs/pull/10/merge
$ git ls-remote https://github.com/mlocati/ci-info.git refs/pull/10/merge
69825df7c60b46c8849a1818df05e19de95513cd        refs/pull/10/merge
2 Likes
9

I think I know what’s happening. For a PR build, Travis actually retrieves origin/refs/pull/<PR#>/merge – a “merge preview” commit generated by Github.

Looks like it’s generated anew each time the PR branch or the base branch changes:

I don’t know if there’s some other way to retrieve that merge preview commit that would allow one to retrieve an earlier version of it that would correspond to the time the specific PR commit was pushed.