technology from back to front

Continuous Integration for Github Pull Requests with Teamcity

Most developers with an interest in open source software these days have seen the Github interface for handling pull requests, and relatedly, Travis CI’s support for pull requests. And so we thought it’d be useful to have something similar for our internal CI system.

So, Github has the rather nice (albeit poorly advertised) feature that whenever a pull request is raised, they add a reference for both the HEAD revision of the remote branch, and a commit which merges said HEAD revision into master. For example:

: ceri@misssplendid; git ls-remote origin | fgrep pull
9d1b88f3a67d2704e08b142b776136ddb1bdf3c1    refs/pull/1/head
454fd4ab3d439e5b10c68b98ea60fbf7a0bf81cb    refs/pull/1/merge
80b11080005b5176564c369e1b4053268d3d4efb    refs/pull/2/head
2222b016401e0b3dc9e7455aeeeeef9a2c4a3b26    refs/pull/2/merge
358197ab037e5f50417ed7f5ea3d977e53a08006    refs/pull/3/head
371e7f88898217a72d5bd8322304bc1fc6b8e8ee    refs/pull/3/merge
: ceri@misssplendid;

Now, it’s possible to Configure git to fetch pull requests so you can check them out locally, but we can use this same trick to configure Teamcity (or another build CI system) to build and test our pull request applied to master.

Assuming that we already have a configuration to build the master branch of a project, then under “Version Control Settings”, and within the appropriate “VCS root”, add the following to the “Branch Specification” field:

+:refs/pull/*/merge

Once that’s saved, Teamcity will start polling all references for merged pull requests from github. Then the next time someone pushes to a branch referenced by a pull request, then it should show up as a branch under the build in Teamcity and (if configured to do so) be automatically built.

We haven’t gotten around to shaving the Github commit status API integration Yak just yet, but we’d love to hear if anyone has.

by
Ceri Storey
on
13/01/13
Comments
6

  1. Dmitry
    on 04/02/13 at 3:14 pm

    Hi,

    here is a TeamCity plugin that sets a github commit status: https://github.com/jonnyzzz/TeamCity.GitHub. For some reason github shows status only for refs/pull/XXX/head, but not for refs/pull/XXX/merge.

  2. Ceri Storey
    on 04/02/13 at 6:07 pm

    Sorry it took so long to approve your comment Dmitry, I’ve only just seen it. :/

    You’re right, it looks like github’s status api associates the status with the commit id, and so because the merge commit from refs/pull/XXX/merge isn’t actually contained within the pull request, it doesn’t get shown.

    I guess what’s needed is to put the status on the mainline parent of the generated merge commit, if that’s possible.

  3. Automatically Building Pull Requests from GitHub with TeamCity « Hadi Hariri's Blog
    on 07/02/13 at 3:11 pm

    [...] on TeamCity 8.0 which is currently in EAP, this feature also works with TeamCity 7.1.3+ (and even previously covered by others). The examples are also based on OSS projects, but you can apply the same workflow to private [...]

  4. Brandon
    on 15/03/13 at 9:17 pm

    Hello, I have Teamcity setup as described such that it picks up the pull requests. However, the builds are not automatically triggering.

    From your article:

    “…then it should show up as a branch under the build in Teamcity and (if configured to do so) be automatically built.”

    I can’t for the life of me figure out how to configure Teamcity to automatically build the pull requests, can you describe to me what I am missing in order to get the builds to fire automatically?

  5. Ceri Storey
    on 16/03/13 at 2:03 pm

    I’m afraid I don’t know off-hand. Assuming the branches are showing up under “Branches” in the project, and if it’s picking up and auto-building changes from

    master
    then it should be working fine.

    Two points that I can think of to look at would be:

    • This will only work if the pull request is mergeable–github will not create a merge refspec if the merge would result in conflicting changes.
    • Checking that the remote github references are actually getting updated: a good way to do this is to use the
      git ls-remotes
      command in the article to check that the remote merge refs are changing.

    Otherwise, it should work as with any other set of branches. Sorry I can’t be of more help :/ (and for the late reply!)

  6. Brandon
    on 18/03/13 at 5:39 pm

    Thanks I appreciate you taking the time. The pull request branches do show up under ‘branches’ and when I push to the master, the builds auto trigger, but they don’t auto trigger on the pull request. They just sit there in TeamCity as pending changes. I have to manually run the builds on that branch. There are not any merge conflicts either. I am pulling my hair out. Thanks again. Despite my problem, this article was a big help.

 
 

Search

Categories

Feeds

2000-13 LShift Ltd, 1st Floor Office, Hoxton Point, 6 Rufus Street, London, N1 6PE, UK +44 (0)20 7729 7060