JetBrains TeamCity Blog

Today’s TeamCity 7.0 EAP is the last EAP build with new features in it, as starting from it we are going to focus on fixing bugs and polishing already announced functionality. So basically, this build is more or less what TeamCity 7.0 is going to look like. So here’s what we have for you today.

REST API

A feature request to allow build configuration editing via REST, that has been around for a while, has finally been implemented, so now you can get complete settings of a build configuration or template via REST and change them as well. Moreover, you can create and delete build configurations, projects and VCS roots.
See the details in release notes.
We would appreciate if you could try the updated REST API and let us know about any issues or suggestions that you might have.

Dependencies Graph

If you have been following the EAP program you’re probably already familiar with the new Dependencies graph that shows all build chains of a particular configuration or a build.
However, with this EAP build you will have much more control over your build chains, for example start dependent parts of the chain using the same revision for dependent builds.
The whole thing is similar to a “pipeline”, at any stage of your release process you can easily prolong pipeline to some further stage.

NuGet

TeamCity now uses Java based back-end for handling NuGet feeds. This should simplify setup of NuGet in TeamCity and as an additional benefit you can use TeamCity NuGet feed feature if server is installed on Unix.

Maven

Both Maven2 and Maven3 are now bundled with TeamCity. You can choose required version of Maven on the Maven runner page.
Additionally you can instruct Maven runner to use unique local artifacts repository for the builds of build configuration.

See the complete release notes, back up your TeamCity instance, try the build and share your feedback with us!
We’re going to try to publish bug-fix builds more often than regular EAP builds, preferably once in two weeks, so stay tuned!

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!

Native NuGet Server?

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:

1. Setup your own NuGet repository by downloading and installing the code that nuget.org for instance
2. Copy nuget packages to a local share and have everyone read off of that

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.

Enabling TeamCity as a NuGet Server

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:

1. Enable the server to be a NuGet server

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.

2. Make your packages be your Artifacts

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.

Configuring Visual Studio

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:

Summary

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.

Today we’re making available yet another TeamCity 7.0 EAP build with lots of cool stuff in it. As usual, you can get a taste of features that are going to be in version 7.0 even before it is released. So if you’re wondering, what is there – here’s a list of things you couldn’t do before, but can try out now:

View investigations assigned to you at one page

Previously, there was no specific place where you could see all investigations assigned to you. Of course you had notifications, and you could see this information in each particular build configuration, but it would be much more convenient to have a dedicated page for that – who knows how many projects and build configurations are affected by your changes and in how many of those you are supposed to investigate failures. Now it’s easy to take a glance at the whole picture – just click a little box with a number next to your name.

Drill down inside artifact archives

It is now super easy to browse inside artifact archives right from the TeamCity web interface!

Moreover, you can download some particular file from an archive using new URL syntax:
http://<server url>/repository/download/<build conf id>/<build>/<archive>\!<path in archive>
Plus it made easier configuring Report Tabs.

Disable build steps, triggers and more

Since we have introduced build steps, one of the most awaited features was an ability, to temporary or permanently disable some setting in build configuration. For example, if you have a configuration inherited from a template. Now you got it! Even better, you can not only enable/disable build steps, but also build triggers, build features and build failure conditions!

Use TeamCity as NuGet feed

TeamCity now can act as NuGet server serving NuGet packages published to TeamCity as regular build artifacts. When a build publishes NuGet package as artifact it is automatically added to TeamCity NuGet feed. This feature needs to be enabled explicitly on Administration -> Server Configuration -> NuGet tab.
Note, current implementation of NuGet shows all found packages within TeamCity installation. Access rights are only checked on downloading packages bits. There is a related issue for it though: TW-19157.

Work easier with agent pools, dependencies, R# inspections and so on

Of course, we also greatly improved features introduced in earlier EAP builds.

• For agent pools we’ve added ability to filter build queue by an agent pool; added grouping by agent pool on Agent Matrix and Agent Statistics pages; redesigned Compatibility pages; and more.
• .NET Inspections runner was improved in order to work correctly with LINQ usages, Silverlight projects, External annotations usages (NUnit) and Web Site, Asp.NET MVC projects.
• Dependencies graph introduced in previous EAP was greatly improved
• and much more – see the release notes.

Don’t forget to back up your TeamCity instance, try the build and help us make another one better for you!

Enjoy!

TeamCity uses Service Messages to provide an easy API to allow for build scripts integration, i.e. the build providing status reports, artifacts publishing, test reporting, etc. A Service Message has the following format:

##teamcity[hello message='teamcity' version='6.5.x' comment='awesome']

Service Messages introduce a communication protocol for data exchanges  between processes using streams, sockets, HTTP or pipes.

I’ve created a wrapper to allow for easier interaction with TeamCity Service Messages, providing it as a package available on NuGet.

Usage

The library contains two main classes. One for reading and one for writing service messages.

Reading service messages

Reading service messages can be done using a TextReader or string with minimal memory requirements:

  using JetBrains.TeamCity.ServiceMessages.Read;
  ...
  var parser = new ServiceMessageParser();
  using(TextReader reader = ... ) {
     foreach(var message in parser.ParseServiceMessages(reader)) {
        /// process IServiceMessage object
     }
  }
  ...

Parse method gives us an IEnumerable of IServiceMessage:

  public interface IServiceMessage
  {
    [NotNull]
    string Name { get; }
    [CanBeNull]
    string DefaultValue { get; }
    IEnumerable<string> Keys { get; }
    [CanBeNull]
    string GetValue([NotNull] string key);
  }

The Name is the name of service message, i.e. ‘name’ in ##teamcity[name'aaa'].
The DefaultValue contains simple value, i.e. ‘value’ for ##teamcity[name 'value'] or null for service message with attributes, i.e. ##teamcity[name tea='hot' ice='cold']. To access service message attributes use Keys property and GetValue method.

Writing service messages

To create a service message you may use anonymous type for service message attributes:

using JetBrains.TeamCity.ServiceMessages.Write;
....
string serializedMessage
  = new ServiceMessageFormatter().FormatMessage(
        "rulez",
        new {
          Version = "3.2.2",
          Mode = "zoom"
        }));
/// returns:  ##teamcity[rulez Version='3.2.2' Mode='zoom']
...

The previous is the simplest way for creating service messages, although you may use a strongly typed approach:

using JetBrains.TeamCity.ServiceMessages.Write;
....
string serializedMessage
  = new ServiceMessageFormatter().FormatMessage(
        "rulez",
        new ServiceMessageProperty("Apple", "239"),
        new ServiceMessageProperty("Pie", "42")
  ));
...

Summary

The source code for the project is available on GitHub and the build is at TeamCity.CodeBetter.Com and with TeamCity support for NuGet, it automatically publishes the library as NuGet package on NuGet.org. For a full description of the format and usages of Service Messages see the Build Script Integration with TeamCity article.

New TeamCity 7.0 EAP build is ready and waiting for you to try! We have improved features introduced in the first EAP build, and of course we’ve got some completely new stuff.

.NET Inspections runner

Yes, it’s finally here and it’s based on powerful ReSharper code analysis engine! Now you can run .NET inspections and see the results right in TeamCity.

Global Maven settings

Previously you could specify path to alternative user settings file (equivalent to Maven command line option -s or –settings) in build configuration.  Now you can define these settings xml files globally in Server Configuration area, and use them in your Maven builds. When you create or modify a build configuration you will only need to select, whether you want to use default settings file (chosen by Maven), specified by path or global (uploaded on server). Since TeamCity stores these files under <TeamCity Data Directory>/config/_mavenSettings , you  can update them there whenever you need.

Per-check-in builds

If you have fast builds, you can now trigger them for each check-in, or for a group of check-ins made by the same user. Why? Thus you will see right away who broke what! When a build contains one check-in, or a couple of check-ins by one user, there can be no doubts, who’s responsible for a new failed test.  ;)

Fail build on a specific text in build log

We’ve already mentioned this feature in one of the recent posts, though we have improved it since then and we would like to hear your feedback on it.

Graph of commits

If your project uses Git or Mercurial you can see graph of commits on build configuration change log page. Graphs are also useful for non-DAG-based VCSs: they make it easier to understand where a VCS root modification comes from.

…and the rest gets only better!

We’ve improved, reworked and made better:

• Administration interface for Agent Pools
• Snapshot dependencies graph
• Tree view in build log
• NuGet integration
• and more…

Don’t forget to back up your TeamCity instance, try the build and help us make another one better for you!

Happy building!

Look out world, we have just opened early access program for the next TeamCity version: code name Faradi. That means you can download the first TeamCity 7.0 build right away and try all the cool features that are in it. Want to know what features are there? Here’s a list:

Build Failure Conditions – Smart Control Over Your Build Status

TeamCity has become smarter in deciding when a build is to be considered “failed” – now it can look beyond the obvious like exit code or failed tests presence. Basically, you can instruct TeamCity to mark a build as failed if it has become “worse”. There is a number of metrics in TeamCity already to measure how “good” a build is, like code coverage, or artifacts size, etc., so all you need now is set up the threshold for those metrics that are important to you. For instance, you can mark build as failed if code coverage or code duplicates number is worse than in the previous build. Learn more about this feature from the related post. However, that’s not the end of the story. Another build failure condition is on its way – it’ll allow to mark build as fail when a certain message is met in build log. This functionality is still quite raw though.

By the way, don’t panic when you don’t find good old “Fail build if” conditions that used to be at the General Settings page – we didn’t drop them, just moved to the new page with the rest.

Agent Pools – Better Agents Management

Starting with TeamCity 7.0 it’s easier to organize your build agents and calculate the required agents capacity. Instead of having a a single set of agents, you can now break it into smaller groups called agent pools. In two words, a pool is a subset of agents to which you can assign projects. Thus you can run your project on a subset of agents and make sure no other projects will run in the same pool.

Dependency Based Test Run – Faster Builds

Maven, Gradle and IntelliJ IDEA Project build runners now support dependency based run of tests. One of the best practices in software design is to make modules as independent as possible, and if you follow this practice, now you can get an extra bonus – faster builds in TeamCity, because TeamCity can run only those tests that are really affected by changes in dependencies.

Learn more in the release notes.

NuGet Support

TeamCity now comes with native NuGet support. The plugin that provides NuGet support has become available a couple of weeks ago, and now it is bundled with TeamCity. There was a series of blog posts dedicated to this plugin, so we won’t go into details here:

• http://blogs.jetbrains.com/dotnet/2011/08/native-nuget-support-in-teamcity/
• http://blogs.jetbrains.com/teamcity/2011/07/20/nuget-plugin/
• http://blog.jonnyzzz.name/2011/07/nuget-publish-build-runner.html

As a side note, the plugin is compatible with TeamCity 6.5, so if you want to use it in your existing production server, you can download it at teamcity.jetbrains.com.

And a bunch of other features…

… including build performance monitor, improved My Changes page and Build Log, support for Subversion 1.7 in Visual Studio Addin, and so on. See the complete release notes, try the build and share your feedback with us!

Don’t forget to back up your TeamCity instance, and note that starting with this version TeamCity server and agent require Java 6.0 or later.

Stay tuned, we’ve just got the ball rolling!

Today I’d like to share with you a plugin for TeamCity 6.5 that provides support for NuGet, the open source developer focused package management system for the .NET platform. What does the plugin bring?

NuGet Packages Installer

The plugin adds dedicated build runner that allows you to:

• Install NuGet packages without having to check them in to the version control, which comes in handy especially when using a DVCS, like Mercurial or Git. The problem and a workaround is also covered in David Ebbo post.
• Automatically update package dependencies to the most recent ones (optionally).

Note, that for installing and updating packages we use NuGet.exe install and NuGet.exe update commands respectively.

NuGet Packages Tab

Once you start using NuGet Packages Installer in your build, you most likely will need to know the exact versions of packages used in the build, and that’s very easy to do – they are listed in the build results at the corresponding tab: