Child pages
  • Faradi 7.0 EAP (build 20184) Release Notes
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 25 Next »

Agent pools

Agent pools provide a way to break a single, common set of agents on separate parts - pools. Each pool has agents and projects assigned. Agent belongs to one agent pool only, but projects can be assigned to several pools.
Builds of a project assigned to a pool can run on the agents from this pool only. There is a special pool called Default, it contains all of the newly authorized agents.

With help of agent pools you can distribute agents among projects, and be sure other projects will not use you project agents. Also with agent pools it is easier to calculate required agents capacity.

Build failure conditions

"Fail build if" settings of build configuration were moved to a separate step. Also there were two useful additions:

  • ability to fail a build on a metric change (read more)
  • fail a build if a specific message (matching some regexp) is logged in the build log

Dependency based test run

Maven, Gradle and IntelliJ IDEA Project build runners now support dependency based run of tests. For example, say your project has these modules: A-prod, A-test, B-prod, B-test.
Modules with -prod suffix contain production code, while modules with -test suffix contain tests for corresponding production modules. Module B-prod depends on module A-prod and module A-test depends on module A-prod.
Module B-test depends on module B-prod and A-prod.

Now if a build starts with a change in module A-prod TeamCity agent will run tests in both modules A-test and B-test (because B-test depends on A-prod and can be affected by the change).
However, if a change was made in B-prod only, TeamCity will only run tests from B-test module.

So, in general, the more independent your modules - the better. It's a recommended way to design a software, but now you can get one more benefit from such approach: faster builds.

To enable this functionality for Gradle or IntelliJ IDEA project runners turn on "Run affected tests only (dependency based)" checkbox.
In case of Maven, some additional settings are available: TODO.

NuGet support

This EAP build of TeamCity comes with bundled NuGet Support plugin. We already announced availability of this plugin in a series of blog posts:

The plugin is also compatible with TeamCity 6.5, so if you want to use it in your existing production server, you can download it from teamcity.jetbrains.com.

Build performance monitor (experimental)

Each new build now has additional tab, called PerfMon. On this tab you can see CPU/Disk and Memory usages on the agent during the build. You can also click on a point in the chart and corresponding part of the build log will be shown.

For example, from the picture below it is clear that at some point CPU and Disk usage is very low. This lasts for about 20 minutes. Seems like the tests executing at this time need some investigation, probably, most of the time they are blocked on some lock or wait for some event:

Performance monitor supports Windows, Linux and Solaris operating systems.

Build log

Collapse all and expand all links added on tree view in the build log. Additionally tree view now works for running builds too.

Artifact dependencies

Artifact dependencies now support syntax similar to checkout rules, i.e. you can define a set of new line delimited rules:
[+:|-:]SourcePath[!ArchivePath][=>DestinationPath]

My Changes page

  • multi-line commit messages are collapsed
  • builds carpet is more "vertical"
  • you can view all related builds, not only suspicious

Other improvements

  • multi-line text fields for build steps command line parameters
  • new icons for build statuses
  • new projects are not added on the overview automatically (yellow warning is shown instead)
  • investigations and muted tests pages improved
  • fixed issues
  • No labels