JetBrains TeamCity Blog

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.

In the upcoming TeamCity 5.1 we’ve added an often requested feature – artifact packaging.

As you probably already know, in TeamCity you can easily configure artifact upload to the server. Later, from a build page, you can download all artifacts of the build. You can specify both directories and individual files as artifacts. The syntax for this is rather simple.

Build artifacts enable another really popular feature – custom reports. The essence of the feature is that if your build produces a report, viewable in a browser (any HTML/Text/Image/PDF), you can integrate this build report into the TeamCity interface. Report files are sent to TeamCity as artifacts, and you configure the report view in the TeamCity UI. One of the interesting things about custom reporting is that TeamCity can extract individual report files from ZIP-packaged archives. So if your report is a big directory with hundreds of files, you better zip them first before sending (to speedup the upload process).

Before TeamCity 5.1, you needed to zip the files in your build script. This required writing an Ant or NAnt task which prepared corresponding archive file. Unfortunately, not all build runners allow creating zip files.

In TeamCity 5.1, artifacts can be packed without modification of your build scripts. Just use archive suffix in your target path, and that’s it:

  testng-report => testng.zip
  **/src/**/*.java => sources/all-java-files.tgz

You can use suffixes zip, jar, war, tgz, tar.gz to specify type of the archive. For jar and war archives, the file format is just zip.

And as you would have expected, if you use tar/gz packaging on a UNIX system, TeamCity preserves file mode of the files, username, and group.

You can try artifact packaging in the just opened TeamCity 5.1 EAP builds.

Hope you’ll like these bits of syntax-sugar, and please share your feedback!

In fact, this feature existed since TeamCity 1.0, though it isn’t much publicized.

Yes, we admit that we are lazy developers, and we don’t like to restart the programs after editing their configuration files. That’s why IntelliJ IDEA monitors the changes on the disk and reloads files automatically after an external change takes place. And the same is true about TeamCity: it monitors the state of the configuration files and picks up the changes if the files were modified.

FYI: TeamCity server uses XML-based configuration files to store information about system-wide settings, such as authentication scheme, version control roots, third-party reports configuration, etc. The information about configured projects and various build settings is also stored in XML files.

To be more specific:

• After any changes in TeamCity server configuration files, such as main-config.xml, project-config.xml or any *-config.xml, TeamCity reloads the server configuration (it monitors file modification timestamp). The important consequence – when you save these files, they should be in the valid and parseable state. If you are brave enough to manually edit these files, be careful not to break them.
• If you modify the build agent’s buildAgent.properties file, there is no need to restart the build agent. The build agent will wait until currently running build finishes and will restart and reload its configuration automatically.

This is not a killer feature, of course, but it is interesting enough to deserve a separate blog post.

Happy building,

KIR

Technorati tags: TeamCity, JetBrains, Java, .NET, IntelliJ IDEA, continuous integration, build management, agile development

Hello,

We are glad to announce the first EAP build of TeamCity 3.0 (codename Benares). It has significant number of new features as well as fixes, usability and performance improvements. It is pretty stable – we run TeamCity EAP as an internal JetBrains build server which serves dozens of projects of various types (.NET, Java) in multiplatform environment (MacOS, Windows, Linux).

Most noticeable features of this build include:

• Per build configuration, shareable VCS Roots
• Visual Studio pre-tested commit support for Subversion
• StarTeam support
• Build queue now features estimated build start and finish times
• Possibility to assign agent to specific build configurations
• Detection of hanged builds
• Multiple UI improvements

and other issues.

We have much more plans, with primary focus on statistics and per-project access rights. Stay tuned with Benares early access program.

Download TeamCity Benares EAP build

Kind regards,

—JetBrains TeamCity team

TeamCity, JetBrains, continuous integration, build management

Hello everyone,

It is the time to reveal some plans regarding the next version of TeamCity.

First of all, as long as code-names for TeamCity are city names, we’ve chosen Benares name for this version.

Benares will be released this year, and more specific dates are not settled yet. The most optimistic date for the release is November, 1

After a lot of disputes with development team, marketing and our customers (mostly represented by Jira votes) we’ve prepared a first version of roadmap for the Benares.

One of the key ideas for TeamCity future is to go beyond continuous integration and build management. Partially, we are doing this already and TeamCity currently offers:

• a set of tools for improving code quality (using powerful server-side code inspections and duplicates finder from the best Java IDE around)
• tight integration with various IDEs and possibility to navigate from Web UI to the source code
• web-based access to user changes, including diff
• time-saving team communication regarding failed builds

But we have more plans.

• Managers (and not only managers) like statistics and nice charts. What are the project coverage trends? How build duration changes? Shall we use more build agent machines to reduce waiting period for builds in queue?
• We’re going to provide code inspections and duplicates finder for Eclipse projects and for Maven projects
• Add possibility to view list of changes for selected users, calculate commit statistics, browse project source tree
• Many our users ask for delayed commit functionality in Visual Studio with Subversion repository
• We plan to implement per-project access rights

From the other hand, we aspire at providing best on the market continuous integration and build management solution. It is not easy to find new features in this area, but we believe it’s worth trying:

• Multiple VCS configurations within single project with possibility to include/hide particular directories in the source tree (cloaking)
• Composed builds with parallel execution on different OS platforms. Final build status will depend on composite status of the builds.
• Possibility to take a thread dump from the build agent right from the Web interface when tests hang.
• Support for blinking tests. Do you know those annoying tests which fail, well, sometimes?
• Edit build agent properties remotely, via Web UI
• Advanced build promotion action with possibility to publish it to external location, pin, tag, prepare changelog, and execute arbitrary script
• Starteam VCS support
• more

Surely, these are just plans. And this is just the tip of the iceberg. But we will try hard to implement most of the features. Despite of the vacation season .

Work is in progress. We invite you to participate in the discussion of the features and to vote for stuff most interesting for you. Here are some resources for that:

• Benares RoadMap in the TeamCity EAP wiki
• TeamCity support forum

With kind regards

—JetBrains TeamCity team

TeamCity, JetBrains, continuous integration, build management

The 2.0 release of TeamCity was packed with features. But appetite comes with eating, and the more features we offer to our users the more requests for improvements and enhancements we get with every new release. Well, at least this keeps us going in the right direction

The 2.1 version of TeamCity we release today lists a fair number of various improvements to existing features, plus several new features you might enjoy:

• More stable and complete integration with Subversion and ClearCase
• Ipr, Inspection and Duplicates finder runners related fixes
• Ivy-related improvements, including password repository protection
• Viewing existing artifact dependencies for a given build on the build results page
• Possibility to select a specific agent to run a build on
• Enforce clean checkout for a project on all build agents (to clean all the incorrect data)

- to name just the most noteworthy ones.

Download TeamCity 2.1 at http://www.jetbrains.com/teamcity/download/ and let us know what you think in our forum. You may also see TeamCity in action on our public site.

Good luck with your builds,

—JetBrains Team

TeamCity, JetBrains, continuous integration, build management, Subversion, TFS, ClearCase

Hello everyone,

We are going to release a minor update to TeamCity 2.0 in May, which will include several new features and a critical bugfixes. So today the first EAP build for this version of TeamCity is published.

My favorite feature in this EAP is “Run on agent”, when you can schedule a build on the specific agent:

You can read release notes for this build, view Jira changelog and download the software.

You’re welcome to participate in our EAP program to provide feedback on its features, and you can get help working with TeamCity in our discussion forum.

With kind regards,

Kirill Maximov

Technorati: TeamCity, JetBrains, eap, continuous integration, Subversion