TeamCity building Git / GitHub pull requests

11
votes

We have a TeamCity 7.1 installation that builds all branches from a GitHub repository.

GitHub has a notification hook back to TeamCity to trigger a build on check-in. We also have TeamCity polling GitHub every 120 seconds to check for changes (in case the server was offline when a change was checked in).

Our normal development follows a common pattern:

  1. Create a branch from master
  2. Commit to that branch until finished with a feature
  3. When finished, pull from master to merge any changes and push to remote
  4. Submit a GitHub pull request to allow the admins to merge into master

Everything is working swimmingly (after much searching to get the correct configuration settings) however...

The above process triggers several builds on TeamCity and I'd like to know whether they're all necessary. Typically we'll end up with:

  • A build for /refs/heads/branch-name
  • A build for /refs/pull/number/head
  • A build for /refs/pull/number/merge

Naturally the first build is the last check-in on the particular branch, and the second build is the pull request, but what is the third build for?

3
gitgithubteamcity
Typically this wouldn't be a problem but running our entire RoR test suite with integration tests is taking ~10 minutes, so we're not getting build-status feedback on the pull requests for up to 30 minutes. – asafb

3 Answers

13
votes

Third build is actually the most valuable — it's the result of pull request auto merge (merge that happens, when you press the button at github).

3
votes

Your builds seem redundant. The more thrifty way to organize TeamCity builds of feature-branches in git is as follows:

  1. Organize continuous integration of your refs/heads/master branch. 120 seconds poll is quite reasonable here.
  2. Organize nightly-builds for every refs/heads/feature-name branches. As of my experience, only a few of the feature-branches require 120-seconds polling.

TeamCity 7.1 has a very nice feature to autotrigger feature-branches, so step (2) can be setup in a couple of clicks with a branch mask like refs/heads/feature-*.

There is no meaning in building pull requests since they will be covered by master builds.

0
votes

Updated answer, in case someone still uses TeamCity 😉

Since 2018, there is a native Pull Request Build Feature. This is a better solution compared to using branch triggers & filters, since it creates a two-way link between the build and the corresponding PR and frees you from having to add any refs/pull/... to the VCS Branch Spec.

Still, if you insist on using pull/*/merge: note that this creates superfluous builds in case the "Require linear history" (=only allow Rebase & Squash merges from PRs) feature is enabled on the GH repo, since a PR in such case can only be merged once it is up-to-date with its base branch anyway.