Pipeline Settings

Edit Pipeline Settings

To view and edit core pipelines settings, click the Settings toggle in the top right corner, then click anywhere within the pipeline canvas area surrounding the jobs in the visual editor.

You can also switch from the visual editor to the code and edit the markup directly.

Parameters

Parameters are name-value pairs designed to substitute raw values with references. When TeamCity encounters a parameter reference (%param-name%), it substitutes it with the actual parameter value.

TeamCity supports two layers of parameters: pipeline parameters and job parameters.

• Pipeline parameters are designed to be accessible from any individual job owned by this pipeline.

  jobs: Job1: name: Job 1 steps: - type: script script-content: echo %pipeline-param1% Job2: name: Job 2 dependencies: - Job1 steps: - type: script script-content: echo %pipeline-param2% parameters: pipeline-param1: foo pipeline-param2: bar

  Typically, these are configuration parameters (without the env. name prefix) most commonly used to store values used by multiple jobs, or quickly alter global pipeline settings.

• Job input parameters are typically environment variables (with the env. name prefix) available only for this specific job. To pass this value to another job, you need to reference them inside an output parameter.

The sample below shows a pipeline-level secret parameter bearer_token and a job-level environment variable env.SERVER_URL used inside a command-line step. Note that parameters with the env. prefix can be referenced via the regular TeamCity %param_name% syntax or accessed in scripts like native agent variables ($param_name).

Secrets

Secrets are protected parameters designed for storing sensitive data. You can reference in the same manner as with regular parameters, but their actual values are hidden from both TeamCity UI and build log.

If you switch to the code view of a pipeline, you will notice that secret values are replaced by names of tokens that store these values. TeamCity automatically creates these tokens to avoid leaking secret data via remotely stored configuration files.

The snippet below illustrates a secret that can be used instead of a password in the Integrations section of a pipeline. The command-line script that attempts to expose this secret prints the "Secret value: *******" line to the build log.

Auto-Run Pipeline

This section includes settings that allow TeamCity to automatically run your pipeline on certain conditions. This functionality is available as triggers.

On New Changes

These settings trigger new pipeline runs whenever TeamCity detects new changes in a repository. In classic TeamCity build configurations, similar functionality is available via VCS triggers.

Trigger settings define which changes should start a new run. Use the Branches toggle to select stable repository branches. In the example below, TeamCity runs the pipeline automatically only when changes are committed to the "production" branch.

The Pull requests toggle includes pull request branches (for example, GitHub refs/pull/ branches) to the list of available sources. Note that you can enable this option only when a pipeline tracks these pull request branches (see the Repository section).

On a Schedule

These settings, similar to a classic build configuration’s schedule trigger, let you define a date-time pattern for when TeamCity should run the pipeline.

Repository

The Repository section lets you check out multiple repositories during a pipeline run. TeamCity retrieves sources from all added repositories, even if no jobs are configured to process them.

The initial repository entry, created automatically with the pipeline, is called the main repository. It cannot be deleted and includes an extra YAML file storage selector.

Repository URL and source

Core repository settings that allow you to choose which repository a pipeline should check out.

Disabled for main repositories.

Default branch and branch specification

These settings define which branches TeamCity tracks. Untracked branches are completely ignored: they do not report changes to the server, you cannot run for these branches, and so on.

See the following classic build configuration articles to learn more about branch specification syntax: Common Specification Syntax and Default Branch.

Pull requests

When this setting is enabled, TeamCity includes pull (merge) request branches in the branch selector on the main pipeline page.

You can also enable the related toggle of the "On new changes" trigger to have TeamCity automatically build incoming pull requests.

YAML storage

Specifies where to store the pipeline YAML configuration: on the TeamCity server or in the source repository. See also: Storing Project Settings in Version Control.

These settings are available for main repository only.

Publish status to repository

If this setting is enabled, TeamCity reports pipeline run statuses (running, successful, failed) to the VCS hosting provider. The following image illustrates how GitHub presents this information.

For classic build configurations, this functionality is available as the Commit Status Publisher build feature.

Each individual job can choose which of the pipeline repositories it will check out. See the following article for more information: Job Settings.

Integrations

Both pipeline and job settings panels include an Integrations section for connecting to private Docker and NPM registries.

• In the pipeline settings, you manage the full list of available integrations for jobs.

• In job settings, toggles let you select which registries the job should log in to automatically, ensuring build steps can access the required data.

Classic TeamCity build configurations support this functionality via the "connection + build feature" combinations:

• Docker Registry connection and Docker Registry Connections build feature for Docker.

• NPM Registry connection and the related build feature for Node.js registries.