JetBrains TeamCity Blog

TeamCity 8.0 is coming and we’re thrilled to present the next EAP to you! Working hard, we have added several new features and we continue to make improvements of the existing ones.

New make in IDEA Project runner

We integrated a new IntelliJ IDEA external make bringing all of the goodies provided by this tool into TeamCity:

• support for different languages like Groovy, Scala, Closure, etc.
• ability to build Android projects and artifacts, as well as all other types of artifacts supported by IntelliJ IDEA itself
• faster compilation thanks to the highly optimized IntelliJ IDEA make tool, plus the ability to build a project incrementally

Meta-Runner

All meta-runners are now stored on the project level. In other words, you can create a meta-runner which will be available in your project and its sub-projects only and won’t be visible outside. Also we have made several important fixes in the Meta-runner itself.

Other enhancements

There are other improvements including:

• human assignable identifiers for VCS roots;
• new icons in the web interface and IntelliJ plugin;
• and so on.

You are most welcome to try new EAP and tell us about your experience. You can find the full list of changes in the release notes.

Happy building!

This post describes one of the new features in the upcoming TeamCity 8.0

Using TeamCity, we can easily set up a build farm using a central TeamCity server and several connected build agents. By having multiple build agents, we can run builds and build configurations in parallel. Different branches of the same project can build simultaneously on different build agents,  personal builds can be run on one build agent while the nightly build is running on another agent and so on.

But what if we have multiple build agents and we want to constrain parallelism for some projects? What if we do want to have parallelism but want to provide different build variables to each build? Good questions, and the Shared Resources plugin is the answer!

The Shared Resources plugin comes bundled with TeamCity 8.0 EAP. In TeamCity 7.1.x it has to be installed separately. Sources for this plugin are available on GitHub.

Limiting concurrent builds with simple named resources

The Shared Resources plugin works at the project level. Per project, we can specify one or more shared resources which we can use to decide on the number of concurrent builds for a given project and build configuration.

In the Project Home under the Shared Resources tab, we can specify the resources we want to be able to lock. A shared resource should be given a name which can be used later on in our builds. The resource type can be infinite (effectively not limiting build concurrency), a resource with quota and a resource with custom values. Let’s go with resource with quota.

The resource quota is the number of concurrent read locks that can be acquired on the resource. Or in other words: the maximum number of concurrent builds we want to run. Let’s be restrictive and set the quota to 1.

None of the Build Configurations will obey these quota: we have to add a Shared Resources Build Feature to every Build Configuration we want to subject to these quota. This can be done in the Build Configuration. Under Build Features, we can add a Shared Resources build feature which acquires a read or write lock on the shared resource created earlier.

Once added, the build configuration will only be run on one build agent at a time. Personal builds as well as regular builds will all be enqueued and wait for the lock on the shared resource to be released, even if one of the build agents is idle.

Note that it is possible to await multiple locks in a build configuration.

Working with custom resource values

While working with simple named resources may be useful, it may be worth having a custom resource value for every lock acquired. Imagine we have a build which has a custom build step running load tests on a server. Wouldn’t it be nice if we could limit the number of concurrent build based on the number of load test targets available and be able to get the URL to one of these servers in our build? We can using a set of custom resource values.

When creating a new Shared Resource, we can specify the type as a resource with custom values:

In our build, we have several options available to acquire a lock on this shared resource. We can lock on any value that is not locked, we can lock on all values or on a specific value. For our purpose of needing a dedicated load testing machine, we can opt to lock on any available value.

Once added, we will not be able to run more builds concurrently than the number of available values in our custom shared resource. If we need the value of the locked value during our build, we can read it using the %teamcity.locks.<lockType>.<lockName>% variable, %teamcity.locks.readLock.RunTestsAgainstServer% in our case. For example when working with build parameters, we can use the lock value as a custom parameter:

Where can I manage shared resources?

So far we’ve seen that shared resources can be added for every project separately and used in that project’s build configurations. With TeamCity 8.0, we’ve introduced project groups which allows us to group several projects under a project group. Shared resources can be added to both the project group as well as the individual projects. Locks can be acquired for every build configuration in a project and/or project group, making it possible to have shared resources across projects as well.

Do let us know your thoughts via the comments below. Dive in, experiment and… happy building!

More than a month passed from last TeamCity EAP and we’re glad to disclose what have been done. Multiple improvements were made to the functionality we introduced in previous EAPs.

Project groups

We continue to integrate groups of projects into TeamCity. When new version is out we promise you won’t believe that there was no allusion to the groups in TeamCity just a few months before. Check an incomplete list of the places which are aware of sub-projects now:

• Project hierarchy is shown on Administration|Projects page;
• Projects hierarchy is shown in all drop downs where a list of projects or configurations is displayed;
• Notification rule defined for a project will be effective for sub-projects too;
• It is possible to define cleanup rules for projects. These cleanup rules are default ones for build configurations from this project and its sub-projects.

Get a full list of changes in release notes.

Meta-runner

Meta Runner is a powerful feature providing a promising new way for customizing TeamCity and making it even more people-oriented. To understand it, let’s consider an example.

Imagine you have some repeated task used over and over again across different build configurations. The task is defined as one or more build steps, based on built-in runners, like Ant or command line. Most likely you’d want to reuse this task easily across several build configurations. You can’t do this with templates because template enforces you to share the same settings across different configurations which is not always possible. A solution which we propose is to extract Meta-runner out of these steps, see how it works in release notes.

External IDs and projects transfer

External IDs will help to simplify import/export of projects and build configurations. We introduced them one EAP ago made some improvements from last time:

• it’s possible to define external ID for build configuration and template;
• external ID can be used in HTTP and REST requests;
• external IDs are stored in project configuration files, not internal ones.

Read more about external IDs in release notes.

Disk Usage Report

Disk Usage is now integrated with Server Health. New report, based on disk usage, show configurations with large build log files which are rarely useful because it’s difficult to analyze them. Read more on this report in release notes.

Queued Build page

Dependencies progress has been added and you can see estimates for all dependencies in one place now.

Please, try new EAP and tell us about your experience. You can find a full list of changes in release notes.

Happy building!

Hello everybody!

New TeamCity 8.0 EAP is waiting for you to try. This build contains several improvements and new features which make TeamCity an ultimate choice for large installations.

Project groups

When this major feature was introduced, there were only a few visible changes such as appearance of “root” project and a new storage scheme for project configuration files. This time we’ve made a big step forward and you can feel the power of this long-awaited functionality. You can create, move sub-projects, organize them into a hierarchy.

Parameters and VCS roots are inherited from parent projects so new configuration variants like definition of global parameter (TW-11202) are easily utilized. It’s also worth mentioning that shared resources plugin is aware of project groups too.

Disk Usage and Server Health pages

TeamCity takes care about all groups of its users, though server administrators, probably, got less attention before than developers or build engineers. This version is called upon to destroy current gap. Mixing authorization mode and improvements in cleanup appeared earlier, now it’s time for server health and disk usage reports. They help you identify many server-related problems faster, including issues with databases, disk, VSC and configuration files.

VCS worker (experimental)

TeamCity is a very popular tool for building projects with large source code base which may require hours to checkout. This process could slow down server responsiveness and decrease server reliability due to VCS-specific problems. To resolve these issues, we’ve moved functions responsible for communication with code source repositories to a separate service – VCS worker. The workers give you a lot of flexibility in routing VCS requests and discovering CPU or memory issues related to VCS operations.
This feature is experimental and turned off by default. We’ll be glad to hear your feedback on it. Please, read release notes if you want to know more.

.NET Inspections

After .NET code analysis was introduced more than a year ago, we constantly improved it, making it more precise and useful. New full MSBuild model support removes a bunch of bugs causing wrong errors detections in code which was checked successfully by ReSharper and is absolutely clean.

Support of Mercurial sub-repositories

Sub-repositories in Mercurial is rather popular feature so DVCS support in TeamCity wouldn’t be full without it. From this EAP, TeamCity can retrieve changes from sub-repositories (including embedded ones) and shows them with other code changes.

Other features

• investigation and muting of build problems ,
• better shared resources,
• new queued builds page,
• ability to remove build
• and more.

Please, try new EAP and tell us about your experience. You can find a full list of changes in release notes.

Happy building!

Hello everyone! Today we’re opening EAP for TeamCity 8.0 (code name Gaya) in order to give you some fresh stuff, to play with during weekend.

Let me briefly describe what we’ve done already and share some of our plans for TeamCity 8.0 (we expect it to be released in Spring 2013).

The major feature of TeamCity 8.0 is sub projects, or project groups (see TW-705, yes, a rather old and rather popular request). We hope it will make TeamCity more scalable in terms of information presentation and the notion of project in TeamCity will become a better match to a real life project (what we call a project right now is rather a VCS branch). While moving in this direction in this EAP we’ve changed how project configuration files are stored on the disk and introduced “root project” (a parent for all of the projects in the system), read more.

Another important feature which we’d like to address in 8.0 is import/export of projects and build configurations (TW-4124). It can become really handy for those who have to maintain several TeamCity instances. At first we plan to provide editable IDs for a project, build configuration, template and VCS root. This will allow assigning IDs on one server so that they do not intersect with IDs on another one, thus will simplify moving configuration files among servers. In this EAP we’ve made the first step in this direction — editable project IDs.

We’ve heard complaints from our customers about the cleanup process. Highly loaded TeamCity server can produce thousands of builds and gigabytes of data each day. Not all of this data will be used in the future, and there is an ability to configure cleanup rules to remove garbage from disks and from the database. Unfortunately, not only this operation takes significant time but web interface becomes inaccessible while the cleanup is in progress. In this EAP we’ve made several improvements in this area, read more and let us know how it works for you.

Mixed mode authentication is the last important addition in the first TeamCity 8.0 EAP. It simplifies migration from one authentication scheme to another by allowing usage of more than one authentication module at a time, read more.

There is also a couple of IDE integration features (currently only available in IntelliJ IDEA plugin). These are: already mentioned some time ago remote debug on agent and showing of test status (success, fail, muted, investigated) right in the editor, plus some other smaller improvements.

Please see release notes for complete list of changes.
Download EAP build, and share your feedback with us.

Happy building!

Hi everyone!
We’re already counting the days till the final TeamCity 7.1 release, and today we have a fresh new EAP build for you which is basically what the release build is going to be like, except we still need to polish a few things. So we encourage you to try it, and help us improve it!

Check out the release notes, which is all about bug-fixes now, try the build out and send us some feedback!

Stay tuned, we’re almost there!

Today’s EAP build is all about significant improvements in Feature Branches support. Since the release date approaches, we’re focusing on polishing already introduced features and fixing known issues. Here’s what we have for you this time:

• Extended branches specification syntax: When you describe branch specification, you now have more control on what will be shown as a branch label in TeamCity UI. For instance, type something like this:
  +:refs/heads/release-(7.0)
+:refs/heads/release-(7.1)
  TeamCity will use label 7.0 for builds from refs/heads/release-7.0 branch and 7.1 for builds from refs/heads/release-7.1.
• Branch labels for builds from default branch: Now builds from default branch also get labels.
• Branch selector on overview and project page: We’ve added an ability to switch between branches to both Overview and Project pages.
  
• Branches tab in build configuration: Want to see an overview of what is going on in each active branch? There is a new build configuration tab to answer exactly this question:
  
• VCS branch parameter: For Git & Mercurial TeamCity provides additional build parameters with names of VCS branch used by the build on the moment of starting.

See the complete release notes, back up your TeamCity instance, try the build and share your feedback with us!

Stay tuned!

Hi everyone!
Today we have a new TeamCity EAP build for you, and right now there are just a few weeks left till the official release, so this build is basically almost “the one”, except that “the one” will be more polished. So if you’re eager to be the first one to put your hands on TeamCity 7.1, this build is just for you. Let’s see what’s in it!

Feature Branches

If you have been following our EAP program, you probably noticed some sprouts of this feature, but now it has grown and expanded and you can already harvest lots of goodies out of it!
First of all, now you can configure what branches you want to monitor in a build configurations right in the VCS root (Git and Mercurial only), just use syntax similar to checkout rules:

Use * to list the branches. For example, +:refs/heads/* will match refs/heads/feature1 branch, and in TeamCity interface you’ll see feature1 only as a branch name.
Once you’ve specified the branches, TeamCity will start to monitor them for changes, and if you have VCS trigger and a change is found in some branch, TeamCity will trigger a build in this branch.
You’ll also be able to filter history, change log, pending changes and issue log by branch name. Also branch names will appear in custom build dialog, so you’ll be able to manually trigger a custom build on a branch too.
But that is just a tip of an iceberg! There’s more to it! This feature affects many aspects of TeamCity behavior: for the details please refer to the release notes.

Other Improvements

Unified look for Change Log, Pending and build Changes pages

We have reworked Pending and build Changes views to look similar to Changelog, for instance, you’ll find graph of commits on the build Changes page as well. You can also notice a new option “Show files” which allows to easily expand all changes on the current page and show affected files.

Manually changing build status

Sometimes you may need to mark a failed build as successful, for example, if a failure happened because of a minor problem, and you want other builds to take artifacts of this build, or your want to promote this build further by pipeline. On the other hand, there are cases when TeamCity was not able to determine build failure. For example, build finished successfully but because of an error in build script it did not produce any artifacts. So the build clearly cannot be treated as successful. Now you can change the build status manually, provided you have enough permissions to do that.

Build Steps Execution

Build step execution policies introduced in the previous EAP have been improved. We’ve added “Always, even if build stop command was issued” option to “Execute step if” drop-down which can be useful for some cleanup tasks. Note that as in previous TeamCity version whether the step is failed or not in most of the cases is determined by process exit code.

NuGet Support Improvements

• We added support of NuGet 1.8/2.0. Now you may even upload your own NuGet.CommandLine package instead of downloading it from the public feed.
• NuGet Trigger now supports Prerelease packages.
• We improved NuGet Installer runner. It no longer requires you to have packages/repository.config file under solution. Starting from this release, NuGet Installer uses Visual Studio solution file (.sln) to create the full list of NuGet packages to install. It also supports Solution-Wide packages, from .NuGet/packages.config file. We added an option on how packages upgrade is done. Now you may select to update packages for entire solution of per packages.config files.

See the complete release notes, back up your TeamCity instance, try the build and share your feedback with us!

Stay tuned!

New TeamCity EAP build (#23373) is available today. Be the first one to try it! Here’s what we’ve got for you this time:

• NTLM HTTP authentication support: You’ve waited for this feature quite a while, and now the related issue (TW-6885) is finally closed!
• Changes from artifact dependencies: Changes in artifact dependencies are now reported in the way similar to VCS changes.
  
• Branches improvements: Not only TeamCity displays branches names now, but you can also filter shown builds, changes and issues by specific branch.
• Support for Amazon EC2 EBS instances: New EC2 instance types are now supported, plus it is now possible to specify the Amazon Instance ID instead of Image ID to make TeamCity start/stop the instance as if it was an image.
• More flexible build steps configuration: Previously, if your build consisted of several steps, TeamCity would stop executing build steps if a non-zero exit code was returned from the previous step. Now you can change this behavior, and tell TeamCity to continue executing build steps anyway.
• Support for .rvmrc in “Ruby environment configurator” build feature: Ruby Environment Configurator build feature is now able to configure environment for the subsequent build steps from the .rvmrc file. (See TW-14493)
• Checkout on label in Perforce integration: In Perforce VCS root settings you can now specify label to be used to checkout sources. If you change it for the VCS root, the next build with changed label will show the changes since previously labeled build.

See the complete release notes, back up your TeamCity instance, try the build and share your feedback with us!

Enjoy!

The release of TeamCity 7.1 is so far planned for mid-June, and today we launch the early access program, so don’t sit on your hands – grab the first EAP build while it’s hot! Today’s menu includes:

Current problems: now on Overview page

If you need to monitor problems in many build configurations, you can now get the whole picture right on the overview page without having to expand each and every build configuration in question:

Sticky investigations

Normally an investigation assigned for a build configuration or a test is automatically cleared once the build configuration becomes green or the test passes. What if it’s a “flickering” test: green-red-green-red… and so on? Still has to be investigated! To allow better management of such problems we introduced manual mode for investigation resolving. When you assign an investigation you can select how you want it to be resolved: automatically, or manually:

Version Control Repository browser

In several places in build step settings, where a path to a build script can be specified, a small icon appeared: . By clicking on this icon you’ll be presented with a VCS repository browser allowing you to choose a file in repository.

And more!

• Own investigation highlighting
• Branch names are shown for builds triggered by Remote Run on branch trigger
• Fixed clean checkout issue for builds from branches
• IntelliJ IDEA plugin improvements
• Brand new service implementation for TeamCity server (be careful, there can be bugs)

Find the details in the complete release notes, try the build and share your feedback with us!
Enjoy!