See also Indore 10 EAP2 (build 41463) Release Notes
Starting from this EAP, configuration of issue trackers, versioned settings, custom charts, shared resources and third-party report tabs was moved from
<TeamCity Data Directory>/config/projects/<ProjectID>/pluginData/plugin-settings.xml to
<TeamCity Data Directory>/config/projects/<ProjectID>/project-config.xml file. The file now has the
<project-extensions> element which contains all of the above-mentioned project features.
Since TeamCity 10, Team Foundation Work Items tracking is integrated with TeamCity. Supported versions are Microsoft Visual Studio Team Foundation Server 2010-2015, and Visual Studio Team Services.
TFS work items support can be configured on the Issue trackers page for a project. If a project has a TFVC root configured, TeamCity will suggest configuring the issue tracker as well.
By default, the integration works the same way as the other issue tracker integrations: you need to mention the work item ID in the comment message, so the work items can be linked to builds and the links will be displayed in various places in the TeamCity Web UI. Additionally, if your changeset has related work items,TeamCity can retrieve information about them even if no comment is added to the changeset. Besides, custom states for resolved work items are supported by TeamCity.
In addition, resolved states in TeamCity can be customized by using the
teamcity.tfs.workItems.resolvedStates internal property set to
"Closed?|Done|Fixed|Resolved?|Removed?" by default.
TeamCity administrators can enable / disable email verification (off by default) on the Administration | Authentication page.
If email verification is enabled on the TeamCity server, the Email address field in the user account registration form becomes mandatory. When an address is added / modified, the users will be asked to verify their it. If the email address is not verified, TeamCity will display a notification on the General tab of the user account settings. Verified email addresses will be marked with a green check on the Administration | Users page.
When project import scope if configured, users with the same username and email are compared based on their email verification. TeamCity will display the conflicts information and the administrator can choose whether to merge the users found.
It is now possible to specify newline- or comma-separated paths in the form of
-:source [ => target] to exclude files or directories from publishing as build artifacts.
Rules are grouped by the right part and are applied in the order of appearance, e.g.
+:**/* => target_directory -:**/folder1 => target_directory
will tell TeamCity to publish all files except for
folder1 into the
Starting from this EAP TeamCity uses unidirectional agent-to-server connection via the polling protocol by default. If for some reason the polling protocol cannot be used, TeamCity switches to the fallback bidirectional communication via xml-rpc.
Project-based Agent Management Permissions
Starting from this EAP, TeamCity introduces 6 new permissions for Project Administrators replacing the inherited Agent Manager role:
1) Enable / disable agents associated with project
2) Start / Stop cloud agent for project
3) Change agent run configuration policy for project
4) Administer project agent machines (e.g. reboot, view agent logs, etc.)
5) Remove project agent
6) Authorize project agent
These permissions are project-based and can provide agent management within an agent pool: if a person is granted a certain permission for all projects
within a pool, this user can perform this action on all agents in this pool. If an agent within a pool is assigned to a project where no such permission is granted to the user, the pool management right is revoked.
Prior to TeamCity 10, Agent Manager has permissions for customizing and managing Build Agents; he/she can change the run configuration policy, enable/disable build agents, and pause/resume build queue.