If you have tens of agents shared between several projects you probably suffer from the following issues:
To solve some of these issues you could assign agents and build configurations one to one, but this would be a tedious and absolutely not scalable approach due to low granularity level.
TeamCity 7.0 addresses these problems in a more convenient way. You can distribute your agents among several agent pools and assign each project to a pool. A project can be assigned to more than one agent pool, but agent can reside in a single pool only. If a project is assigned to a pool, its builds can run on agents of this pool only. They won't affect other pools and other projects. There is also a so-called Default pool, that cannot be removed and serves as a place for all agents and projects not assigned directly to other pools.
Ability to perform one-to-one assignment between agents and build configurations is still there and provides a fine grained control within a pool.
When defining a build parameter either on build configuration or project level, you can specify a type of a control for this parameter. For example, if a parameter has two values - true or false, it is natural to show it as checkbox. Currently this only affects custom build dialog.
Besides control type, you can also specify some standard properties for each parameter, such as:
Supported control types are:
If password parameter is used, TeamCity will do its best to hide the actual value of password parameter. You won't see the password in build logs, TeamCity web interface, or IDE plugins. It will be stored in configuration files in scrambled form. Note that as TeamCity performs global replacement of the password in build log, you have to choose relatively strong passwords - those that are unlikely to appear in the build log as a sequence of characters.
Parameter specification (a part of parameter which defines how to show it) cannot be overwritten if a parameter is inherited from a template or project.
Build chains (a collection of builds combined by snapshot dependency) is a TeamCity approach to setting up something similar to a pipeline.
Some important notes:
Given the complexity of build chains, it is not easy to represent them visually. But we decided to make a first step in this direction in TeamCity 7.0.
For each build chain you can see all builds that constitute a build chain as well as their status: not triggered, in queue, running or finished. Clicking a build in a chain will highlight this build and all its direct dependencies (both upstream and downstream). Since there can be several build chain in a single project, there is an ability to filter them.
But this page not just visualizes the chain, but also provides some abilities you can't easily reproduce using earlier versions of TeamCity. For example, the following chain is in not triggered state:
This means some of the builds were not started yet. By pressing the "Run" button you can continue the chain, i.e a new build will be started on the chain revisions and associated with builds from this chain.
Besides build chains presentation we've made some other important improvements.
For a build configuration with snapshot dependencies you can enable showing of changes from these dependencies transitively. The setting is available on the "Version Control Settings" step of the build configuration administration pages:
With this setting enabled, "Schedule Trigger" with a "Trigger build only if there are pending changes" option will consider changes from dependencies too.
Finish build trigger has become a little bit smarter too. If a build configuration is set up with a "Finish build trigger" and has snapshot dependencies to selected build configuration, the trigger will run the build on the same revisions and will attach the build to the chain. Thus you can have automated promotion of builds in a chain.
Newly added build configuration editing step called "Build Failure Conditions" accumulates all settings that define when the build should be marked as failed. Standard options like "fail build if at least one test failed" were moved from the "General Settings" step to this page.
Besides the standard options, you can find two new build failure conditions:
With the help of this build failure condition you can track whether a specific statistical value changes within certain limits, and if it exceeds these limits, a build will be marked as failed. For example, you can require that the size of artifacts in your build is never less than 1Mb. Or that line coverage is always more than 80%.
There are cases when a build must be marked as failed if some statistical value differs significantly from a previous build (or from some reference build). For example, you may want to fail a build if the number of covered lines drops significantly compared to the previous build. Or, if compared to a build marked with some tag (reference build), the number of duplicate code fragments increased by more than a specified threshold. This is all possible with "fail build on metric change" condition.
The name of this failure condition speaks for itself. If text in the build log matches some regular expression, a build will be marked as failed. You can also define a failure message that will be shown in build status text and in the build log.
Maven, Gradle and IntelliJ IDEA Project build runners now support incremental building (for IDEA it's limited to running tests). Say, your project has these modules: A-prod, A-test, B-prod, B-test.
Now if a build starts with a change in module A-prod, TeamCity agent will run the tests in both modules (because B-test depends on A-prod and can be affected by the change).
In general, the more independent your modules are, the better. Modularity is a common good practice of software design, and now you can get another benefit from such approach: faster builds.
To enable this functionality for Gradle or IntelliJ IDEA project runners, simply turn on "Run affected tests only (dependency based)" checkbox. For Maven, you should enable "Build only modules affected by changes" checkbox.
Note that since IntelliJ IDEA project runner operates with run configurations instead of individual tests, when the "Run affected tests only (dependency based)" checkbox is enabled the runner will execute run configurations depending on affected modules only.
A long-standing feature request to allow build configuration editing via REST has finally been implemented.
Here is an example of how to get build configuration steps:
Save individual step details to a file:
And create a new step (a copy of the saved one):
REST API has had "/app/rest/application.wadl" since the very beginning, but it has now got an XML schema attached (see <ns2:grammars><ns2:include href="application.wadl/xsd1.xsd"> element and try application.wadl/xsd1.xsd request) and will hopefully get some more inline comments soon.
If you are already using the REST API please note that the protocol version has changed.
Additionally with TeamCity 7.0 REST API you can:
New Inspections runner for .NET is now available. Internally this runner uses parts of JetBrains ReSharper, so basically it means that ReSharper Code Analysis is now available on the server side too.
Key benefit of .NET Inspections runner is that it can use ReSharper 6.1 settings profiles. So you can easily tune the runner to match your own code style.
Inspection results are shown in the standard TeamCity interface.
Also, links to on-line inspections wiki are available for some inspection types.
Which should help you learn how the code can be improved.
We still have a few unresolved technical problems which could lead to incorrect inspection results. All these issues will be targeted in the future releases. Among them:
NuGet is a relatively new tool in .NET world. In brief, it aims at solving dependency management issues experienced by many .NET projects. You can read more about NuGet on NuGet.org.
TeamCity offers several NuGet-related features:
If you publish NuGet packages as TeamCity artifacts you can enable NuGet Server feature on Administration -> NuGet Settings page.
In this case TeamCity will provide its own NuGet feed with all published packages. You can use this feed in Visual Studio to get notifications when packages are updated on the server.
Maven settings files often contain shared settings for all Maven-based projects within a company. Until TeamCity 7.0 it was hard to define them in TeamCity as you had to store these settings in version control (or on a network share), and remember to use command line options to specify a path to them. Now you can upload your settings files to TeamCity:
And then use them in Maven-specific build steps:
Maven 3 is now bundled with TeamCity in addition to Maven 2. You can select which Maven version to use in Maven build step.
TeamCity 7.0 is compatible with Subversion 1.7:
Since IntelliJ IDEA does not yet support SVN 1.7, TeamCity plugin for IntelliJ IDEA also won't work with 1.7.
Several user interface improvements have been made in TeamCity 7.0.
Project and build configuration change log now shows branch graphs for distributed version control systems like Git or Mercurial.
There will be as many graphs as the number of VCS roots you have in your project or build configuration. When clicking a node in the graph, corresponding part of the change log is highlighted.
Also in places where information about committer is shown, TeamCity will try to show the TeamCity user name instead of the version control user name.
We restructured the TeamCity administration area to make it more logical, scalable and to bring some often used pages up front.
Note that for each failed test on this page you can get a bunch of information instantly, without a need to leave the page. For example, you can see all build configurations in which this test is currently failing. You can also see a current stacktrace and information about a build where the test is currently failing. You can also see information about the first failure of this test, again with stacktrace and build.
Similar improvements were also applied to project's "Current Problems", "Investigations", and "My Changes" pages.
You can filter build log by message priority, expand all nodes in the whole build log, or within a single node only. Tree view is now available for running builds as well (it was not so before TeamCity 7.0).
Browsing inside artifact archives from within the TeamCity UI has become extremely easy. Supported archive types are: .zip, .jar, .war, .ear, .tar, .tar.gz, .apk, .sit. Browsing archives inside archives is supported too.
If you want to download a file from an archive in a build script, use this URL syntax:
See more on this in our documentation
Here you can see that build produced zero CPU and Disk usage during a period of several minutes, starting at 15:00. Most likely there was some code spending a lot of time in wait state. By clicking a point in the chart, a part of build log for this period of time will be shown.
Performance monitor spawns a separate process which gathers hardware statistics. Statistics is gathered for the whole agent machine, so it won't work properly if you have more than one agent installed on the same machine and these agents run builds in parallel. CPU, Disk and Memory usage are all percentages of what is available on the agent. Sometimes you can see that only 50% of CPU is being used by a build. This usually means that a build does not utilize all CPU cores of the agent machine. Platforms supported by PerfMon are Windows, Solaris, Linux and MacOS X.
VCS trigger now supports two new options:
With the first option enabled, each new check-in will result in a build added to the queue and associated with this check-in (i.e. build won't include other changes).
If the second option is enabled, and there are several pending changes, TeamCity will group them by user and will start builds having single user changes only.
Option to run a build with clean sources was added to custom build dialog and to "Schedule Trigger".
Global, per-server build execution timeout can be defined for all of the builds. If build configuration level timeout is specified, it will override the global setting.
Diagnostics page now shows current memory usage and JVM arguments. In case of memory issues (high memory usage for a prolonged period of time), a warning will be shown in TeamCity web interface. If you customized some TeamCity internal properties, you can see them on Diagnostics page too.
Artifact dependencies now support syntax similar to checkout rules, i.e. you can define a set of new line delimited rules:
Settings like build triggers, build steps, build features and build failure conditions can be disabled in build configuration or template. Disabled settings will stay inactive until they are enabled again. If you disable a build step, this build step will not be executed on the agent. Inherited settings can be disabled too, for example, if a build step is inherited from a template, you can disable it in the build configuration and define some other step instead of inherited one.
Plugin providing information about agent hardware was available for quite some time (see http://youtrack.jetbrains.net/issue/TW-4857). We decided that it is useful enough to bundle it with TeamCity distribution.
Ant-like file patterns can be specified for artifacts cleanup rules, in the form:
VCS username, default for all of the types of version controls, can be specified on user profile.
To see personal builds of other users enable "Show all personal builds" setting on your profile.
First of all, the long standing bug with non-functional Ruby environment configurator (http://youtrack.jetbrains.net/issue/TW-14803) has now been fixed.
Also, agents now detect the presence of RVM and report rvm_path environment variable with the path to RVM. This way you can easily set up your build configurations to run on agents where RVM is installed. Enabling of Ruby environment configurator will add this requirement automatically.
Skip to end of metadata Go to start of metadata