APPENDIX — REFERENCE CARDS

TeamCity 2017.2.2 Reference Cards

Your cheat-sheet companion for the entire series: top gotchas, all runners, predefined parameters, branch-spec patterns, REST API endpoints, Jenkins comparison, and naming conventions

ReferenceCheat SheetQuick ReferenceREST API

🎓 Series Complete

You've covered all 15 phases of TeamCity 2017.2.2. Use this appendix as your daily reference while working with TeamCity in production.

A.1 — Top 20 TeamCity Gotchas #

1
Agent not appearing after install

The agent registers itself but must be authorized manually in Administration → Agents → Unauthorized. Until authorized it will never pick up builds.

2
Artifact path uses wrong separator

Artifact paths always use forward slashes / even on Windows agents. Backslashes silently produce no artifacts.

3
Branch spec missing +: prefix

Every branch pattern must start with +: (include) or -: (exclude). A bare refs/heads/* with no prefix is invalid and monitors nothing.

4
Default branch not in branch spec

+:refs/heads/* does NOT include the default branch unless the default branch is under refs/heads/. Add +:refs/heads/main explicitly or verify.

5
Dependency parameter syntax typo

Cross-build parameters use dep.<ExternalID>.param. The external ID is case-sensitive and includes the project prefix. A single wrong character means the parameter stays blank with no error.

6
HSQL database in production

The bundled HSQL database is development-only. It does not support concurrent writes and corrupts under moderate load. Always migrate to MySQL or PostgreSQL before going live.

7
Password parameters logged in plain text

Only parameters whose type is explicitly set to Password are masked in logs. A system property or env var named env.SECRET will still print in full unless its type is Password.

8
Agent requirement mismatch silently queues forever

If no agent satisfies a build's requirements the build sits in the queue forever with a "No compatible agents" note in small text. Always check agent compatibility before wondering why a build won't start.

9
Artifact dependency on "latest successful" vs same chain

Artifact dependency set to "latest successful build" will pick an artifact from a different chain run. Use "build from the same build chain" to guarantee you're testing the exact artifact you just built.

10
VCS Trigger quiet period not set

Without a quiet period, every single commit in a multi-commit push fires a separate build. Set a 60–120 second quiet period to batch commits from the same push into one build.

11
Build counter not reset after project copy

When you copy a build configuration the build counter continues from where the source left off. Reset it to 1 in General Settings if you want the new config to start from build #1.

12
Clean checkout wipes agent work directory every build

Enabling "Clean all files before build" means full VCS checkout every time — safe but slow. Use it only for release builds; leave it off for developer feedback builds.

13
Composite builds don't run steps

A composite build configuration is purely an aggregation node — it can have snapshot dependencies and parameters but no build steps. Adding steps to a composite config has no effect.

14
Template detach loses overrides silently

Detaching a build configuration from its template embeds the current state, but any parameters or steps that were identical to the template are not highlighted. Review all settings after detaching.

15
Kotlin DSL requires a round-trip to activate

Enabling Versioned Settings with Kotlin DSL does not immediately export existing config. You must commit the generated XML first, then migrate to Kotlin — skipping the XML step causes a blank config import.

16
REST API calls without Accept header return XML

TeamCity defaults to XML responses. Add Accept: application/json to every API request or you'll parse XML instead of JSON. The Content-Type: application/json header is also required for POST bodies.

17
JVM heap too small on server startup

The default 750 MB heap is insufficient for large installations. On a server with 50+ projects and 500+ builds/day, increase -Xmx to at least 2–4 GB in TEAMCITY_SERVER_MEM_OPTS.

18
SSH Agent feature doesn't forward to sub-processes

The SSH Agent build feature forwards the key to the agent JVM process but not to child processes spawned via shell scripts unless you explicitly eval the agent socket in the script.

19
Shared Resource lock not released on build cancel

In some 2017.x versions, cancelling a build while it holds a Shared Resource lock can leave the lock held until the next build finishes. Monitor the Shared Resources page if builds queue unexpectedly.

20
Notification rules don't fire for personal builds by default

Notification rules apply to regular builds. Personal (pre-commit) builds only notify the build's owner unless you explicitly check "My personal builds" in the notification rule.

A.2 — All Runner Types Quick Reference #

RunnerLanguage / PlatformKey Settings
MavenJavaGoals, POM path, JVM options, user settings XML
GradleJava / KotlinTasks, Gradle wrapper, build file, init scripts
AntJavaBuild file, targets, JVM options
IntelliJ IDEA ProjectJava / KotlinProject path, build configuration (for inspections)
MSBuild.NET / C#Build file, targets, MSBuild version, platform
.NET CLI.NET CoreCommand (build/test/publish), project, args
Visual Studio (sln).NET FrameworkSolution file, VS version, configuration/platform
Command LineAnyExecutable or script content, working directory
PowerShellWindowsEdition (Desktop/Core), version, script file or content
PythonPythonPython executable, script, environment
RakeRubyRuby interpreter, Rakefile, tasks
FTP UploadDeploymentFTP host, credentials, source/target paths
SSH ExecDeploymentHost, credentials, commands to run remotely
SSH UploadDeploymentHost, credentials, source/target paths (SCP)
Duplicates Finder (Java)Java analysisSource directories, threshold, exclusions
Duplicates Finder (.NET).NET analysisSource pattern, threshold
Inspections (IntelliJ)Java/Kotlin analysisProfile XML, failure conditions
NUnit.NET testingNUnit version, assemblies, run type
MSTest.NET testingTest file, test names, VS version
NAnt.NET buildBuild file, targets, NAnt home
DockerContainersSubcommand (build/push/other), image name, Dockerfile

A.3 — Predefined Build Parameters Cheat Sheet #

Build Identity

ParameterExample ValueDescription
build.number42Current build number (auto-incremented counter by default)
teamcity.build.id12345Unique internal build ID (never reused)
teamcity.buildType.idMyProject_BuildExternal ID of the build configuration
teamcity.projectNameMyProjectName of the containing project
teamcity.buildConfNameBuildName of this build configuration

VCS / Branch

ParameterExample ValueDescription
build.vcs.numbera3f8d12VCS revision (commit SHA / SVN rev)
teamcity.build.branchrefs/heads/mainFull branch ref being built
teamcity.build.branch.is_defaulttruetrue when building the default branch
teamcity.pullRequest.number47PR number (set by Pull Request build feature)
teamcity.pullRequest.titleFix login bugPR title (set by Pull Request build feature)

Agent

ParameterExample ValueDescription
agent.namelinux-agent-1Name of the agent running this build
agent.home.dir/opt/teamcity-agentAgent installation directory
agent.work.dir/opt/tc-agent/workAgent working directory root
agent.tools.dir/opt/tc-agent/toolsAgent tools directory (JDKs, etc.)
system.agent.home.dir/opt/tc-agentSame as agent.home.dir as a system property

Timing

ParameterExample ValueDescription
build.start.date20260612T093045+0530Build start timestamp (ISO 8601)
teamcity.serverUrlhttp://tc.company.com:8111TeamCity server URL (useful for notification scripts)

A.4 — Branch Specification Cheat Sheet #

Each line is +: (include) or -: (exclude) followed by a pattern. The logical branch display name is in (*).

+:refs/heads/*Include all branches under refs/heads/; display name = branch name (e.g. main)
+:refs/heads/mainInclude only the main branch
+:refs/heads/release/*Include all release/x.y branches
-:refs/heads/wip/*Exclude all WIP branches (combine with a broader include above)
+:refs/pull/*/headInclude all GitHub pull request head refs (requires PR build feature)
+:refs/tags/*Include all tags (useful for release builds)
+:refs/heads/(*)Include all branches; display name is captured by (*) — strips refs/heads/ prefix
+:refs/pull/(*/head)Include PRs; display name shown as 47/head
+:refs/heads/feature-*Include branches matching feature- prefix (glob-style, no capture)
-:refs/heads/dependabot/*Exclude Dependabot auto-update branches
Rule: Exclude rules always win over include rules when both match a ref. Ordering within includes/excludes doesn't matter — the most-specific match wins.

A.5 — REST API Quick Reference #

Base URL: http://<server>:8111/app/rest — Add -H "Accept: application/json" to every curl call.

Projects

GET/projects
List all projects
GET/projects/id:MyProject
Get a single project by external ID
POST/projects
Create a project (JSON body: {"name":"…","parentProject":{"id":"_Root"}})

Build Types

GET/buildTypes
List all build configurations
GET/buildTypes/id:MyProject_Build
Get a single build configuration

Builds

GET/builds?locator=buildType:MyProject_Build,branch:main,count:10
Last 10 builds on main for a specific config
GET/builds/id:12345
Get build by internal ID
POST/buildQueue
Trigger a build
curl -X POST http://tc:8111/app/rest/buildQueue \ -H "Content-Type: application/json" \ -H "Accept: application/json" \ -u admin:password \ -d '{"buildType":{"id":"MyProject_Build"}}'
PUT/builds/id:12345/tags/
Add a tag to a build
PUT/builds/id:12345/pin
Pin a build (prevent cleanup)

Artifacts

GET/builds/id:12345/artifacts/content/app.jar
Download a specific artifact file
GET/builds/id:12345/artifacts/children
List artifact root children

Agents

GET/agents?locator=authorized:true
List all authorized agents
PUT/agents/id:3/authorized
Authorize an agent (body: true, content-type: text/plain)

Test Results

GET/testOccurrences?locator=build:id:12345,status:FAILURE
Get failed tests for a build

A.6 — TeamCity vs Jenkins Feature Comparison #

FeatureTeamCity 2017.2.2Jenkins (LTS)Edge
Setup / UI Wizard-driven, polished web UI, no plugin hunting for basics Bare after install; plugins required for almost everything TC
Build configuration GUI form-based; Kotlin DSL optional Jenkinsfile (Groovy DSL) — code-first Tie (depends on preference)
Build chains / pipelines First-class: snapshot + artifact dependencies, chain visualization Pipeline plugin; multi-stage but no built-in chain visualization TC
Agent management Built-in pools, requirements matching, auto-upgrade Nodes/labels; agent management via plugins TC
Test reporting Built-in: pass/fail trend, flaky test detection, history JUnit plugin; decent but no flaky test detection built-in TC
Plugin ecosystem ~100 official plugins; smaller community 1,800+ plugins; huge community Jenkins
Infrastructure as code Kotlin DSL (strong typing, IDE support) Jenkinsfile (Groovy; widely adopted, more examples) Jenkins (ecosystem)
Cost Free up to 3 agents + 100 build configurations; paid tiers beyond Open source, free always Jenkins
Security (built-in) Role-based, 2FA (2017.2), project-level isolation, audit log Role Strategy plugin needed; security is add-on TC
REST API Comprehensive, well-documented, stable versioning Available but less consistent; JSON by default Tie
Hosted / cloud option TeamCity Cloud (JetBrains hosted) CloudBees CI (paid); no official JetBrains equivalent Tie

A.7 — Recommended Project Structure & Naming Conventions #

Project Names

Use PascalCase matching the repo or team name: OrderService, FrontendApp
Prefix environment-specific sub-projects: OrderService / Production, OrderService / Staging
Don't use slashes or special characters in project names — they break external IDs

Build Configuration Names

Use verb-noun pattern: Build, Test Unit, Test Integration, Package, Deploy Staging, Deploy Production
Prefix with environment when a project has multiple deployment targets: Staging / Deploy
Template names: prefix with TPL_ — e.g. TPL_MavenBuild, TPL_NodeTest

VCS Root Names

Pattern: <Org>/<Repo> (branch) — e.g. myorg/order-service (main)
For shared VCS roots at project level, use just <Org>/<Repo>

Parameter Names

Config parameters: env.prefix.name — e.g. deploy.s3.bucket
System properties: system.maven.opts
Environment variables: env.JAVA_HOME, env.DOCKER_REGISTRY
Password parameters: suffix with .secret or .password as a visual cue

Agent Pool Names

Name by capability: Linux-Java11, Windows-DotNet6, Docker-Privileged
One pool per environment tier when agents have different secrets or network access: Production-Deploy

Artifact Path Conventions

Always use forward slashes: target/*.jar => artifacts
For multi-module projects, include module name: order-service/target/*.jar => artifacts/order-service
Test reports to a fixed path so downstream builds and the REST API can find them: **/surefire-reports/*.xml => test-reports

Series Complete — Well Done!

You've finished all 15 phases and the appendix. Return to the hub to review any phase or share the series with your team.

Back to TeamCity Hub ← Phase 15: Advanced