Why doesn't the Travis git ref match my pull request sometimes?

I have a Travis-CI script that checks the commit messages of pull requests. GitHub gives it a range of commits and it uses git log --format=online "<lastref>..<firstref>" to build the list of SHAs to check.

This works great most of the time, but occasionally this happens:

My pull request (merging branch 2.2 into 2.x, several commits) yields this command on Travis:

git log --format=oneline b5d12909dacd80d21c4e4f4ca6d5683d6e547f9e..b349be9418371c1f694dabeccbce0e946fde3a0a

Locally, this works as expected. I get the commits in the PR. On Travis, though, the b5d129 commit does not appear, and so it dumps out every commit back to the beginning of the project.

What's going on here?

Update: I made another merge PR, this time with Travis's default git clone depth of 50, but also not including a new commit on 2.x. In any case, the build for this new PR worked correctly. I'm still stumped. Clone depth shouldn't have any effect because the checkout would fail if it didn't have the necessary commits.

Clone depth shouldn't have any effect because the checkout would fail if it didn't have the necessary commits.

If the issue is clone depth, you have to realize that your latest commit does not rely on all the commits that came before it. Each commit is a complete "snapshot" of your repository, and can work independently. Even if you cloned with a depth of 1, that commit would have all the information needed to checkout/build/deploy/etc, as long as that commit is the one that the branch's HEAD points to. The small deltas you see in GitHub or git show are just diffs between the commit you're looking at the one that came before it (the commit parent).

If these Pull Requests have more than 50 commits, then I think the behaviour you're seeing is somewhat expected. I'm not sure if Travis lets you set clone depth to anything higher that 50 (or disable it altogether), but I have a feeling that would resolve your issue.

Recommended topics

Hot tags