TeamCity say you should tie your builds to the /merge for CI, this will build the merge result, and I agree.

However lets look at what happens in GitHub when we merge in Feature 1.

The new code goes into master, which will recalculate the merge result on Pull request 2. TeamCity correctly builds the merge reference and validates that the Pull Request will succeed.

However if we look in GitHub we will see the below

It now blocks you and prompts you to updates your branch.

After you click this, the /head and /merge refs will update, as it adds a commit to your branch and recalculates the merge result again, then you need wait for another build to validate the new commit on your branch.

This now triggers a second build.And when it completes you can merge.

The issues here is we are double building. There is two solutions as I see it,

GitHub should allow you top merge without updating your branch

TeamCity should allow you to trigger from one ref and build on a different one

I was able to implement the second result using a build configuration that calls the TeamCity API to trigger a build. However my preference would be number 1 as this is more automated.

Inside it looks like this

Below is example powershell that is used in the trigger build, we had an issue with the SSL cert (even though it wasn’t self signed) so had to disable the check for it to work.

One thought on “GitHub Pull Request Merge Ref and TeamCity CI fail”

This is after I mentioned that the merge reference is recommended by teamcity, Travis, and appveyor

—–

The ref/pull/$id/merge reference is an undocumented implementation detail of the “Merge pull request” button. We make no guarantees that this will not be changed or even exist in the future, which is why we do not recommend relying on it, along with the caveats that I mentioned in my last reply.

I realize the merge ref is convenient, but for your purposes it’s inaccurate and could lead to your test builds not matching what is actually merged into your production branch. It’s also not guaranteed to exist at the exact moment when code is pushed, but is regenerated asynchronously. This is an issue that the CI services have to deal with as well. While we have some active discussions around improving this experience, there’s no timetable for the change.