Managing Jobs

Creating a job

Create a new build configuration in a project. The parent project comes from --project, the TEAMCITY_PROJECT environment variable, or the linked project (see Linking):

By default TeamCity derives the job ID from the name. Set an explicit ID with --id, or base the new job on an existing template with --template:

Add --web to open the new job in your browser, or --json for machine-readable output.

Listing jobs

List build configurations across all projects. Jobs backed by pipelines are hidden by default — pass --all to include them:

Filter by project:

Limit the number of results (use --limit 0 to fetch all):

Output as JSON:

Viewing job details

View details of a build configuration:

Open the job page in your browser:

Output as JSON:

Dependency tree

Visualize the snapshot dependency chain for a job. By default, the tree shows both dependents (what gets triggered after this job) and dependencies (what must run before this job):

Show only one direction:

Limit the tree depth:

Managing build steps

Build steps are the individual runners a job executes in order. List the steps on a job:

View one step's full configuration, including its parameter keys:

Add a step. --type is the runner type ID used by TeamCity's REST API, which differs from the display name in the UI — Command Line is simpleRunner, Gradle is gradle-runner, Maven is Maven2. Repeat --param key=value for each runner setting:

Delete a step by its ID:

Pausing and resuming jobs

Pause a job to prevent new builds from being triggered:

Resume a paused job to allow new builds:

Managing job parameters

Managing job settings

Settings are the build-configuration options that control how a job runs — build number format, execution timeout, artifact rules, and similar. Unlike parameters, settings always have server defaults and cannot be deleted.