TeamCity 7.0 Help

Upgrade Notes

Changes from 7.1.4 to 7.1.5

teamcity.build.branch parameter semantics has changed, see http://youtrack.jetbrains.com/issue/TW-23699#comment=27-448002

Changes from 7.1.3 to 7.1.4

No noteworthy changes.

Changes from 7.1.2 to 7.1.3

No noteworthy changes.

Please check up-to-date list of known regressions for the version in our issue tracker.

Changes from 7.1.1 to 7.1.2

Possible issues with hg server-side checkout There is a known issue with 7.1.2 release: TW-24405 which can reproduce when server-side checkout, labeling or file content viewing are used for Mercurial repository. If you experience the error with message "abort: destination 'hg1' is not empty", please install the patch attached to the issue.

Other known issues Please also check a list of known regressions for the version in our issue tracker.

Changes from 7.1 to 7.1.1

No noteworthy changes.

Changes from 7.0.x to 7.1

Windows service configuration

Since version 7.1, TeamCity uses it's own service wrapping solution for the TeamCity server as opposed to that of default Tomcat one in previous versions. This changes the way TeamCity service is configured (data directory and server startup options including memory settings) and makes it unified between service and console startup. Please refer to the updated Configuring TeamCity Server Startup Properties on configuring the server startup properties.

Agent windows service started to use OS-provided environment variables. Once Agent server (and JVM) are x86 processes, agent will report x86 environment variables. The change may affect your CPU bitness checks. See MSDN Blog on how to check if machine supports x64 by reported environment variables

Default location for TeamCity Data Directory when installed with Windows installer This is only relevant for fresh TeamCity installations with Windows installer. Existing settings are preserved if you upgrade an existing installation. Windows installer now uses %\ALLUSERSPROFILE%\JetBrains\TeamCity location as default one for TeamCity Data Directory. In TeamCity 7.0 and previous versions that used to be %\USERPROFILE%\.BuildServer.

Windows domain login module When TeamCity server runs under Windows and Windows domain user authentication is used, TeamCity now uses another library (Waffle) to talk to the Windows domain. Under Linux the behavior is unchanged: jCIFS library is used as it were.

Unless you specified specific settings for jCIFS library in ntlm-config.properties file, your installation should not be affected. If you experience any issues with login into TeamCity with your Windows username/password after upgrade, please provide details Feedback. In the mean time you can switch to using old jCIFS library. For this, add teamcity.ntlm.use.jcifs=true line into Configuring TeamCity Server Startup Properties. Please note that jCIFS library approach can be depricated in future versions of TeamCity, so the property specification is not recommended if you can go without it.

Checkout directory change for Git and Mercurial Build configurations that have either Git or Mercurial VCS roots and use default checkout directory will perform clean checkout upon upgrade. The clean checkout will be triggered by changed default checkout directory name. Further builds will reuse the checkout directory more aggressively (all builds using different branches but using the same VCS root will use the same directory). This affects agent- and server-side checkouts.

Perforce agent checkout workspace names change Build configurations using Perforce agent-side checkout will perform clean checkout once after server upgrade. This is related to changed names for automatically generated Perforce workspaces.

SVN revision format For changes, detected in external repositories, SVN revision got format NNN_MMM:EXTUUID_CHANGEDATE, where NNN - revision of the main repository, MMM - revision of externals repository, EXTUUID - UUID of externals repository, CHANGEDATE - change timestamp. This change may affect plugins/REST api clients which use revision of the last build change somehow.

Eclipse IDE plugin compatibility Since TeamCity 7.1, Eclipse version 3.3 (Europa) is no longer supported by TeamCity Eclipse plugin. Eclipse 3.8 and Eclipse 4.2 (Juno) are now supported.

Default schema when Microsoft SQL Server is used as an external database Starting with version 7.1 TeamCity works only with a single database schema unlike previous versions when it could work with tables in any schemas of the database server.

TeamCity-related tables should now be located in the database schema which is set as default one for the database user used by TeamCity to connect to the database.

This change may require reconfiguration of the database to set default schema for the user used by TeamCity server to connect to the database.

Please check that all TeamCity-related tables are located in the default user's schema before performing the upgrade. (e.g. using the 'sys.tables' view)

If the default user's schema is not set right TeamCity can report "TeamCity database is empty or doesn't exist" error on the first start of newer TeamCity.

To change user's default schema, use the 'alter user' SQL command.

For the default schema description, see the "Default Schemas" section in the corresponding documentation.

Open API changes See Open API Changes

Changes from 7.0.1 to 7.0.4

No noteworthy changes.

Changes from 7.0 to 7.0.1

HTML report tabs URLs Change If you use direct links for build-level or project-level Including Third-Party Reports in the Build Results, please update the links as they will change after upgrade. The change is necessary to make the feature more reliable.

Changes from 6.5.x to 7.0

(Known issue) Build can hang or produce memory error for NUnit and other .Net test runners Affected are: .Net test runners (NUnit, MSTest, MSpec) as well as TeamCity NUnit console launcher. Reproduces when path to test assemblies has several deep paths without wildcards ("*").

Visible outcome: build hangs or fails with OutOfMemoryException error after "Starting ...JetBrains.BuildServer.NUnitLauncher.exe" link in the build log.

The issue (TW-20482) is fixed and the fix will be included in the next release. Patch with a fix is available.

Minimum Supported Project JDK for Ant Runner Starting with this version Ant runner requires minimum of JDK 1.4 in runtime build part (was 1.3 previously). This means that you will not be able to use TeamCity Ant runner if your project uses JDK 1.3 for compilation or tests running. For projects that require JDK 1.3 you can use command-line runner instead and configure "XML report processing" build feature to parse test reports.

Supported Java for Server and Agent Starting with this version the following requirements

  • TeamCity server should be run with JRE 1.6 or above (was 1.5 previously). TeamCity .exe distribution is already bundled with appropriate Java. For .tar.gz or .war TeamCity distributions you might need to install and configure server Installing and Configuring the TeamCity Server.

  • TeamCity agent should be run with JRE 1.6 or above (was 1.5 previously). Agent .exe distribution is already bundled with appropriate Java. If you used .zip agent distribution or installed the TeamCity agent with TeamCity version 5.0 or earlier, you might need Setting up and Running Additional Build Agents. If you run TeamCity 6.5.x, please check "Agents" page of your existing TeamCity server: the page will have a yellow warning in case any of the connected agents are running JDK less than 1.6.

Project/Template parameters override In TeamCity 7.0 project parameters have higher priority than parameters defined in template, i.e. if there is a parameter with some name and value in the project and there is parameter with the same name and different value in template of the same project, value from the project will be used. This was not so in TeamCity 6.5 and was changed to be more flexible when template belongs to anohter project. Build configuration parameters have the highest priority, as usual.

Support for Sybase is discontinued From this version support for Sybase as external database is shifted back into "experimental" state. The reason for this decision is that it does not seem like the database is actively used with TeamCity and supporting it requires significant effort from TeamCity team which otherwise can be directed to improving more important areas of the product. While it should be still Setting up an External Database we do not recommend to use Sybase as external database and we are not planning to provide support for the Sybase-related issues. Please consider using one of the other Supported Platforms and Environments. If you use Sybase please migrate to another database before upgrading TeamCity.

REST API Changes

  • Several objects got additional attributes and sub-elements (e.g. BuildType, VcsRoot). Please check that your parsing code still works. /buildTypes/ path: BuildType object dropped runParameters field (as well as /<locator>/runParameters path is dropped) in favor of steps collection and /<locator>/steps/ path.

  • A bug fixed which resulted in non-array JSON representation of single element arrays for some resources. Please check if your code is affected.

  • in build object, "dependency-build" element is renamed to "snapshot-dependencies", revisions/revision/vcs-root is renamed to revisions/revision/vcs-root-intance (and it points to resolved VCS root instance now), revisions/revision/display-version is renamed to "version".

  • in buildType object, "vcs-root" element is renamed to "vcs-root-entries"

Old version of the REST API is available via /app/rest/6.0/... URL in TeamCity 7.0. Please update your REST-using code as future versions of TeamCity might drop support for 6.0 protocol.

Minimum version of supported Tomcat If you use TeamCity .war distribution, please note that Tomcat 5.5 is no longer supported. Please update Tomcat to version 6.0.27 or above (Tomcat 7 is recommended).

Open API Changes

Classes from jetbrains.buildServer.messages.serviceMessages package like jetbrains.buildServer.messages.serviceMessages.BuildStatus no longer depend on jetbrains.buildServer.messages.Status class. To make your code compatible with TeamCity 6.0 - 7.0 you can use jetbrains.buildServer.messages.serviceMessages.ServiceMessage#asString methods, for example:

ServiceMessage.asString("buildStatus", new HashMap<String, String>() {{ put("text", "Errors found"); put("status", "FAILURE"); }});

See also Open API Changes

Changes from 6.5.4 to 6.5.6

No noteworthy changes

Changes from 6.5.4 to 6.5.5

(Known issue infex in 6.5.6) .NET Duplicates finder may stop working, the patch is available, please see this comment: http://youtrack.jetbrains.net/issue/TW-18784#comment=27-261174

Changes from 6.5.3 to 6.5.4

No noteworthy changes

Changes from 6.5.3 to 6.5.4

No noteworthy changes

Changes from 6.5.2 to 6.5.3

No noteworthy changes

Changes from 6.5.1 to 6.5.2

Maven runner Working with MAVEN_OPTS has changed again. Hopefully for the last time within the 6.5.x iteration. (see http://youtrack.jetbrains.net/issue/TW-17393) Now TeamCity acts as follows: 1. If MAVEN_OPTS is set TeamCity takes JVM arguments from MAVEN_OPTS 2. If "JVM command line parameters" are provided in the runner settings, they are taken instead of MAVEN_OPTS and MAVEN_OPTS is overwritten with this value to propagate it to nested Maven executions.

Those who after upgrading to 6.5 had problems of not using MAVEN_OPTS and who had to copy its value to the "JVM command line parameters" to make their builds work, now don't need to change anything in their configuration. Builds will work the same way they do in 6.5 or 6.5.1.

Changes from 6.5 to 6.5.1

(Fixed known issue) Long upgrade time and slow cleanup under Oracle

Changes from 6.0.x to 6.5

(Known issue) Long upgrade time and slow cleanup under Oracle On first upgraded server start the database structures are converted and this can take a long time (hours on a large database) if you use Oracle external database (TW-17094). This is already fixed in 6.5.1.

Agent JVM upgrade With this version of TeamCity we added semi-automatic upgrade of JVM used by the agents. If there is a Java 1.6 installed on the agent, and the agent itself is still running under the Java 1.5, TeamCity will ask to switch agent to Java 1.6. All you need is to review that detected path to Java is correct and confirm this switch, the rest should be done automatically. The operation is per-agent, you'll have to make it for each agent separately. Note that we recommend to switch to Java 1.6, as at some point TeamCity will not be compatible with Java 1.5. Make sure newly selected java process has same firewall rules (i.e. port 9090 is opened to accept connections from server)

IntelliJ IDEA Coverage data Coverage data produced by IntelliJ IDEA coverage engine bundled with TeamCity 6.5 can only be loaded in IntelliJ IDEA 10.5+. Due to coverage data format changes older versions of IntelliJ IDEA won't be able to load coverage from the server.

IntelliJ IDEA 8 is not supported Plugin for IntelliJ IDEA no longer supports IntelliJ IDEA 8.

Unsupported MySQL versions Due to bugs in MySQL 5.1.x TeamCity no longer supports MySQL versions in range 5.1 - 5.1.48. TeamCity won't start with appropriate message if unsupported MySQL version is detected. Please upgrade your MySQL server to version 5.1.49 or later.

Finish build properties are displayed Finished builds now display all their properties used in the build on "Parameters" tab. This can potentially expose names and values of parameters from other builds (those that the given build uses as artifact or snapshot dependency). Please make sure this is acceptable in your environment. You can also manage users who see the tab with "View build runtime parameters and data" permissions which is assigned "Project Developers" role by default.

PowerShell runner is bundled If you installed PowerShell manually, please remove it form .BuildServer/plugins as a fresh version is now bundled with TeamCity.

Changed settings location

  • XML test reporting settings are moved from runner settings into a dedicated Adding Build Features.

  • "Last finished build" artifact dependency on a build which has snapshot dependency is automatically converted into dedicated "Build from the same chain" source build setting.

Responsibility is renamed to Investigation A responsibility assigned for a failing build configuration or a test is now called investigation. This is just a terminology change to make the action more neutral. If you have any email processing rules for TeamCity investigation assignment activity, please check is they need updating to use new text patterns.

REST API Changes Several objects got additional attributes and sub-elements (e.g. "startDate" in reference to a build, "personal" in a change). Please check that your parsing code still works.

Cleaning Non-default Checkout Directories In previous releases, if you have specified build Build Checkout Directory explicitly using absolute path, TeamCity would not clean the content of the directory to free space on the disk. This is no longer the case. So if you have absolute path specified for the checkout directory and you need the directory to be present on agent for other build or for the machine environment, please set system.teamcity.build.checkoutDir.expireHours Build Checkout Directory to "never" and re-run the build. Please take into account that using Build Checkout Directory is not recommended.

If you are using one of Build Checkout Directory properties and it is set to "never" to prevent the checkout directory from automatic deletion, the directory might be deleted once after TeamCity upgrade. Running the build in the build configuration once after the upgrade (and within 8 days from the previous build) will ensure that the directory preserves the "protected" behavior and will not be automatically removed by TeamCity.

Free disk space This release exposes Free disk space in UI that was earlier only available via setting build configuration properties. While the old properties still work and take precedence, it is highly recommended to remove them and specify the value via "Disk Space" build feature instead. Future TeamCity versions might stop to consider the properties specified manually.

Command line runner @echo off which turns off command-echoing is added to scripts provided by "Custom script" runner parameter. To enable command-echoing add @echo on to the script.

Windows Tray Notifier You will need to upgrade windows tray notifier by uninstalling it and installing it again. Unfortunately, auto-upgrade will not work due to issues in old version of Windows Tray Notifier.

Maven runner

  • In earlier TeamCity versions Maven was executed by invoking the 'mvn' shell script. You could specify some parameters in MAVEN_OPTS and some in UI. Maven build runner created its own MAVEN_OPT by concatenating these two (%\MAVEN_OPTS%+jvmArgs). In this case, if some parameter was specified twice - in MAVEN_OPTS and in UI, only the one specified in MAVEN_OPTS was effective. Starting with TeamCity 6.5 Maven runner forms direct java command. While this approach solves many different problems, it also means that MAVEN_OPTS isn't effective anymore and all JVM command line parameters should be specified in build runner settings instead of MAVEN_OPTS.

  • Those who had to manually setup surefire XML reporting for Maven release builds in TeamCity 6.0.x because otherwise tests weren't reported, now can forget about that. Since TeamCity 6.5 surefire tests run by release:prepare or release:perform goals are automatically detected. So don't forget to switch surefire XML reporting off in the build configuration settings to avoid double-reporting!

Email sending settings Please check email sending settings are working correctly after upgrade (via Test connection on Administration > Server Configuration > EMail Notifier). If no authentication is needed, make sure login and password fields are blank. Non-blank fields may cause email sending errors if SMTP server is not expecting authentication requests.

XML Report Processing Tests from Ant JUnit XML reports can be reported twice (see TW-19058), as we no longer automatically ignore TESTS-xxx.xml report. To workaround this avoid using *.xml mask and specify more concrete rules like TEST-*.xml or alike that will not match report with name starting with "TESTS-"

Open API Changes Several return types have changes in TeamCity open API, so plugins might need recompilation against new TeamCity version to continue working. Also, some API was deprecated and will be discontinued in later releases. It is recommended to update plugins not to use deprecated API. See also Open API Changes

Changes from 6.0.2 to 6.0.3

No noteworthy changes

Changes from 6.0.1 to 6.0.2

Maven and XML Test Reporting Load CPU on Agent If you use Maven or XML test reporter and your build is CPU-intensive, you might find important the known issue. Patch is available, fixed in the following updates.

Changes from 6.0 to 6.0.1

No noteworthy changes

Changes from 5.1.x to 6.0

Visual Studio Add-in and Perforce There is critical bug in TeamCity 6.0 VS Add-in when Perforce is enabled. This can cause Visual Studio hangs and crashes. The fixed add-in version is available. (related issue). The issue is fixed in TeamCity 6.0.1.

TFS checkout on agent TFS checkout on agent might refuse to work with errors. Patch is available, see the comment. Related issue. The issue is fixed in TeamCity 6.0.1.

Error Changing Priority class You may encounter a browser error while changing priority number of a priority class. A patch is available in a related issue. The issue is fixed in TeamCity 6.0.1.

IntelliJ IDEA Compatibility IntelliJ IDEA 6 and 7 are no longer supported in TeamCity plugin for IntelliJ IDEA.

Also, if you plan to upgrade to IntelliJ IDEA X (or other JetBrains IDE) please review this Known Issues.

Build Failure Notifications TeamCity 6.0 differentiates between build failure occurred while running a build script and one occurred while preparing for the build. The errors occurring in the latter case are called "failed to start" errors and are hidden by default from web UI (see "Show canceled and failed to start builds" option on Build Configuration page).

Since TeamCity 6.0, there is a separate notification rule "The build fails to start" which applies for "failed to start" builds. All the rest build failure notifications relate to build script-related failures.

Please note that on upgrade, all users who had "The build fails" notification on, will automatically get "The build fails to start" option to preserve old behavior.

Properties Changes teamcity.build.workingDir property should no longer be used in non-runner settings. For backward compatibility, the property is supported in non-runner settings and is resolved to the working directory of the first defined build step.

Swabra and Build Queue Priorities Plugins are Bundled If you have installed the plugins previously, please remove them (typically form .BuildServer/plugins) before starting upgraded TeamCity version.

Maven runner Java older than 1.5 is no longer supported by the agent part of Maven runner. Please make sure you specify 1.6+ JVM in Maven runner settings or ensure JAVA_HOME points to such JVM.

NUnit and MSTest Tests If you had NUnit or MSTest tests configured in TeamCity UI (sln and MSBuild runners), the settings are extracted form the runners and converted to a new runner of corresponding type.

Please note that implementation of tests launching has changed and this affected relative paths usage: in TeamCity 6.0 the working directory and all the UI-specified wildcards are resolved based on the build's Build Checkout Directory, while they used to be based on the directory containing .sln file. Simple settings are converted on TeamCity upgrade, but you might need to verify the runners contain appropriate settings.

"%" Escaping in the Build Configuration Properties Now, two percentage signs (%%) in values defined in Build Configuration settings are treated as escape for a single percentage sign. Your existing settings are converted on upgrade to preserve functioning like in previous versions. However, you might need to review the settings for unexpected "%" sign-related issues.

.Net Framework Properties are Reported as Configuration Parameters In previous TeamCity versions, installed .Net Frameworks, Visual Studios and Mono were reported as System Properties of the build agents. This made the properties available in the build script. In order to reduce number of TeamCity-specific properties pushed into the build scripts, the values are now reported via Configuration Parameters (that is, without "system." prefix) and are not available in the build script by default. They still be used in the Build Configuration settings via %-references by their previous names, just without "system." prefix.

Ipr runner is deprecated in favor of IntelliJ IDEA Project runner Runner for IntelliJ IDEA projects was completely rewritten. It is not named "IntelliJ IDEA Project" runner. Previously available Ipr runner is also preserved but is marked as deprecated and will be removed in one of the further major releases of TeamCity. It is highly recommended to migrate your existing build configurations to the new runner. Please note that the new runner uses different approach to run tests: you need to have a shared Run Configuration created in IntelliJ IDEA and reference it in the runner settings.

Cleanup for Inspection and Duplicates data Starting from 6.0 Inspection and Duplicates reports for the builds are cleaned when build is cleaned from history, not when build's artifacts are cleaned as it used to be.

Inspection and Duplicates runners require Java 1.6 "Inspections" and "Duplicates (Java)" runners now require Java JDK 1.6. Please ensure Java 1.6 is installed on relevant agents and check it is specified in the "JDK home path" setting of the runners.

XML Report Validation If you had invalid settings of "XML Report Processing" section of the build runners, you might find the Build Configurations reporting "Report paths must be specified" messages upon upgrade. In this case, please go to the runner settings and correct the configuration. (related issue)

Open API Changes See Open API Changes Several jars in devPackage were reordered, some moved under runtime subdirectory. Please update your plugin projects to accommodate for these changes.

REST API Changes Several objects got additional attributes and sub-elements. Please check that your parsing code still works.

Perforce Clean Checkout All builds using Perforce checkout will do a clean checkout after server upgrade. Please note that this can impose a high load on the server in the first hours after upgrade and server can be unresponsive while many builds are in "transferring sources" stage.

Changes from 5.1.2 to 5.1.3

Path to executable in Command line runner The bug was fully fixed. The behavior is the same as in pre-5.1 builds.

Changes from 5.1.1 to 5.1.2

Jabber notification sending errors are displayed in web UI for administrators again (these messages were disabled in 5.1.1). If you do not use Jabber notifications, please pause the Jabber notifier on the Jabber settings server settings page.

Changes from 5.1 to 5.1.1

Path to executable in Command line runner The bug was partly fixed. The behavior is the same as in pre-5.1 builds except for the case when you have the working directory specified and have the script in both checkout and working directory. The script from the working directory is used.

Path to script file in Solution runner and MSBuild runner The bug was fixed. The behavior is the same as in pre-5.1 builds.

Changes from 5.0.3 to 5.1

Notification templates change Since 5.1, TeamCity uses Customizing Notifications (Freemarker) to generate notification messages. New default templates are supplied and customizations to the templates made prior to upgrading are no longer effective.

If you customized notification templates prior to this upgrade, please review the new notification templates and make changes to them if necessary. Old notification templates are copied into <TeamCity Data Directory>/config/_trash/_notifications directory. Hope, you will enjoy the new templates and new extended customization capabilities.

External database drivers location JDBC drivers can now be placed into <TeamCity Data Directory>/lib/jdbc directory instead of WEB-INF/lib. It is recommended to use the new location. See details at Setting up an External Database.

PostgresSQL jdbc driver is no more bundled with TeamCity installation package, you will need to Setting up an External Database it yourself upon upgrade.

Database connection properties Database connection properties template files have changed their names and are placed into database.<database-type>.properties.dist files under <TeamCity Data Directory>/config directory. They follow TeamCity Data Directory.

It is recommended to review your database.properties file by comparing it with the new template file for your database and remove any options that you did not customize specifically.

Default memory options change We changed the default Installing and Configuring the TeamCity server for PermGen memory space and if you had -Xmx JVM option changed to about 1.3G and are running on 32 bit JVM, the server may fail to start with a message like: Error occurred during initialization of VM Could not reserve enough space for object heap Could not create the Java virtual machine. On this occasion, please consider either:

Vault Plugin is bundled In this version we bundled Vault (with experimental status). Please make sure to uninstall the plugin from .BuildServer/plugins (just delete plugin's zip) if you installed it previously.

Path to executable in Command line runner A bug was introduced that requires changing the path to executable if working directory is specified in the runner. The bug is partly fixed in 5.1.1 and fully fixed in 5.1.3.

Path to script file in Solution runner and MSBuild runner A bug was introduced that requires changing the path to script if working directory is specified in the runner. The bug is fixed in 5.1.1.

Open API Changes See Open API Changes

Changes from 5.0.2 to 5.0.3

No noteworthy changes.

Changes from 5.0.1 to 5.0.2

External change viewers The relativePath variable is now replaced with relative path of a file without checkout rules. The previous value can be accessed via relativeAgentPath. More information at TW-10801.

Changes from 5.0 to 5.0.1

No noteworthy changes.

Changes from 4.5.6 to 5.0

Pre-5.0 Enterprise Server Licenses and Agent Licenses need upgrade With the version 5.0, we announce changes to the upgrade policy: Upgrade to 5.0 is not free. Every license (server and agent) bought since 5.0 will work with any TeamCity version released within one year since the license purchase. Please review the detailed information at Licensing and Upgrade section of the official site.

Bundled plugins If you used standalone plugins that are now bundled in 5.0, do not forget to remove the plugins from .BuildServer/plugins directory. The newly bundled plugins are:

  • Mercurial

  • Git (JetBrains)

  • REST API (was provided with YouTrack previously)

Other plugins If you use any plugins that are not bundled with TeamCity, please make sure you are using the latest version and it is compatible with the 5.0 release. e.g. You will need the latest version of Groovy plug and other properties-providing extensions. Pre-5.0 notifier plugins may lack support for per-test and assignment responsibility notifications.

Obsolete Properties The system property "build.number.format" and environment variable "BUILD_NUMBER_FORMAT" are removed. If you need to use build number format in your build (let us know why), you can define build number format as %system.<property name>% and define <property name> system property in the build configuration (it will be passed to the build then).

Oracle database If you use TeamCity with Oracle database, you should add an addition privilege to the TeamCity Oracle user. In order to do it, log in to Oracle as user SYS and perform

grant execute on dbms_lock to <TeamCity_User>;

PostgreSQL database TeamCity 5.0 supports PostrgeSQL version 8.3+. So if the version of your PostgreSQL server is less than 8.3 then it needs to be upgraded.

Open API Changes See Open API Changes

Changes from 4.5.2 to 4.5.6

No noteworthy changes.

Changes from 4.5.1 to 4.5.2

Here is a critical issue with Rake runner in 4.5.2 release. Please see TW-8485 for details and a fixing patch.

Changes from 4.5.0 to 4.5.1

No noteworthy changes.

Changes from 4.0.2 to 4.5

Default User Roles The roles assigned as default for new users will be moved to "All Users" groups and will be effectively granted to all users already registered in TeamCity.

Running builds during server restart Please ensure there are no running builds during server upgrade. If there are builds that run during server restart and these builds have test, the builds will be canceled and re-added to build queue (TW-7476).

LDAP settings rename If you had LDAP integration configured, several settings will be automatically converted on first start of the new server. The renamed settings are:

  • formatDN — is renamed to teamcity.auth.formatDN

  • loginFilter — is renamed to teamcity.auth.loginFilter

Changes from 4.0.1 to 4.0.2

Increased first cleanup time The first server cleanup after the update can take significantly more time. Further cleanups should return to usual times. During this first cleanup the data associated with deleted build configuration is cleaned. It was not cleaned earlier because of a bug in TeamCity versions 4.0 and 4.0.1.

Changes from 4.0 to 4.0.1

"importData" service message arguments id argument renamed to type and file to path. This change is backward-compatible. See FxCop section for examples of new syntax.

Changes from 3.1.2 to 4.0

Initial startup time On the very first start of the new version of TeamCity, the database structure will be upgraded. This process can increase the time of the server startup. The first startup can take up to 20 minutes more then regular one. This time depends on the size of your builds history, average number of tests in a build and the server hardware.

Users re-login will be forced after upgrade Upon upgrade, all users will be automatically logged off and will need to re-login in their browsers to TeamCity web UI. After the first login since upgrade, Remember me functionality will work as usual.

Previous IntelliJ IDEA versions support IntelliJ IDEA plugin in this release is no longer compatible with IntelliJ IDEA 6.x versions. Supported IDEA versions are 7.0.3 and 8.0.

Using VCS revisions in the build build.vcs.number.N system properties are replaced with build.vcs.number.<escaped VCS root name> properties (or just build.vcs.number if there is only one root). If you used the properties in the build script you should update the usages manually or switch compatibility mode on. References to the properties in the build configuration settings are updated automatically. Corresponding environment variable has been affected too. Defining and Using Build Parameters in Build Configuration.

Test suite Due to the fact that TeamCity started to handle tests suites, the tests with suite name defined will be treated as new tests (thus, test history can start from scratch for these tests.)

Artifact dependency pattern Artifact dependencies patterns now support Wildcards. If you relied on "" pattern to match directory names, please adjust your pattern to use " /" instead of single "*". If you relied on the "" pattern to download only the files without extension, please update your pattern to use "." for that.

Downloading of artifacts with help of Ivy If you downloaded artifacts from the build scripts (like Ant build.xml) with help of Ivy tasks you should modify your ivyconf.xml file and remove all statuses from there except "integration". You can take the ivyconf.xml file from the following page as reference: Configuring Dependencies

Browser caches (IE) To force Internet Explorer to use updated icons (i.e. for the Run button) you may need to force page reload (Ctrl+Shift+R) or delete "Temporary Internet Files".

Changes from 3.1.1 to 3.1.2

No noteworthy changes.

Changes from 3.1 to 3.1.1

No noteworthy changes.

Changes from 3.0.1 to 3.1

Guest User and Agent Details

Starting from version 3.1, the Guest user does not have access to the agent details page. This has been done to reduce exposing potentially sensitive information regarding the agents' environment. In the Enterprise Edition, the Guest user's roles can be edited at the Users and Groups page to provide the needed level of permission.

StarTeam Support

Working Folders in Use

Since version 3.1 when checking out files from a StarTeam repository TeamCity builds directory structure on the base of the working folder names, not just folder names as it was in earlier versions. So if you are satisfied with the way TeamCity worked with StarTeam folders in version 3.0, ensure the working folders' names are equal to the corresponding folder names (which is so by default).

Also note, that although StarTeam allows using absolute paths as working folders, TeamCity supports relative paths only and doesn't detect absolute paths presence. So be careful and review your configuration.

StarTeam URL Parser Fixed

In version 3.0 a user must have followed a wrong URL scheme. It was like starteam://server:49201/project/view/rootFolder/subfolder/... and didn't work when user tried to refer a non-default view. In version 3.1 the native StarTeam URL parser is utilized. This means you now don't have to specify the root folder in the URL, and the previous example should look like starteam://server:49201/project/view/subfolder/...

Changes from 3.0 to 3.0.1

Linux Agent Upgrade

  • Due to an issue with Agent upgrade under Linux, Agent auxiliary Launcher processes may have been left running after agent upgrades. Versions 3.0.1 and up fix the issue. To get rid of the stale running processes, after automatic agent upgrade, please stop the agent (via agent.sh kill command) and kill any running java jetbrains.buildServer.agent.Launcher processes and start the agent again.

Changes from 2.x to 3.0

Incompatible changes

Please note that TeamCity 3.0 introduces several changes incompatible with TeamCity 2.x:

  • build.working.dir system property is renamed to teamcity.build.checkoutDir. If you use the property in you build scripts, please update the scripts.

  • runAll.bat script now accepts a required parameter: start to start server and agent, stop to stop server and agent.

  • Under Windows, agent.bat script now accepts a required parameter: start to start agent, stop to stop agent. Note that in this case agent will be stopped only after it becomes idle (no builds are run). To force immediate agent stopping, use agent.bat stop force command that is available under both Windows and Linux (agent.sh stop force). Under Linux you can also use agent.sh stop kill command to stop agents not responding to agent.sh stop force.

Build working directory

Since TeamCity 3.0 introduces ability to configure VCS roots on per-Build Configuration basis, rather then per-Project, the default directory in which build configuration sources are checked out on agent now has generated name. If you need to know the directory used by a build configuration, you can refer to <agent home>/work/directory.map file which lists build configurations with the directory used by them. See also Build Checkout Directory

User Roles when upgrading from TeamCity 1.x/2.x/3.x Professional to 3.x Enterprise

When upgrading from TeamCity 1.x/2.x/3.x Professional to 3.x Enterprise for the first time TeamCity's accounts will be assigned the following Role and Permission by default:

  • Administrators become System Administrators

  • Users become Project Developers for all of the projects

  • The Guest account is able to view all of the projects

  • Default user roles are set to Project Developer for all of the projects

Changes from 1.x to 2.0

Database Settings Move Move your database settings from the <TeamCity installation folder>/ROOT/WEB-INF/buildServerSpring.xml file to the database.properties file located in the TeamCity configuration data directory (<TeamCity Data Directory>/config).

Last modified: 20 April 2023
Hardware Requirements for TeamCity Upgrade