TeamCity Pipelines Roadmap

Integration with build chains

Build chains allow you to link build configurations in a single workflow.

We expect to integrate build chains in the pipeline experience in two ways:

• Provide the ability to link pipelines with build configurations. This will allow you to keep using existing building routines in tandem with lightweight pipelines.

• Support linking multiple pipelines in a single build chain.

Kotlin DSL Support

Both pipelines and build configurations support configuration-as-code, but they use different formats: pipelines use YAML, while build configurations rely on Kotlin DSL.

Each approach has its strengths. YAML is widely used and familiar, while Kotlin DSL offers the flexibility of a full programming language, including extending standard types with custom functionality, creating objects at runtime.

As we work toward making pipelines a complete solution for any CI/CD task, our goal is to give you the best of both worlds. Bringing Kotlin DSL to pipelines will make it easier to use versioned settings and choose the approach that best fits your workflow.

Custom Runs

Running custom builds is a great way to trigger a tailored build sequence without changing configuration settings. You can schedule a build, pick a specific agent, override parameters, skip dependencies, and more.

We expect to support a similar functionality in pipelines.

Job-level Build Features

Build features enhance build configurations with advanced capabilities: from simple cleanup with Swabra to Matrix builds that spawn dozens of virtual builds cycling through the predefined set of parameters. Our plan is to bring the most widely used features to pipelines.

As with other configuration-only features, we aim to support what matters without cluttering pipelines with rarely used options. Your feedback is essential here: reach out via Slack or our issue tracker to help us prioritize the features that matter most.

More Build Steps

TeamCity 2025.11 introduces .NET build steps: one of many step types previously available only in classic build configurations.

More steps are on the way, but as with build features, we want to focus on what users truly need. Our research shows that while many appreciate specialized steps, the universal Command Line (Script) step remains the most commonly used. To keep pipelines simple and approachable, we aim for quality over quantity and would greatly appreciate your feedback.

Let us know which steps you’d like to see next — Python, PowerShell, Xcode Project, or anything else — so we can prioritize them for future releases.

.NET Build Steps

In version 2025.11, we're bringing the familiar .NET build step to pipelines. Instead of one single step with dozens of settings that depend on the selected step command, pipelines split this build step into a series of task-specific units.

See the More Build Steps section for more information on other steps currently available only in build configurations.

Learn more: .NET.

Project Registry Connections Support

Starting with version 2025.11, Docker and NPM connections owned by projects are available as integrations in pipeline and job settings.

Learn more: Pipeline Settings.

Advanced Build and Test Actions

Starting with version 2025.11, pipelines support some of advanced features that was previously available only in build configurations. Users can now process build and test failures: assign investigations, mute irrelevant failures, and manually label as fixed issues that are expected to be resolved in future builds.

In addition, the run actions menu now includes options to pin, tag, and comment individual pipeline runs.

Learn more: Working with Build and Test Failures, Main Actions on Builds

Parameter Import

Previously, a parameter owned by a project could not be used inside pipelines. Referencing such parameters would result in an implicit agent requirement: only agents that provide a value for this parameter were eligible to run this pipeline.

Starting with version 2025.11, you can import any parameter from a direct or indirect project and use it as any other native pipeline parameter.

Learn more: Pipeline parameters, Configuring Build Parameters

Job Failure Conditions

We plan to introduce failure conditions similar to those in build configurations. This will give you finer control over when a job is marked as failed and allow downstream jobs to run even if earlier ones fail.

Execution Timeouts

We’re exploring timeout settings that let you define maximum run durations. Jobs or pipelines that exceed the threshold would be automatically canceled and marked as failed.

Recipes Support

Recipes complement custom build steps by letting you package commonly used logic into reusable assets and download community-created steps from JetBrains Marketplace. Adding recipe support would greatly expand what pipelines can do.

Build Step Conditions

Classic build configurations support step execution conditions that specify criteria for when a step should run. We plan to add a similar feature for steps inside pipeline jobs.

Typed Parameters

Pipelines currently support only single-value text parameters (including masked secret parameters for sensitive values). We aim to implement more parameter types available in classic build configurations, such as checkboxes, multi-selects, and values pulled from external sources.

Templates

Templates help configure multiple build configurations that share similar settings. We plan to bring an equivalent concept to pipelines, enabling you to define reusable YAML templates.

VCS YAML Recognition

You can already save pipeline settings to a repository. Next, we want TeamCity to do the opposite: detect pipeline YAML files in supported VCS hosts (GitHub, GitLab, Bitbucket, and so on) and automatically create pipelines from them.