TeamCity Pipelines Help

Pipelines 101: Common Concepts and Settings

This section outlines the main enhancements and differences Pipelines exhibit compared to the classic TeamCity UI, and explains core concepts and terms.

Common Terms

In Pipelines, any CI/CD routine consists of three logical blocks:

  • Step — a simple build action an agent performs, such as testing a Maven solution, executing a CLI script, or building a Gradle project. Steps are not standalone entities and always have parent Jobs.

  • Job — a sequence of consecutively executed Steps. These are "build configurations" in classic TeamCity terminology.

  • Pipeline — a sequence of Jobs executed either consecutively or in parallel. Jobs united in a Pipeline can share output files. Multi-Job Pipelines are counterparts to classic TeamCity "build chains".

Supported VCS and Project Types

Supported version control systems:

  • GitHub

Supported project types:

  • Gradle

  • Maven

  • NodeJS

  • Custom Command-Line Scripts

Initial Setup

When you navigate to the Pipelines tab for the first time, TeamCity asks you to approve the OAuth access to GitHub. TeamCity uses this authorization method to scan for repositories in your personal account, as well as repositories of your organization(s). You can create Pipelines only for these found repositories.

You can revoke TeamCity’s access to GitHub at any time. To do this, visit the Settings | Applications | Authorized OAuth Apps page.

YAML Configuration

TeamCity stores all Pipeline, Job, and Step settings in an .yml file. You can click Preview YAML button in the top right corner to browse this file.

A YAML configuration file allows you to quickly view, validate, and share the hierarchy of your Pipeline with all of its Jobs, Steps, and individual settings. We are currently working on making this file editable, so that settings you add in a YAML configuration are reflected in the web UI.

Reusing Builds

If you run a Pipeline whose underlying VCS repository did not change since the last successful build, TeamCity will use those last successfully built Jobs instead of re-running them. This technique optimizes builds and allows TeamCity to skip builds whose results are already known.

Reusing unchanged Jobs

In future releases, we intend to add Job settings that will allow you to force TeamCity do a fresh Job run even if there are no changes.

Last modified: 10 March 2023