Build Features

Build features are optional add-ons configured under Build Configuration → Build Features → Add build feature. Multiple features can be active simultaneously. They are applied around the build steps without modifying them.

Already covered in Phase 5. Quick reference for configuration:

Covered in Phase 5. Additional configuration option not covered there:

Filter by target branch

Only build PRs targeting a specific branch. Enter branch patterns:

# Only build PRs targeting main or develop
refs/heads/main
refs/heads/develop

# Build PRs targeting any release branch
refs/heads/release/*

Filter by author role

Options: All (including forks), Members (org members only), Members and external contributors with write access. For public repos, use Members to prevent fork-based CI abuse.

JaCoCo integration instruments Java bytecode and reports line, branch, and method coverage. The coverage report appears in the build's Code Coverage tab and on the build overview as a percentage bar.

Maven setup

TeamCity injects JaCoCo agent into the JVM automatically when the JaCoCo build feature is enabled — no changes to your pom.xml required for basic coverage.

1. Add build feature: Code Coverage → JaCoCo.
2. Instrumentation classes: ** (all classes). Narrow to your source packages for accurate results: com/yourcompany/**.
3. Exclude: test classes, generated code: **/*Test*, **/*Generated*.
4. Coverage threshold (optional): fail build if line coverage drops below 80%.

Scans Java source files for duplicated code blocks. Reports are shown in the Duplicates tab of the build.

Runs IntelliJ IDEA's code inspections on the source — Checkstyle, PMD, FindBugs/SpotBugs, and IDEA's own inspections (unused imports, null pointer risks, etc.).

Alternative: Maven Checkstyle step

# Instead of IntelliJ inspections, use Maven Checkstyle runner:
# Build step: Maven runner
# Goals: checkstyle:check
# Fails build if violations exceed configured threshold

# Or inline in pom.xml:
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-checkstyle-plugin</artifactId>
  <configuration>
    <failsOnError>true</failsOnError>
  </configuration>
</plugin>

Replaces tokens in files before build steps run. Ideal for injecting the build number into version files, configuration files, or assembly info files. The replacement is applied on the agent's working copy — the original files in VCS are not modified.

Example: inject build number into version.properties

# File Content Replacer configuration:
File pattern:       src/main/resources/version.properties
Find what:          APP_VERSION=SNAPSHOT
Replace with:       APP_VERSION=%build.number%
Regular expression: No (literal text replacement)

Example: .NET AssemblyInfo.cs version injection

File pattern:       **/AssemblyInfo.cs
Find what:          \[assembly: AssemblyVersion\(".*"\)\]
Replace with:       [assembly: AssemblyVersion("%build.number%.0")]
Regular expression: Yes

The SSH Agent build feature starts an ssh-agent process on the agent and loads a specified key. Build steps can then make SSH connections (git push, rsync, ssh deploy) using that key without specifying credentials explicitly.

1. Upload a private key in Administration → <Project> → SSH Keys.
2. Add build feature: SSH Agent.
3. Select the uploaded key.
4. Build steps now have access to the key via the ssh-agent socket ($SSH_AUTH_SOCK).

# In a Command Line deploy step:
# No need to specify -i /path/to/key — ssh-agent handles it
rsync -avz --delete dist/ deploy@prod-server:/var/www/app/
ssh deploy@prod-server "systemctl restart app"

The Docker Support build feature handles Docker registry login/logout and optionally cleans up Docker images created during the build.

Setup

1. Add build feature: Docker Support.
2. Add a Docker registry: select from project connections or enter registry URL + credentials.
3. Enable Clean up pushed images (optional): TeamCity tracks images pushed during the build and removes them after the build completes. Prevents unbounded registry growth.

# With Docker Support feature active, build steps can use docker commands
# without logging in explicitly:

# Build step: Command Line
docker build -t registry.yourcompany.com/myapp:%build.number% .
docker push registry.yourcompany.com/myapp:%build.number%

# The Docker Support feature:
# 1. Runs docker login BEFORE steps (using stored credentials)
# 2. Runs docker logout AFTER steps
# 3. If cleanup enabled: removes the pushed image tag after build

Swabra detects files created during the build that are not part of the VCS checkout and removes them after the build. Prevents build pollution — if build A creates a temp file, build B (on the same agent) won't accidentally pick it up.

Collects CPU, memory, and disk I/O metrics on the agent during the build. Results appear in the build's Build Statistics charts. Useful for diagnosing builds that are getting slower over time.

No configuration required — just add the build feature and data is collected automatically at 3-second intervals during the build.

Shared Resources implement semaphore-style locking to prevent concurrent access to limited resources — a test database, a hardware device, a specific port on an agent, or an external API with rate limits.

Setup

1. Define the resource: Administration → <Project> → Shared Resources → Add resource. Name it (e.g., integration-test-db). Set a quota (max concurrent users: 1 for exclusive access).
2. Add build feature: Shared Resources to each build config that needs the resource.
3. Select the resource and lock type: Writeable lock (exclusive) or Readable lock (shared, up to quota).

When a build needs the resource, TeamCity waits in the queue until the resource is available. Only then is the build assigned to an agent.