JetBrains TeamCity Blog

Scenario

You’re running an OSS project* and someone makes a pull request. You’ve got two choices:

• Merge and Pray
• Pull to local branch, build, run tests and merge if all OK

What do you do? Well, what is it going to be?

I know what I’d like to do, and GitHub makes it so so tempting:

But unfortunately I go with the second option.

That’s a pain, specially if you do a quick code-review and things look decent. Yet you still need to make sure that it builds and all tests pass.

Well there is a third way. And what’s even nicer, is that it’s also possible with TeamCity.

*This applies to non-OSS too

Automatically Building All Pull Requests

What I want to do is have TeamCity automatically build all Pull Requests for me of my main repository, and notify me if it is successful. And I want this to happen without me having to configure every single fork as a repository in TeamCity, because like that, it wouldn’t be manageable. Here’s a diagram explaining it:

This will drastically improve the workflow since we no longer have to manually create a local branch of the pull request, check it, build it and only then merge it.

Configuring TeamCity

Setting up TeamCity to do this is really simple. It actually only requires one thing: configuring the Branch Specification under the VCS root:

Let’s see what this means and why it works. When a pull request is made, GitHub automatically creates a reference that holds the pull request as well as one that is a merge with the master branch. What we’re saying to TeamCity is to monitor this branch, in addition to the main branch. In this syntax, pull refers to the pull request. The * refers to ANY pull request, and the merge indicates that we’re interested in the pull request merged with the master branch. This means that when TeamCity builds, it will build the branch that was merged. If we want to build the branch, without merging, we could use the following:

+:refs/pull/*/head

So to recap, adding merge builds the result of the merge, and adding head, just the pull request without the merge.

The result of these builds show up in TeamCity like so:

where the number denotes the pull request. Now, we can actually make this a bit nicer by allowing us to see whether the particular request was the result of a merge or just the branch itself. For that, we can specify the following in the Branch Specification

with TeamCity now indicating whether this was a merge or head:

In addition, TeamCity also provides us with a Dropdown, where we can filter all the different pull requests:

Seeing notifications on the Pull Request

As this is a normal build, like any other build, we can configure TeamCity to receive notifications via email, tray icon, etc, both on successful builds as well as failed builds. However, there is one other thing that we can do: see the result of the build on the Pull Request page on GitHub. In order for this to happen, we do need to install a plugin for TeamCity which currently doesn’t ship out of the box. This plugin, written by Eugene Petrenko uses some hooks GitHub provides to add notification information on the Pull Request page.

To install it, download the plugin as a zip file and place it in the plugins folder of the server and restart the server.

Once that’s installed, we can now display build status information on the GitHub pull request by adding a Build Feature to our Build Steps:

and filling in some simple configuration parameters:

And with that, we can see the status on the Pull Request page on GitHub.

* If you’re running your OSS project on TeamCity at CodeBetter, you now have this plugin available.

Summary

Although my example was based 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 repositories also, hopefully making things a little bit easier.

We’re happy to tell you that TeamCity 7.1 is officially released! If you were following the early access program, you may have noticed that in this release we were mostly focusing on enhancing support for distributed version control systems, such as Git and Mercurial, making the daily work with branches smooth, clear and easy. So give a warm welcome to Feature Branches in TeamCity and check them out!

As you know, Feature Branches in DVCSs like Git and Mercurial allow you to work on a feature independently from the repository and commit all the changes for the feature onto the branch, merging the changes back when your feature is complete. This approach brings a number of advantages to software development teams, however in continuous integration servers that do not have dedicated support for it, it also causes a number of problems, like constant build configurations duplication, poor visibility and in the end loss of control of the process.
Our main idea was to make development and building in branches as simple as possible. Ideally, all you would have to do is to push your branch to a Git or Mercurial repository and TeamCity would detect it and start a build on your changes. And this is how it actually works in TeamCity 7.1! You need to make only one tiny change in your build configuration – let TeamCity know which branches you want it to monitor.
So, here are some highlights:

• Once a change is detected in a branch, TeamCity will start a build in this branch.
• All the builds from branches are marked with branch labels to distinguish them from one another.
  
• In various places in TeamCity UI you can filter builds by branch label: filter all build configurations of a single project, or history, change log, issue log and pending changes for a specific build configuration.
  
• Get a bird’s-eye view on the status of active branches in a build configuration on the dedicated page.
• Run custom builds for specific branches.
• Use all regular TeamCity smart features such as quiet period, per-checkin triggering, dependencies, notifications, new failing tests detection, and so on with DVCS branches!

There’s a lot more to this huge feature, because it relates to many aspects of continuous integration experience, so please make sure to read the release notes to get the full taste of all the goodies we brought to you in this build.

In addition to all that we have also made a number of improvements in different areas:

• Current problems are now shown for collapsed configurations.
• Sticky investigation: the right way to investigate flickering tests.
• Version Control Repository browser: use a tree view to choose a file in the repository instead of typing or pasting the path.
• NTLM HTTP authentication is supported.
• Manually mark build as successful or failed.
• More options to control build steps execution.
• Checkout on label in Perforce integration.
• Bundled Xcode runner.
• Amazon EC2 EBS-based instances support.
• and much more….

Download TeamCity 7.1.

Enjoy!

Today’s EAP build is all about significant improvements in Feature Branches support. Since the release date approaches, we’re focusing on polishing already introduced features and fixing known issues. Here’s what we have for you this time:

• Extended branches specification syntax: When you describe branch specification, you now have more control on what will be shown as a branch label in TeamCity UI. For instance, type something like this:
  +:refs/heads/release-(7.0)
+:refs/heads/release-(7.1)
  TeamCity will use label 7.0 for builds from refs/heads/release-7.0 branch and 7.1 for builds from refs/heads/release-7.1.
• Branch labels for builds from default branch: Now builds from default branch also get labels.
• Branch selector on overview and project page: We’ve added an ability to switch between branches to both Overview and Project pages.
  
• Branches tab in build configuration: Want to see an overview of what is going on in each active branch? There is a new build configuration tab to answer exactly this question:
  
• VCS branch parameter: For Git & Mercurial TeamCity provides additional build parameters with names of VCS branch used by the build on the moment of starting.

See the complete release notes, back up your TeamCity instance, try the build and share your feedback with us!

Stay tuned!

Another update for TeamCity is now available – TeamCity 5.1.2, which might be especially interesting for those who use Git with ssh protocol or Visual Studio add-in. This version contains a number of improvements and fixes in these areas and is considered to be more stable; plus, it includes some other fixes.

See the complete list of changes, download the build and share your feedback with us. Do not forget to backup your data before upgrading.

The JetBrains TeamCity Team

A fresh update for TeamCity is now available – TeamCity 5.1.1. Since this release, the Check out on agent feature has become available for Git.
Furthermore, a number of bug-fixes included.

Take a look at the release notes, download the build and tell us what you think. Don’t forget to back up your TeamCity data before upgrading to a new version – just to be on the safe side.

Sincerely,
JetBrains TeamCity team.