We have created a TeamCity User Guide as a series of screencasts.
An outline of the table of contents is:
The entire course duration is under an hour. You can view it entirely for free either on JetBrainsTV or on our YouTube Channel. Enjoy!
You’re running an OSS project* and someone makes a pull request. You’ve got two choices:
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
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.
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:
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.
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.
This free webinar will take place on August 20th at 4 pm CET (Central European Time). Click here to register. Seats are limited so don’t delay!
Paul Stack is a London based developer working on the .net technology stack. He has spoken all over the UK about his passion for continuous integration and continuous delivery and why they should be part of what developers do on a day to day basis. He believes that reliably delivering software is just as important as its development.
You can follow him on twitter @stack72 or read more about him on his blog.
This summer we will be visiting two User Groups in Switzerland to talk about some of our tools among other things.
The events are organized in collaboration with the local User Groups of Berne and Lucerne:
If you’d like to attend the event, I’d recommend you sign up as places are limited.
Date: Tuesday 3rd July – 6 to 9 pm
Topics:
ReSharper Tips’n’ Tricks
Real World MVC
Registration, Location and more info: User Group Web Site
Date: Wednesday 4th July – 6 to 8:30 pm
Topics:
ALM with JetBrains Tools (covering TeamCity, YouTrack et al.)
Real World MVC
Registration, Location and more info: User Group Web Site
All registrations are handled directly by the user groups. Please contact them (via their web site) if you have any issues.
Hope to see you there!
TeamCity 7.0 EAP (Early Access Program) was recently opened and one of the new features is the built-in support for NuGet. I recently blogged about setting up TeamCity to pack and publish NuGet packages via a plug-in and this plug-in is now included by default in TeamCity 7. However, the real new interesting feature is that TeamCity is now a native NuGet repository too!
Many of those that have been using NuGet, have most likely been using it to consume packages from nuget.org where there are currently over 3800 unique packages, most of which are open source.
What happens however if for some reason or another you do not want to submit packages to nuget.org? For instance, think that you want to use NuGet to modularize and distribute code inside your own organization, or create libraries for private consumption. In this case, publishing to nuget.org does not make sense. This leaves you with basically two options:
Both of these options come with their own share of overhead. With the local share you now require sharing of folders and permissions. Setting up your own NuGet repository also requires managing permissions and whatnot separately. At the end of the day, its another service to manage.
Fortunately, you now have a third option: TeamCity. The same server that builds your projects, runs your tests, packs and publishes your packages can now also serve them. The best part of it is that it is so simple, that I had to take up the rest of this blog with the previous nonsense just to give it some meat.
I am not going to cover how to pack and publish packages in this post. All that is covered in detail in the previous post I wrote, so please read that first if you’re not familiar with the process. Enabling TeamCity as NuGet and making packages available consists of two steps:
Go to Administration | Server Configuration | NuGet tab
Click on the Enable button to enable it. The same screen with then display two different feeds: a public and a private one:
If by chance the Public Url is not available, you will probably see a message telling you that you need to enable the Guest account in TeamCity, which can be done from the General tab.
Since TeamCity itself is going to be a NuGet server, the step to publish a package is no longer required. However, packing the package is. In this step (NuGet Pack Build Type), we can just configure the output for the package to point to some specific folder, for instance packages
We need instruct TeamCity to ouput the results of this folder as artifacts. This is done in the General Settings step of the Build Configuration
and with that, we’re done. Next up is to configure Visual Studio to consume from this feed.
Although this step is optional, it is recommended to add your repositories to Visual Studio to avoid having to type long URL’s in each time you want to read from a specific package repository. To do this, click on Options | Library Package Manager | Package Manager Settings
We need to add a new NuGet Repository. I’ve called it Local TeamCity and the URL corresponds to the public URL provided to me by TeamCity in Step 1:
Notice that I have another entry which is Local TeamCity Auth which corresponds to the authenticated version.
Once we have this, we can now easily consume packages from our repository by merely specifying it in the Package Manager Console, either via the Combobox or explicitly in each call:
That’s all there is to it. By merely publishing our packages as artifacts, TeamCity now provides a full-fledged nuget server which opens up great possibilities when it comes to working and managing dependencies between projects. TeamCity is currently in EAP and much of what I’ve described here is in open to improvements. That is why your feedback is very important. Download 7 and start playing with it today. Let us know what you think.
Twitts about TeamCity