Build checks out an old (i.e., non-latest) Git revision

Symptoms

Build configuration has Checkout Rules, and a Pull Request that modifies the files matched by the checkout rules is merged without conflicts using the merge policy, creating an empty merge commit.

*   abc1234 Merge PR #123
|\ 
| * def5678 Change some files
| |

A build starts at the target branch, but the non-latest commit (def5678) is checked out.

Why was the non-latest commit checked out? Is it possible to make the build to check out the latest revision, i.e., the merge commit that modifies 0 files (abc1234)?

Cause

There are checkout rules in the build configuration, and an empty merge commit doesn't modify any files.

The latest commit is considered irrelevant in this case because it doesn't modify any files relevant to the checkout rules.

Resolution

Option 1

Change the merge method to Squash or Rebase. Those methods don't result in an empty merge commit at the tip of the target branch.

Option 2

To keep the merge strategy unchanged while also obtaining the hash of the empty merge commit (e.g., for passing it to a downstream build or external tool), use a Command Line build step to run a Git command that returns the required revision. Example:

git rev-list %build.vcs.number%..origin/master --ancestry-path --merges | tail -1

Note: This option won't work with a shallow clone. If your build agent is an ephemeral (cloud) agent configured to terminate after the first build, you will need to change the root's Checkout Policy to 'Use mirrors'. Otherwise, the 'Auto' policy will resolve to 'Shallow clone'.