JetBrains TeamCity Blog

“I see dead code” – .NET developers all over the world know this slogan due to incredible code analysis feature provided by JetBrains ReSharper. One of the most wanted TeamCity features was to have .NET inspections results right on build server. Starting with the latest EAP you have it!

The only thing you need to do to get all the benefits of ReSharper’s analysis right in TeamCity is to add Inspections (.NET) build runner as a build step to your build configuration.

Configuration is quite easy, so let’s just take a look at how the results look when this runner is configured – you can find them at the dedicated “Code Inspections” tab of the build results.

Here we’ve got all the usuall options like exploring overal inspections statistic, opening problematic sources in IDE, viewing inspections description, etc.

Moreover, using this build runner together with another fresh feature – build failure conditions, you can update your builds status based on of inspections results.

What’s next? First of all, in the nearest future it will be possible to share ReSharper inspections settings profile between your team members and use this profile in TeamCity build. More to come, you will be able to ask TeamCity to run custom inspections related to your code base as well.

As always, your comments and feedback are very much welcome. To try it, install TeamCity 7.0 EAP build.

Enjoy!

Previously described Fail build on metric change feature is not the only new way of controlling build status and detecting build failures. In TeamCity 7.0 we introduce one more useful feature that allows to mark build as failed, in case when certain line is met in build log.

Note, that you can instruct TeamCity to look for a line containing or matching a Java Regular Expression regexp text that appears/doesn’t appear during the build. When the condition is set, the interface looks like:

Here’s how a build failure looks when caused by such condition:

The feature is not completed yet, so your comments and feedback are very much welcome. To try it live, install TeamCity 7.0 EAP build, we recommend the next EAP build which is about to be released in the nearest future.

Enjoy!

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!

One of TeamCity’s remarkable features is a possibility to analyze the code of your application, find duplicates, show corresponding reports and charts. You can calculate code coverage metrics, run code inspections, and see results right in the TeamCity’s UI. And in most cases, these features work out of the box, without setting up additional external plugins.

All these code examining tools generate various numeric metrics, and you can see the dynamic of their change in the TeamCity UI.

What you could not do before (well, almost could not) is to specify metric thresholds, which would fail the build upon exceeding them. For instance, you couldn’t tell TeamCity that the build must fail if code coverage or code duplicates number is worse than in the previous build.

Corresponding requests stayed for a while in our tracker and collected quite a few number of votes:
- TW-2539 Inspection Build: fail if more inspection errors than in last successful build
- TW-3040 Make build fail if code coverage is below certain threshold
- TW-3041 Make build fail if code coverage is below previous code coverage value
- TW-4953 Setting to fail a build when number of found code duplicates exceeds some threshold
- TW-15679 Option to fail a build if a specific statistics value is below/greater then in last successful/tagged build

When we started pondering over the task, it became obvious, that it can be generalized. And besides code quality, we could consider other metrics, such as number of tests in a build or volume of published artifacts:
- TW-12449 Option to fail a build if test number drops
- TW-5451 Option to fail a build when not all artifacts are published (artifacts validation)

Moreover, if a build publishes its own numeric metric (and it is very easy to set up), this metric can also be used to determine build status.

So now you can specify several metric-based build failure rules for a build configuration:

or

As you see, you can create rules for both the absolute metric values, and for the difference with a previous build in the same build configuration. As a previous build anchor, you can use:
- last finished build
- last successful build
- last pinned build
- build with a specified build number
- last finished build with given tag

The default list of available metrics is:
- artifact bytes (you can fail a build, if not all artifacts were published, basing on their volume)
- number of tests in a build
- number of ignored tests
- code inspections: errors, warnings
- code duplicates count
- code coverage percentage – lines, blocks, methods, classes

To add your custom metric to this list, you have to change TeamCity’s configuration file main-config.xml (<TeamCity data directory>/config/main-config.xml) and add the following section there:

<build-metrics>
<statisticValue key="my_file_count" description="number of files"/>
</build-metrics>


So, if your build will publish value my_file_count, you can use it as a criteria for a build failure.

When build failure metrics are set up, the interface will look like:

When a build fails because of the bad metric value, it looks like this:

The feature is not completed yet, so your comments and feedback are very much welcome. To try it live, install TeamCity 7.0 EAP build, which is about to be released in the nearest future.

Java build tools are evolving constantly. Good old tools become better, while new tools appear frequently. One of the new ones, called Gradle, aims to bring together powers of Ant, Maven, Ivy, and spice them up with Groovy language. From the Gradle page you can learn more about its benefits.

If you feel interested in it, you’ll probably like that in TeamCity 6.0 we are going to add full-fledged Gradle support. A tiny piece of Graddle runner has already appeared in the previous TeamCity EAP. Since then we’ve done a lot of improvements:

• Better failing tests reporting.
• Correct reporting of tests executed in parallel tasks.
• Code coverage: activate built-in IntelliJ IDEA code coverage, and get overall and detailed coverage statistic.
• Build Properties configuration. Use build and agent properties inside your Gradle build.

If you already have a Gradle build, you are likely to be using Gradle-wrapper. Gradle Wrapper support is on its way as well, allowing you to create Gradle build configuration for TeamCity in no time. Just point TeamCity to your version control, mark appropriate checkbox – and you are ready to go! You won’t need to install and configure Gradle runtime distribution to any of your build agents.

Migration to Gradle is rather simple, or almost invisible, e.g. for maven2 builds. Try Gradle runner in the forthcoming EAP and tell us what you think!

It’s quite a typical case when you need to create several more or less similar build configurations in TeamCity, for example, to run builds in different environments, or create a separate build configuration for release builds, etc. Of course, you can simply copy build configurations, but what if you’ll need to change, for example, a VCS root in all of them? Naturally, you’ll have to manually change it in every configuration. Don’t you think it’s too much of routine work? We thought so too, that’s why in TeamCity there are build configuration templates. You can create a template with common (shared) settings and then inherit any number of build configurations from this template, or you can extract a template from any of your existing build configurations. Thus, when you’ll need to change some setting in all template-based configurations, you’ll just change it in the template.

One might ask what to do if you need to override a setting inherited from a template in one of the build configurations. If your template defines a specific value for this setting, every template-based configuration will have the same value and since it’s inherited it’ll be a display-only field. But there’s a trick! You can use a configuration parameter instead of an actual value in the template. Basically, such parameter is used inside TeamCity only, and it is not passed to an actual build, but it provides you with means to make your templates flexible.
Here’s an example to illustrate how it works. Let’s say I need to redefine Maven goals in my build configurations based on the same template. In the template settings, instead of actual goals I’ll introduce a configuration parameter:

Note, the syntax here is elementary – %ParameterName%. Now, if I’ll go to the Properties and Environment Variables section, I’ll see there this configuration parameter.

I can define a default value for goals, or leave it as is – in this case I’ll have to define it in every child configuration manually. Let’s say, the default should be test.

Now, I’ll switch to the build configuration based on this template where I’d like to have deploy goal instead of test, and redefine it there.

In our docs, you’ll find the list of settings that can and cannot be overridden with configuration templates. However that’s not the only use case for the configuration parameters. Now they are also used as some of the agent’s parameters, for example for .NET Framework/SDK/Visual Studio/Mono detected on an agent. These we’ll describe in detail in the next post, so stay tuned!

Have you already tried multiple runners in latest TeamCity 6.0 EAP builds? If you have, there’s no need to repeat that now you can split the build procedure into steps and add as many build runners to be invoked sequentially as you need, for instance, call a NAnt script before compiling VS solutions. Having this approach implemented, we decided to review existing .NET runners in TeamCity.

As you know, TeamCity provides bundled support of NUnit and MSTest. In previous versions you could configure running such tests within MSBuild and VS.Solution build runners. That was reasonably good and handy solution for everyone to run unit tests without writing a line of script/code. Nevertheless, we removed NUnit and MSTest options from these runners. Don’t worry! You’re not going to miss them. Instead, we’ve introduced separate NUnit and MSTest build runners which you can now add as a build step to your configuration.

If you previously used to run the tests by means of MSBuild and VS.Solution build runners, you probably won’t even notice the difference, because such build configurations will be just split into two build steps during upgrade.

But here goes nice news for those who combined NUnit tests with Rake runner, NAnt, or for some other reason had to pick up some convoluted way to pass test reports to TeamCity, like using TeamCity NUnit launcher from command line, or service messages, or TeamCity addin for NUnit, etc. Now you can forget about all those tricky configurations and relax. Just add one more runner.
Of course, all old approaches will still work, but will remain mostly for exceptional cases.

Enjoy!

In the latest TeamCity 6.0 EAP we’ve added new feature to Visual Studio add-in. Now it is tightly integrated with another popular JetBrains product – ReSharper! So if you have both ReSharper 5.0 (or later) and TeamCity add-in installed, you gain the following benefits:

• From the add-in’s Failed Tests tool window you can navigate to source code of a failed test.
• From the same tool window, you can re-run tests failed in a TeamCity build locally with ReSharper.

Note, that by “tests” we mean all kinds of tests supported by TeamCity and ReSharper.

This feature is just the beginning, we plan to greatly improve TeamCity integration with ReSharper, so there’s more features to come. As usual, we’re looking forward to your feedback and all the feature requests are trully appreciated.

Stay tuned!

In the first TeamCity 6.0 EAP you can find the long-awaited feature — build priorities; you asked — we did it. Moreover, since it is implemented as a Build Queue Priorities plugin for TeamCity, it is also available for TeamCity 5.1.x.

Now you can control build priorities by creating so-called Priority Classes — in two words, a priority class is a set of build configurations with a specified priority. Naturally, these classes can be configured from the Build Queue page, but note that only users with System administrator role can access these settings.

You can add as many priority classes as you need, add build configurations to them according to your needs and define the priority in the range -100..100. This setting is taken into account only when a build is added to the queue. The builds with higher priority will have more chances to appear at the top of the queue; however, you shouldn’t worry that the build with lower priority won’t ever run. If a build spent long enough in the queue, it won’t be outrun even by builds with higher priority.

Also note that by default you already have two predefined priority classes — Personal (priority=10) and Default(priority=0).
The first one is used for personal builds (Remote run or Pre-tested commit) only, i.e. any personal build added to the queue will be assigned to this priority class. The Default class simply includes all the builds not associated with any other class. This allows to create a class with priority lower than default and place some builds to the bottom of the queue.

We’ve had a lot of discussions about this feature, because there were many ways to implement it. We picked the one that seems the best, however we encourage you to try it and share your feedback with us. Try it!

The JetBrains TeamCity Team

In addition to the previous post about YouTrack, we would like to mention that since version 5.0 TeamCity supports YouTrack (1.0 and later), Jira (3.10 and later) and Bugzilla (3.0 and later) issue trackers out of the box.

The integration with an issue tracker can make your development environment even more convenient and transparent:

• TeamCity transforms all issue IDs mentioned in VCS commits, descriptions, or elsewhere into links to corresponding issues;
• You can review the issues mapped to a build on the dedicated tab of the build results page, or browse the issue log for the build configuration.

Note: Moreover, if you use YouTrack, you can configure TeamCity integration in it to get more bonuses. For example, if a comment submitted with a TeamCity change contains an issue ID, the issue can be automatically marked as fixed and the Fixed in build attribute is filled with a corresponding build number. Read more in docs.

The only setup you need to do is to establish the connection between TeamCity and the tracker. On the Administration | Server Configuration | Issue Tracker tab click Create new connection and specify the connection settings. That’s it!

By the way, if you use an issue tracker other than YouTrack, Jira and Bugzilla, you can still integrate TeamCity with it, but the steps are a bit different. For the instructions, please refer to the documentation. Plus, if you feel that existing integration is not enough for your needs, you can create custom integration plugin for any other issue tracker using Open API, or you can share with us your ideas about new features and improvements. Feedback is always welcome.

The JetBrains TeamCity Team