Faradi 7.0 EAP (build 20334) Release Notes

Skip to end of metadata
Go to start of metadata

New agent pools administration interface

We reworked agent pools administration interface, and we would appreciate any feedback on it.

.NET Inspections runner (based on R#)

New .NET Inspections runner based on ReSharper inspections engine is now available. .NET duplicates runner has got major update too.

.NET Inspections runner results:

Inspections runner configuration screen:

New duplicates runner configuration screen:

Global Maven settings

Now it is possible to define global (per server) settings xml files, and use them in your Maven builds.

Global settings xml files can be uploaded via TeamCity administration interface:

The files are stored under <TeamCity Data Directory>/config/_mavenSettings directory. If necessary, the files can be edited right there.

Then in each Maven build step you can specify which settings xml to use: default (chosen by Maven), specified by path or global (uploaded on server).

Fail build on a specific text in build log

Build failure condition to fail build on a specific text in build log has been improved. You can read more about it in this blog post.

Per-check-in builds

VCS trigger now supports two new options:

  • Trigger one build per each checkin
  • Trigger one build per group of checkins from the same user

With the first option enabled, each new check-in will result in a build added to queue and associated with this check-in (i.e. build won't include other changes).

If 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.

Graph of commits on the build configuration changelog page

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 VCSes, they make it easier to understand where a VCS root modification comes from.

Reworked snapshot dependencies graph

Build dependencies tab has been reworked to show complete build chain formed by snapshot dependencies. The same view is also available on change details page.

Types for build properties (experimental)

Disclaimer: This feature is experimental and will be changed in the future releases. No data conversions will occur and you will need to re-enter all property descriptions again.

With this build property definitions of a build configurations get an additional "Spec" attribute.
This property "meta" information is then used to display the property in the "Run custom build" dialog.
It can be used to:

  • specify property presentation (checkbox, drop-down, validation for valid integer value)
  • specify display text to use instead of property name
  • mark property as mandatory (user needs to specify it's value before running a build)
  • mark property as hidden (the property will not appear in cutom run dialog)

These settings are configred via a specially-formatted string described in the comment of the original issue.

Some examples are:

text label='My pretty and important name' required='true'
text hidden='true'
integer label='Number of retries' minValue='0' maxValue='10'
enum items='red;green;blue'
enum label='JVM Memory' items='small;medium;large' data_small='-Xmx100m' data_medium='-Xmx300m' data_large='-Xmx1000m'

Filtering messages in build log tree view

We continue improving tree view in build log, and with this EAP we added filter by message status, and also improved tree view presentation.

Other improvements

  • global, per-server build execution timeout, can be overridden on build configuration level
  • Performance Monitor is now a build feature and is not enabled by default (you'll need to add it explicitly), also it now supports MacOS X
  • NuGet integration improved
  • On My Changes page and on the page for an individual Change, you can see an estimate for queued builds associated with the change (see Builds tab)
  • full list of fixed issues
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Nov 10, 2011

    When trying out the awesome new Types for build properties feature with an enum (i.e. list) spec, I ran into a small issue that took me a couple minutes to figure out.

    If you are using an enum list without data values, such as:

    you can simply enter an enum value (such as green) as the default value in the  "Value" text field of the Add New Parameter dialog.

    However, when using an enum list that has data values, such as:

    for the default property value, entered in the "Value" text field of the Add New Parameter dialog, you need to enter the default data value (such as -Xmx100m) and not the default enum item (such as small). When you open the custom build dialog, the drop shows the enum items (as expected) and defaults to the one that corresponds to the default data value.

    Once you think about it, this makes sense since the value you are specifying is the value of parameter, which is ultimately the data value in the second case, and is the enum value in the first case. But initially I was thinking of the default value text field as the value of the item in the enum list. Not the property's data value.

    I just wanted to mention this in case anyone else bumps in this.