Child pages
  • Benares EAP (build 5813) Release Notes
Skip to end of metadata
Go to start of metadata

Per-project Roles Enhancements

This release introduces further improvements to the per-project roles first available in the previous EAP release.
Most notable changes include:

  • Elimination of "All Projects Developer", "All Projects Viewer" and "All Projects Administrator" roles. These are superseded with ability to assign any role to "All Projects".
  • Ability to assign a role in multiple projects with single "Assign roles" action;
  • Ability to assign roles in multiple projects to multiple users;
  • Ability to unassign multiple roles with single action
  • Ability for a user with "Project Administrator" role to assign roles within administered projects
  • Ability to set permissions for "Guest" user and newly created users (including self-registered): available via corresponding actions on User Accounts page

Custom Statistics

Builds can now publish values through teamcity-info.xml file and charts for the values can then be displayed on the Statistics tab of the build configuration.
Basically, what is needed is to generate teamcity-info.xml file during the build, like this one:

And specify how to show the graph in the main-config.xml:

Detailed description can be found in the corresponding section of our online documentation.

Reworked Build Results Page

In our effort to provide the best user experience we have started reworking layout of some pages. This release introduces the new build results page header appearance:

We are open to feedback and appreciate if you can share your opinion with us!

More in VCS Labeling

In addition to CVS and Perforce, VCS Labeling is now supported for Subversion, StarTeam and ClearCase. In addition to automatic labeling, you can now label sources used for a build at a later time: via "Label this build sources" action available in "VCS revisions and labels" section of the build results.

Authorized Status for Agents

In order to provide more control over agents included into the build grid, new status is introduced for the build agents: authorized/unauthorized. Unauthorized agents are listed in a separate tab under "Agents", agents can be authorized by users with "System Administrator" role.
Please note that all newly connected agents are Unauthorized by default.

Agent status round up now looks as follows:

  • Authorized or Unauthorized. Agent should be authorized to be allowed to run the builds. This prevents "alien" agents from getting sources and allows System Administrators to control what agents are included into the build grid.
  • Enabled or Disabled. Server can automatically assign a new build to compatible enabled agent. However, builds can be manually assigned to disabled agents. This is particularly useful for "debugging" specific agents or preventing build running on the agent temporarily.
  • Connected or Disconnected. Connected state designates running agent software.

Other

  • Improved "Builds with my changes" notifications: no notification when build was already broken on the time you committed and you did not fail any more changes; eliminating notifications on newly failed tests after your commit (turned on by "Ignore failures not caused by my changes" option of the failed build notification)
  • Improvements in Statistic charts presentation, new passed tests count and inspections/duplicates counts charts.
  • Visual Studio add-on and Windows tray notifier are now using MSI-based installers
  • StarTeam support improved (e.g. now there is no requirement to have time synchronized between TeamCity server and StarTeam server, more accurate file deletion detection)
  • ClearCase performance improved
  • No labels

4 Comments

  1. I assume the teamcity-info.xml file is hard-coded?  Could be nice if TC picked up all teamcity-*-info.xml files (or some variation) in the case of multiple build processes providing statistics - although I suppose whatever process is generating this file could also update/extend an existing file..

    1. Yes, it is hard-coded currently. Actually, processing several files can cause some issues with precedence, etc. (e.g. imagine several teamcity-*-info.xml that set build number to own different values). The further extension to the feature that can cover your case is to allow publishing values currently stored in teamcity-info.xml via simple stdout. See/comment/vote for TW-3189.

      1. The issue with precedence came to mind shortly after posting the comment actually. Voted and watching TW-3189.