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!

Right in between Christmas and New Year’s eve we’ve got a shiny surprise for you – new EAP build. It’s going to be hard not to notice the changes in today’s TeamCity EAP build, because we’ve significantly changed user interface aiming to make it more friendly, logical, simple and clear. To begin with, we have redesigned the Administration page to provide faster and easier access to frequently used sections and simplify navigation by grouping settings.

Secondly, it is now very easy to see when a test failed for the first time: you can find this information right above expanded stacktrace:

We decided to get rid of Bulk mode and always show check boxes near test names instead.

In addition to mentioned changes, there are numerous usability improvements: the whole list you can find in the release notes.

However, changed look is not the only noteworthy thing here. In one of the previous EAP builds you could have noticed an experimental feature “Types for build properties”. Since then, it has been greatly improved and now it’s ready to use! The following types are now supported:

• simple text field with ability to validate its value using regular expression
• password field
• check box
• select control

Note, that if you want to use a typed parameter to introduce a password field in Run custom build dialog, values of password parameters will be hidden from build log and Build Parameters tab of the build, plus values of these parameters can’t be seen in custom build dialog and are stored in scrambled form in configuration files.

As usual, these are only the highlights and there are more to it, so we recommend to take a look at the release notes and give it a try!

Happy New Year and happy building!

Yet another bug-fix update is out – TeamCity 6.5.6. In this build we fixed issues related to Duplicates Finder (.NET) runner, once again improved general performance and addressed a couple of issues in TeamCity plugin for IntelliJ IDEA platform. You can find the complete list of changes in release notes.

Download the build and share your feedback with us.
Happy building!

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!

Over the last few weeks we have made a great deal of improvements in .NET inspections support. As a result .NET Inspections (powered by JetBrains ReSharper) and FxCop inspections runners produce much more clear results.

In case you missed, some time ago we announced new .NET inspections runner based on ReSharper inspections engine, and we already received feedback on it. Thanks to our EAP users we were able to fix a number of serious problems:
- LINQ usages are marked as unresolved symbols;
- TW-18724 NUnit attributes usages (and all External Annotations);
- TW-18730 Usages of resources in WPF, Silverlight projects.

Now the updated plug-in is available for download: follow the installation instructions and share your feedback with us.

As for FxCop runner, it now has a new setting – ‘FxCop version’.

It is really useful in case you have several FxCop versions installed in your build farm: selecting the version of FxCop to use in the runner settings will allow to keep the results consistent. If you’re not sure which FxCop versions you have installed, just go to Agents > Parameters Report page and use ’system.FxCopCmdFileVersion’ parameter name. You’ll get something like this.

Updated plug-in is available to download too.

Note that both plugins are compatible with the latest TeamCity 7.0 EAP and are not intended to work with earlier TeamCity versions.

Enjoy!

New bug-fix update is available – TeamCity 6.5.5. Several performance problems were addressed in this build, as well as quite old issue with symbolic links (TW-7938) and some other bugs: see the complete list of fixed issues.

Download the build and share your feedback with us.

Happy building!

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.

“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!

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!