TRAVIS_COMMIT is not the commit initially checked out

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.

It is getting even better at an initial git checkout $TRAVIS_COMMIT is failing, seems like the very commit being tested is not even present in the repository…?

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.

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?

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.