Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

You are viewing documentation of TeamCity 5.x, which is not the most recent released version of TeamCity. Please refer to the listing to choose another version.
Search

Table of Contents

In this section:

Integrate with an issue tracker

You can turn issue ID references in change comments into links. Please see Mapping External Links in Comments for configuration instructions.

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:
Create a build configuration C and create snapshot dependencies A on C and B on C. Now when you have snapshot dependencies you can refer to the build number pattern of A and B to the build number of build C. Use the substitution pattern:

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.

More on 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

Assume, to run a build you need to use specific external tool to be installed on a build agent. To solve the problem, 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.

Install Multiple Agents on the Same Machine

See instructions at Setting up and Running Additional Build Agents.

Change Server Port

To change the server's port, in the <TeamCity Home>/conf/server.xml change the port number in the HTTP/1.1 connector:

To apply changes, you should restart server.

Make temporary build files erased between the build

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 directory before the build and deletes it right after the build.

Force creating System Administrator account

Since TeamCity 4.5
If there is no system administrator account in your current authentication scheme, to create one proceed as follows:

  1. access directly the following URL: http://<your_TeamCity_server>/setupAdmin.html
  2. create new account (it should not match any existing user account in the system) for the System Administrator role.

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

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 150Mb.

The server hardware requirements depend on the server load. The load on the server depends significantly on the type of the builds and server usage, so here are only some general guidelines.

The load on the server depends on:

  • the number of build configurations
  • the number of running builds
  • the number of builds in the history
  • the amount of data generated by the builds (size of the build log, number and output size of unit tests, etc.)
  • the number of agents
  • the number of users having TeamCity web pages open
  • the number of users logged in from IDE plugin
  • the number and type of VCS roots as well as checking for changes interval for the VCS roots

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

  • 60 projects and 300 build configurations, (with one forth being active and running regularly)
  • 50 build agents
  • 50 web users and 30 IDE users
  • 100 VCS roots (mainly perforce and subversion), average checking for changes interval is 120 seconds
  • the database (MySQL) is running on the same machine, main TeamCity process has -Xmx1100m -XX:MaxPermSize=120m JVM settings.

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.

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.