TeamCity: Quick Installation And An Overview Of Build Configuration Of A Project

TeamCity logo
Reading Time: 5 minutes
Software logo

TeamCity is an On-Premises java-based CI/CD tool of JetBrains. It is available in two licenses: Enterprise and Professional and a Cloud version as well. Here we learn about its Build Configuration in a project.


We will be using docker image installation so it would be independent of the platform (i.e. Operating System) where used. So you may need docker installed in the system. Please refer to this site:
The other requirement is Git with its configuration of username and email in our system. Please refer to these for understanding: and
Once done, we are ready to go. We will be using the public GitHub repository provided by JetBrains (works for both Windows and Linux):


git clone
cd teamcity-docker-samples
cd compose-ubuntu #Windows:compose-windows

Set TeamCity version in .env file in current directory or folder (also could be ‘EAP’, or ‘EAP-nanoserver-2004’ for Windows). ( Currently it is ‘TEAMCITY_VERSION=2021.1’ )

docker-compose up -d
commands running on terminal in ubuntu

open http://localhost:8112/ in browser in Linux. In Windows, execute following in Powershell:
explorer ” http://$(docker inspect -f ‘{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}’ teamcitywindows_server_1):8111 ”
Now read and accept “Terms and Conditions” and create your user. Before you run any build in TeamCity authorise the agents provided by this repository by visiting “Agents -> Unauthorized”

Showing Agent page in TeamCity
Agents after you authorize them

Now Click Create Project.
In From a repository URL, add a public Repository, like:
then click Proceed.
Now after automatic configuration by TeamCity, again proceed.
(Note We are not explaining and skipping some steps as the focus is on build configuration only.)

Creating a simple project

Build Configuration:

General Settings:

This is about the general description of the Build consisting of:
Name: Name of the build
Build configuration ID: create an ID for that particular build, used in URLs, REST API, HTTP requests to the server, and configuration settings in the TeamCity Data Directory.
Description: describe the work and steps of the build.
Publish artefacts: convey the policy of artifact publishing: dependent on failure, success or none.
Artifacts paths: define the path in the directory to store the artifact

General Settings in Build Configuration
General Settings

Version Control Settings:

Here we attach the root repository for the source of the code that is to build.
Type of VCS: Git (most common, others like CVS Subversion, etc)
VCS root name: a unique name for VCS root to distinguish from other roots
VCS root ID: Similar to Build Configuration ID, VCS root ID is used in parameter references to VCS root parameters and REST API.
Fetch URL: to bring data from this repository.
Default branch: define the branch or tag that requires monitoring.
Branch Specification: if any more branch requires monitoring.
Authentication: Anonymous, Password/ access token, Private Key. ( depends on a repository being public or private)
Belongs to project: Project ID created at the start when created your project.

VCS root Settings
VCS Root Settings

Build Steps:

We configure the sequence of build steps for build configuration,
There are two ways: Auto-detect build steps ( TeamCity creates build steps automatically) and Add build steps ( manually add steps).
Runner type: The software or plugin required to run the software for the build. ( Our is scala file so Simple Build Tool (Scala))
Step name: to distinguish this from other steps if added.
Parameters: different in every case. ( for Scala:
SBT commands: clean compile test (default commands)
SBT installation mode: for Auto or Custom (version of sbt ) )

Build Steps Settings
Build Steps


They are caused to add a build after the occurrence of an event or a scheduled time.
VCS Trigger: events like push that bring changes VCS root.
Schedule Trigger: after a particular time for a particular time, can have a case of pending changes to trigger.
Finish Build Trigger: it means to start on Build B after Build A finishes, can have a case of success and failure with it where the build B may or may not affect build B.
Branch Remote Trigger: this adds a build to the queue whenever a particular branch has any changes.
Retry Trigger: used to again add this particular build in the queue after the last build unless specified to be on top in the queue.
NuGet Dependency Trigger: this is for the new NuGet package update only. ( Basically for Windows )
The Maven Triggers uses a checksum approach to find the change if the hash is the same as before then the build is not triggered otherwise triggered.
Maven Artifact Trigger: modification of the content is to be detected.
Maven Snapshot Trigger: modification of snapshot dependency is to be detected.

Triggers in Build Configuration

Failure Conditions:

In this, we define the conditions that lead to the failure of the build.
Fail build if:

  • it runs longer than specified limit in minutes ( 0 — unlimited )
  • one of build steps exited with an error (e.g non-zero exit code in command line runner)
    1. at least one test failed
      • support test retry: successful test run mutes previous test failure
    2. build runner logs an error message
    3. an out-of-memory or crash (Java only)
Failure Conditions
Failure Conditions


There are two dependencies: Artifact and Snapshot Dependency.

Snapshot Dependency: Snapshot dependencies are build chains. In a build chain, when all dependencies are built
, the build of this configuration will start only. This simply means that to start the build we need to complete a set of builds that are part of the same chain but come before so they are to be finished before.

For example, let’s say a chain of build A–>B–>C–>D and D has the snapshot dependency. The sequence A–>B–>C completes and then build D.

Artifact dependency: artifact is an outcome of a build like .jar file in the case of a maven file. So this dependency is about the outcome of one build for another build.

For example, let’s say build B: for running a docker file, would require to build A: to run docker build of image. So B is artifact dependent on A as well as Snapshot dependent as it cannot run without A output.

Dependencies of build configuration


After the above configuration in the project, click on run. This will take us directly to the build log page. The build configuration constituted more. Some are Build Features, Parameters and Agent Requirements. Since the aim was to cover a simple project, these were omitted. We need to experiment and explore to know more. I am providing references for this. For directly making a CI pipeline on Teamcity we can refer to:



Written by 

Explorer of new technologies: from DevOps to Web 3