TeamCity 7.0 Help

How To...

Integrate with an Issue Tracker

TeamCity comes with dedicated Integrating TeamCity with Issue Tracker for YouTrack, Jira and Bugzilla. For any other tracker, you can turn any issue tracker issue ID references in change comments into links. Please see Mapping External Links in Comments for configuration instructions.

Install Multiple Agents on the Same Machine

See the Setting up and Running Additional Build Agents under agent installation documentation.

Watch Several TeamCity Servers with Windows Tray Notifier

TeamCity Tray Notifier is used normally to watch builds and receive notifications from a single TeamCity server. However, if you have more than one TeamCity server and want to monitor them with Windows Tray Notifier simultaneously, you need to start a separate instance of Tray Notifier for each of the servers from the command line with the /allowMultiple option:

  • From the TeamCity Tray Notifier installation folder (by default, it's C:\Program Files\JetBrains\TeamCity run the following command: JetBrains.TrayNotifier.exe /allowMultiple Optionally, for each of the Tray Notifier instances you can explicitly specify the URL of the server to connect using the /server option. Otherwise, for each further tray notifier instance you will need to log out and change server's URL via UI. JetBrains.TrayNotifier.exe /allowMultiple /server:http://myTeamCityServer

See also details in the issue tracker.

Move TeamCity Installation to a New Machine

If you need to move existing TeamCity installation to a new hardware or clean OS, it is recommended to follow copy_server the server from one machine to another and then switch_server_to_another_address from the old server to a new one. If you are sure you do not need the old server data you can probably perform move operations instead of copying.

You can use existing license keys when you move the server from one machine to another (as long as there are no two servers running at the same time). As license keys are stored under <TeamCity Data Directory>, you transfer the license keys with all the other TeamCity settings data.

A usual advice is not to combine TeamCity update with any other actions like environment or hardware changes and perform the changes one at a time so that if something goes wrong the cause can be easily tracked.

Switching from one server to another Please note that TeamCity Data Directory and database should be used by a single TeamCity instance at any given moment. If you configured new TeamCity instance to use the same data, please ensure you shutdown and disable old TeamCity instance before starting a new one.

Generally it is recommended to use a domain name to access the server (in agent configuration and when users access TeamCity web UI). This way you can update the DNS entry to make the address resolve to the IP address of the new server and after all cached DNS results expire, all clients will be automatically using the new server.

However, if you need to use another server domain address, you will need:

  • Switch agents to new URL (requires updating serverUrl property in Build Agent Configuration on each agent).

  • Upon new server startup do not forget to update Configuring Server URL on Administration | Global Settings page.

  • Notify all TeamCity users to use the new address

Move TeamCity Agent

Apart from the binaries, TeamCity agent stores it's configuration and data left from the builds it run. Usually the data from the previous builds makes preparation for the future builds a bit faster, but it can be deleted if necessary. The configuration is stored under conf and launcher\conf directories. The data collected by previous build is stored under work and system directories.

The most simple way to move agent installation into a new machine or new location is to:

With these steps the agent will be recognized by TeamCity server as the same and will perform clean checkout for all the builds.

Please also review the Agent Home Directory for a list of directories that can be deleted without affecting builds consistency.

Share the build number for builds in a chain build

Suppose you have build configurations A and B that you want to build in sync: use same sources and take the same build number. Solution:

  1. Create a build configuration C, then Dependent Build: A on C and B on C.

  2. Set the Configuring General Settings in A and B to: %dep.<btID>.system.build.number% Where <btID> is the internal ID of the build configuration C. Please refer to the Build Configuration page for description of how to determine build configuration ID.

This reference is also available if you use artifact dependencies instead of snapshot. Predefined Build Parameters about dependency properties.

We plan to provide more option on build number sharing. Please watch/comment on TW-7745.

Use an external tool that my build relies on

If you need to use specific external tool to be installed on a build agent to run your builds, you have the following options:

  • Check in the tool into the version control and use relative paths.

  • Create a separate build configuration with a single "fake" build which would contain required files as artifacts, then use artifact dependencies to send files to the target build.

  • Install and register the tool in TeamCity:

    1. Install the tool on all the agents that will run the build.

    2. Add env. or system. property into buildAgent.properties file (or add environment variable to the system).

    3. Add agent requirement for the property in the build configuration.

    4. Use the property in the build script.

  • Add environment preparation stage into the build script to get the tool form elsewhere.

Change Server Port

See Installing and Configuring the TeamCity Server in server installation instructions.

Make temporary build files erased between the builds

Update your build script to use path stored in ${teamcity.build.tempDir} (Ant's style name) property as the temp directory. TeamCity agent creates the Agent Home Directory before the build and deletes it right after the build.

Retrieve Administrator Password

On the first start TeamCity displays Administrator Setup page. TeamCity installation should always have a user with System Administrator role in the current authentication scheme. See also Configuring Authentication Settings when switching from one authentication scheme to another.

If there is no user account with System Administrator role in the current authentication scheme, you can use http://<your_TeamCity_server>/setupAdmin.html URL to setup administrator account. If there is an administrator account in the current authentication scheme, the page is not available and you need to remember the administrator account credentials.

If you forgot Administrator password and use internal database, you can reset the password using the Changing user password with default authentication scheme. Otherwise you can use REST API Plugin to add System Administrator role to any existing user. And here is an instruction to patch roles directly in the database provided by a user.

Related feature requests in our tracker: TW-1964, TW-4524, TW-1681, TW-2456.

How do I clear build queue if it got too many builds due to a configuration error

Try pausing the build configuration that has the builds queued. On build configuration pausing all its builds are removed form the queue. Also there is an ability to delete many builds from the build queue in a single dialog.

Estimate hardware requirements for TeamCity

The hardware requirements differ for the server and the agents.

The agent hardware requirements are basically determined by the builds that are run. Running TeamCity agent software introduces requirement for additional CPU time (but it can usually be neglected comparing to the build process CPU requirements) and additional memory: about 500Mb. Although, you can run build agent on the same machine as the TeamCity server, the recommended approach is to use a separate machine (though, it may be virtual) for each build agent. If you chose to install several agents Setting up and Running Additional Build Agents, please consider possible CPU, disk, memory or network bottlenecks that might occur. Performance Monitor build feature can help you in analyzing live data.

The server hardware requirements depend on the server load, which in its turn depends significantly on the type of the builds and server usage. Consider the following general guidelines.

Database Note : When using the server extensively, database performance starts to play greater role. For reliability and performance reasons you should use external database. Please see Setting up an External Database on choosing external database. Database size requirements naturally vary based on the amount of data stored. An active server database usage can be estimated at several gigabytes of data. Say, 2 Gb per year.

Overview on the TeamCity hardware resources usage :

  • CPU: TeamCity utilizes multiple cores of the CPU, so increasing number of cores makes sense. It is probably not necessary to dedicate more than 8 cores to TeamCity server.

  • Memory: See a Installing and Configuring the TeamCity Server on memory usage. Consider also that required memory may depend on the JVM used (32 bit or 64 bit). You will probably not need to dedicate more than 4G of memory to TeamCity server.

  • HDD/disk usage: This sums up from the temp directory usage (<TeamCity home>/temp and OS temp directory) and .BuildServer/system usage. Performance of the TeamCity server highly depends on the disk system performance. As TeamCity stores large amounts of data under .BuildServer/system (most notably, VCS caches and build results) it is important that the access to the disk is fast. (e.g. please pay attention to this if you plan to store the data directory on a network drive).

  • Network: This mainly sums up from the traffic from VCS servers, to clients (web browsers, IDE, etc.) and to/from build agents (send sources, receive build results, logs and artifacts).

The load on the server depends on :

  • number of build configurations;

  • number of builds in the history;

  • number of the builds running daily;

  • amount of data generated by the builds (size of the build log, number and output size of unit tests, number of inspections and duplicates hits etc.);

  • cleanup rules configured

  • number of agents and their utilization percentage;

  • number of users having TeamCity web pages open;

  • number of users logged in from IDE plugin;

  • number and type of VCS roots as well as checking for changes interval for the VCS roots. VCS checkout mode is relevant too: server checkout mode generates greater server load. Specific types of VCS also affect server load, but they can be roughly estimated based on native VCS client performance;

  • number of changes detected by TeamCity per day in all the VCS roots;

  • total size of the sources checked out by TeamCity daily.

Based on our experience, a modest hardware like 3.2 dual core CPU, 3.2Gb memory under Windows, 1Gb network adapter can provide acceptable performance for the following setup:

  • 60 projects and 300 build configurations (with one forth being active and running regularly);

  • more than 300 builds a day;

  • about 2Mb log per build;

  • 50 build agents;

  • 50 web users and 30 IDE users;

  • 100 VCS roots (mainly Perforce and Subversion using server checkout), average checking for changes interval is 120 seconds;

  • more than 150 changes per day;

  • the database (MySQL) is running on the same machine, main TeamCity process has -Xmx1100m -XX:MaxPermSize=120m JVM settings.

However, to ensure peak load can be handled well, more powerful hardware is recommended.

HDD free space requirements are mainly determined by the number of builds stored on the server and the artifacts size/build log size in each. Server disk storage is also used to store VCS-related caches and you can estimate that at double the checkout size of all the VCS roots configured on the server.

If the builds generate large number of data (artifacts/build log/test data), using fast hard disk for storing .BuildServer/system directory and fast network between agents and server are recommended.

The general recommendation for deploying large-scale TeamCity installation is to start with a reasonable hardware and add more projects to the server gradually, monitoring the performance characteristics and deciding on necessary hardware or software improvements. Anyway, best administration practices are recommended like keeping adequate disk defragmentation level, etc.

If you consider cloud deployment for TeamCity agents (e.g. on Amazon EC2), please also review Setting Up TeamCity for Amazon EC2

A note on agents setup in JetBrains internal TeamCity installation: We use both separate machines each running a single agent and dedicated "servers" running several virtual machines each of them having a single agent installed. Experimenting with the hardware and software we settled on a configuration when each core7i physical machine runs 3 virtual agents, each using a separate hard disk. This stems form the fact that our (mostly Java) builds depend on HDD performance in the first place. But YMMV.

TeamCity can work well with up to 200 build agents (200 concurrently running builds). If you need more agents/parallel builds, it is recommended to setup several separate TeamCity instances and distribute the projects between them.

See also a related blog post.

Setup TeamCity in Replication/Clustering Environment

TeamCity does not provide specific support for any of replication/high availability or clustering solutions; however you can replicate the data that TeamCity server uses and prepare to start a new server using the same data if existing server malfunctions.

When setting up TeamCity in a replication environment please note that TeamCity uses both database and file storage to save data. You can browse through TeamCity Data Backup and TeamCity Data Directory pages in to get more information on TeamCity data storing.

Basically, both TeamCity data directory on disk and database that TeamCity uses should remain in a consistent state and thus should be replicated together.

Only single TeamCity server instance should use database and data directory at any time.

Please also ensure that the distribution of the backup server is of exactly the same version as the main server.

See also information on switch_server_to_another_address from one server to another.

Move TeamCity projects from one server to another

Generally, moving projects to a server that already have projects/build configurations configured is not supported. For addressing simple cases manually, please see a comment.

Automatically create or change TeamCity build configuration settings

If you need a level of automation and web administration UI does not suite your needs, there are two possibilities:

Attach Cucumber reporter to Ant build

If you use Cucumber for Java applications testing you should run cucumber with --expand and special --format options. More over you should specify RUBYLIB environment variable pointing on necessary TeamCity Rake Runner ruby scripts:

<target name="features"> <java classname="org.jruby.Main" fork="true" failonerror="true"> <classpath> <pathelement path="${jruby.home}/lib/jruby.jar"/> <pathelement path="${jruby.home}/lib/ruby/gems/1.8/gems/jvyaml-0.0.1/lib/jvyamlb.jar"/> .... </classpath> <jvmarg value="-Xmx512m"/> <jvmarg value="-XX:+HeapDumpOnOutOfMemoryError"/> <jvmarg value="-ea"/> <jvmarg value="-Djruby.home=${jruby.home}"/> <arg value="-S"/> <arg value="cucumber"/> <arg value="--format"/> <arg value="Teamcity::Cucumber::Formatter"/> <arg value="--expand"/> <arg value="."/> <env key="RUBYLIB" value="${agent.home.dir}/plugins/rake-runner/rb/patch/common${path.separator}${agent.home.dir}/plugins/rake-runner/rb/patch/bdd"/> <env key="TEAMCITY_RAKE_RUNNER_MODE" value="buildserver"/> </java> </target>

Please, check RUBYLIB path separator. (';' for Windows, ':' for Linux, or '${path.separator}') If you are launching Cucumber tests using Rake build language TC will add all necessary cmdline parameters and env. variables automatically. P.S: This tip works in TeamCity version >= 5.0.

Get last successful build number

Use URL like this:

http://<your TeamCity server>/app/rest/buildTypes/id:<internal ID of build configuration>/builds/status:SUCCESS/number

The build number will be returned as a plain-text response. For <internal ID of build configuration>, see Build Configuration. This functionality is provided by REST API Plugin

Create a copy of TeamCity server with all data

One of the ways to create a copy of the server is to create a TeamCity Data Backup, then install a new TeamCity server of the same version that you already run, ensure you have appropriate environment configured, ensure that the server uses own TeamCity Data Directory and own Setting up an External Database and then Restoring TeamCity Data from Backup. This way the new server won't get build artifacts and some other less important data. If you need them, you will need to copy appropriate directories (e.g. "artifacts") from TeamCity Data Directory from the original to the copied server.

If you do not want to use bundled backup functionality or need manual control over the process, here is a description of the general steps one would need to perform to manually create copy of the server:

  1. create a TeamCity Data Backup so that you can restore it if anything goes wrong,

  2. ensure the server is not running,

  3. either perform clean Installing and Configuring the TeamCity server or copy TeamCity binaries (TeamCity home directory) into the new place (temp and work subdirectories can be omitted during copying). Use exactly the same TeamCity version. If you plan to upgrade after copying, perform the upgrade only after you have existing version up and running.

  4. transfer relevant environment if it was specially modified for existing TeamCity installation. This might include:

    • if you run TeamCity with OS startup (e.g. Windows service), make sure all the same configuration is performed on the new machine

    • use the same Configuring TeamCity Server Startup Properties

    • use appropriate OS user account for running TeamCity server process with appropriately configured settings, global and file system permissions

    • transfer OS security settings if required

    • ensure any files/settings that were configured in TeamCity web UI are accessible; put necessary libraries/files inside TeamCity installation if they were put there earlier)

  5. copy TeamCity Data Directory. If you do not need the full copy, refer to the items below for optional items.

    • .BuildServer/config to preserve projects and build configurations settings

    • .BuildServer/lib and .BuildServer/plugins if you have them

    • files from the root of .BuildServer/system if you use internal database and you do not want to perform database move.

    • .BuildServer/system/messages (optional) if you want build logs (including tests failure details) preserved on the new server

    • .BuildServer/system/artifacts (optional) if you want build artifacts preserved on the new server

    • .BuildServer/system/changes (optional) if you want personal changes preserved on the new server

    • .BuildServer/system/pluginData (optional) if you want to preserve state of various plugins and build triggers

    • .BuildServer/system/caches and .BuildServer/system/caches (optional) are not necessary to copy to the new server, they will be recreated on startup, but can take some time to be rebuilt (expect some slow down).

  6. create copy of the Setting up an External Database that your TeamCity installation is using in new schema or new database server

  7. configure new TeamCity installation to use proper TeamCity Data Directory and Setting up an External Database (.BuildServer/config/database.properties points to a copy of the database)

Note: if you want to do a quick check and do not want to preserve builds history on the new server you can skip step 6 (cloning database) and all items of the step 5 marked as optional.

  1. ensure the new server is configured to use another data directory and the database then the original server At this point you should be ready to run the copy TeamCity server.

  2. run new TeamCity server

  3. upon new server startup do not forget to update Configuring Server URL on Administration | Global Settings page. You will also probably need to disable Email and Jabber notifiers or change their settings to prevent new server from sending out notifications

  4. if you need the services on the copied server check that email, jabber and VCS servers are accessible from the new installation.

  5. install new agents (or select some form the existing ones) and configure them to connect to the new server (using new server URL)

See also the notes on Move-TeamCity-Installation-to-a-New-Machine from one machine to another.

Licensing issues You cannot use a single TeamCity license on two running servers at the same time, so to run a copy of TeamCity server you will need another license. You can get TeamCity Licensing Policy from the official TeamCity download page. If you need an extension of the license or you have already evaluated the same TeamCity version, please contact our sales department.

Test-drive newer TeamCity version before upgrade

It's advised to try new TeamCity version before upgrading your production server. Usual procedure is to copy_server of your production TeamCity installation, then Upgrade it, try the things out and when everything is checked, drop the test server and upgrade the main one.

How do I choose OS/platform for TeamCity server

Once the server/OS fulfills the Supported Platforms and Environments, TeamCity can run on any system. Please also review the Supported Platforms and Environments for the integrations you plan to use (e.g. integration with Microsoft TFS and VSS will work only under MS Windows)

If you have no preference, Linux platforms may be more preferable due to more effective file system operations and the level of required general OS maintenance.

Final Operating System choice should probably depend more on the available resources and established practices in your organization.

If you choose to install 64 bit OS, TeamCity can run under 64 bit JDK (both server and agent). However, unless you need to provide more than 1Gb memory for TeamCity, the recommended approach is to use 32 bit JVM even under 64 bit OS. Our experience suggests that using 64 bit JVM does not increase performance a great deal. At the same time it does increase memory requirements to almost the scale of 2. See a Installing and Configuring the TeamCity server on memory configuration.

How do I set up deployment for my application in TeamCity

  1. Write a build script that will perform the deployment task for the binary files available on the disk. (e.g. use Ant or MSBuild for this)

  2. Create a build configuration in TeamCity that will execute the build script.

  3. In this build configuration configure Dependent Build on a build configuration that produces binaries that need to be deployed

  4. Configure one of the available triggers if you need the deployment to be triggered automatically (e.g. to deploy last successful of last pinned build), or use "Promote" action in the build that produced the binaries that need to be deployed. Consider using Dependent Build in addition to artifact ones and check Build Chain tab to get the overview of the builds.

  5. If you need to parametrize the deployment (e.g. specify different target machines in different runs), pass parameters to the build script using Triggering a Custom Build. Consider using Typed Parameters to make the custom run dialog easier to use.

  6. If the deploying build is triggered manually consider also adding commands in the build script to pin and tag the build being deployed (via sending a REST API Plugin request). You can also Share-the-build-number-for-builds-in-a-chain-build from the build that generated the artifact.

Integrating with Reporting/Metric Tools

If you have a tool that generates some report or provides code metrics, you may want to display the data in TeamCity.

The integration tasks involved are collecting the data in the scope of a build and then reporting the data to TeamCity so that they can be presented in the build results or in other ways.

Data collection The easiest way for a start is to modify your build scripts to make use of the selected tool and collect all the required data. For an advanced integration a custom TeamCity plugin can be developed to ease tool configuration and running. See XML Test Reporting and FXCop plugin (see a link on Open-source Bundled Plugins) as an example.

Presenting data in TeamCity For a report, the most simple approach is to generate HTML report in the build script, pack it into archive and publish as a build artifact. Then configure a Including Third-Party Reports in the Build Results to display the HTML report as a tab on build's results.

A metrics value can be published as TeamCity statistics via Build Script Interaction with TeamCity and then displayed in a Customizing Statistics Charts. You can also configure Build Failure Conditions based on the metric.

If the tool reports code-attributing information like Inspections or Duplicates, TeamCity-bundled report can be used to display the results. A custom plugin will be necessary to process the tool-specific report into TeamCity-specific data model. Example of this can be found in XML Test Reporting plugin and FXCop plugin (see a link on Open-source Bundled Plugins).

For advanced integration, a custom plugin will be necessary to store and present the data as required. See Developing TeamCity Plugins for more information on plugin development.

TeamCity Security Notes

These notes are provided only for your reference and are not meant to be complete or accurate in their entirety. TeamCity is developed with security concerns in mind and reasonable efforts are made to make the system not vulnerable to different types of attacks. However, the general assumption and recommended setup is to deploy TeamCity in a trusted environment with no possibility to be accessed by malicious users. Here are some notes on different security-related aspects:

  • man-in-the middle concerns

    • between TeamCity server and user's web browser: It is advised to Using HTTPS to access TeamCity server for the TeamCity server. During login, TeamCity transmits user login password in an encrypted form with moderate encryption level.

    • between TeamCity agent and TeamCity server: see Setting up and Running Additional Build Agents.

    • between TeamCity server and other external servers (version control, issue tracker, etc.): the general rules apply as for a client (TeamCity server in the case) connecting to the external server, see guidelines for the server in question.

  • user that has access to TeamCity web UI: the specific information accessible to the user is defined via TeamCity Role and Permission.

  • users who can change code that is used in the builds run by TeamCity: the users have the same permissions as the system user under which TeamCity agent is running. Can access and change source code of other projects built on the same agent, modify TeamCity agent code, etc. It is advised to run TeamCity agents under users with only Setting up and Running Additional Build Agents and use Agent Pools feature to insure that projects requiring different set of access are not built on the same agents.

  • users with System Administrator TeamCity role: It is assumed that the users also have access to the computer on which TeamCity server is running under the user account used to run the server process. Thus, some operations like server file system browsing can be accessible by the users.

  • TeamCity server computer administrators: have full access to TeamCity stored data and can affect TeamCity executed processes. Passwords that are necessary to authenticate in external systems (like VCS, issue trackers, etc.) are stored scrambled under TeamCity Data Directory and can also be stored in the database. However, the values are only scrambled, which means they can be retrieved by the users who have access to the server file system or database.

  • TeamCity agent computer administrators: same as "users who can change code that is used in the builds run by TeamCity".

  • Other:

    • TeamCity web application vulnerabilities: TeamCity development team makes reasonable effort to fix any significant vulnerabilities (like cross-site scripting possibilities) once they are uncovered. Please note that any user that can affect build files ("users who can change code that is used in the builds run by TeamCity" or "TeamCity agent computer administrators") can make a malicious file available as build artifact that will then exploit cross-site scripting vulnerability.

    • TeamCity agent is fully controlled by the TeamCity server: since TeamCity agents support automatic updates download from the server, agents should only connect to a trusted server. An administrator of the server computer can force execution of arbitrary code on a connected agent.

Restore Just Deleted Project

TeamCity moves settings files of deleted projects under /config/_trash directory. To restore project you should find its directory on the server and move it one level up. Also you should remove suffix _projectN from the directory name. You can do this while server is running, it should pick up restored project automatically.

Please note that TeamCity preserves builds history and other data for deleted projects/build configurations for 24 hours since the deletion time. The data id removed during the next cleanup after 24 hours timeout elapses.

Set Up TeamCity behind a proxying server

Internal TeamCity server should work under the same context as it is visible from outside by external address.

Provided: TeamCity server is installed at URL: teamcity.local:8111 It is visible to the outside world as URL: teamcity.public:400

Then use: for Apache

for Nginx

Alternative approach is to setup a proxying server to redirect requests to TeamCity server to a dedicated port and edit <TeamCity home>\conf\server.xml to change existing or add new Connector node:

<Connector port="8111" protocol="HTTP/1.1" maxThreads="200" connectionTimeout="60000" redirectPort="400" useBodyEncodingForURI="true" proxyName="teamcity.public" proxyPort="400" secure="false" scheme="http" />

(You will need to use secure="true" and scheme="https" for HTTPS)

This latter approach is also described in the comment.

Transfer 3 default agents to another server

This is not possible.

Each TeamCity server (Professional and Enterprise) allows to use 3 agents without any licenses. It's a "function" of a server: users do not pay for these agents, there is no license key for them, nor are they bound to the server license key.

So, these 3 agents cannot be transferred to another server as they are "bound" to the server instance.

Each TeamCity server allows to connect agents up to number of agent license keys +3

Configure newly installed MySQL server

If MySQL server is going to be used with TeamCity you should review and probably change some of its settings. If MySQL is installed on Windows, the settings are located in my.ini file which usually can be found under MySQL installation directory. For Unix-like systems the file is called my.cnf and can be placed somewhere under /etc directory. Read more about configuration file location in MySQL documentation. Note: you'll need to restart MySQL server after changing settings in my.ini|my.cnf.

The following settings should be reviewed and/or changed:

InnoDB database engine

Make sure you're using InnoDB database engine for tables in TeamCity database. You can check what engine is used with help of this command:

show table status like '<table name>';

or for all tables at once:

show table status like '%';

max_connections

You should ensure max_connections parameter has bigger value than the one specified in TeamCity <TeamCity data directory>/config/database.properties file.

innodb_buffer_pool_size

Too small value in innodb_buffer_pool_size can affect performance significantly:

# InnoDB, unlike MyISAM, uses a buffer pool to cache both indexes and # row data. The bigger you set this the less disk I/O is needed to # access data in tables. On a dedicated database server you may set this # parameter up to 80% of the machine physical memory size. Do not set it # too large, though, because competition of the physical memory may # cause paging in the operating system. Note that on 32bit systems you # might be limited to 2-3.5G of user level memory per process, so do not # set it too high. innodb_buffer_pool_size=2000M

We recommend to start with 2Gb and increase it if you experience slowness and have enough memory.

innodb_file_per_table

For better performance you can enable so called per-table tablespaces. Note that once you add innodb_file_per_table option new tables will be created and placed in separate files, but tables created before enabling this option will still be in the shared tablespace. You'll need to re-import database for them to be placed in separate files.

log files on different disk

Placing the MySQL log files on different disk sometimes helps improving performance. You can read about it in MySQL documentation.

Import coverage results in TeamCity

TeamCity comes bundled with IntelliJ IDEA/Emma coverage engines for Java and dotCover/NCover/PartCover for .NET. However, there are plenty of other coverage tools out there, like Cobertura, Jacoco and others which are not directly supported by TeamCity.

In order to achieve similar experience with these tools you can:

  • publish coverage HTML report as TeamCity artifact: most of the tools produce coverage report in HTML format, you can publish it as artifact and Including Third-Party Reports in the Build Results to show it in TeamCity. If published artifact name is coverage.zip and there is index.html file in it, report tab will be shown automatically.

  • extract coverage statistics from coverage report and publish Custom Chart to TeamCity with help of Build Script Interaction with TeamCity: if you do so, you'll see coverage chart on build configuration Statistics tab and also you'll be able to fail build with help of build failure condition on metric change (for example, you can fail build if coverage drops).

Last modified: 20 April 2023
REST API Troubleshooting