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

Table of contents

Reading Time: 5 minutes

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.

Prerequisite:

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: https://docs.docker.com/get-docker/.
The other requirement is Git with its configuration of username and email in our system. Please refer to these for understanding:

https://git-scm.com/downloads and https://docs.github.com/en/get-started/using-git
Once done, we are ready to go. We will be using the public GitHub repository provided by JetBrains (works for both Windows and Linux):
https://github.com/JetBrains/teamcity-docker-samples

Installation:

git clone https://github.com/JetBrains/teamcity-docker-samples
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

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: https://github.com/vaibhavkumar779/sbtAssignment
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.)

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

Version Control Settings:

Here we attach the root repository as source code for 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.

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 ) )

Triggers:

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.

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)

Dependencies:

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.

Conclusion

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:
https://blog.knoldus.com/ci-using-teamcity/
https://www.tutorialspoint.com/continuous_integration/continuous_integration_creating_project_teamcity.htm