Pipeline Optimization
TeamCity Pipelines employ a number of smart features that allow builds to avoid wasting precious time and resources on performing repeated actions. For example, if your Jobs are organized in a single "Job A → Job B" chain and "Job A" detects no new pending changes, "Job B" can reuse the last successful "Job A" build instead of triggering it anew.
![Optimizations overview Optimizations overview](https://resources.jetbrains.com/help/img/teamcity/pipelines/dk-optimizations-overview.png)
Pages with information on individual runs display information about currently enabled optimization features in their headers. You can click this block to view the impact of every feature on the overall run duration.
Reusing Jobs
If you build a Pipeline whose underlying VCS repository did not change since the last successful run, a Job will copy the results of its latest predecessor instead re-running all building tasks. This technique optimizes builds and allows TeamCity to skip builds whose results are already known.
![Reusing unchanged Jobs Reusing unchanged Jobs](https://resources.jetbrains.com/help/img/teamcity/pipelines/pipelines-reuse-overview.png)
The Optimizations settings section allows you to prevent Jobs from re-using their previous builds, even if no new commits are present. Turn off the Reuse Job Results switch for mission-critical Jobs that need to run fresh every time your pipeline starts.
![Job reuse Job reuse](https://resources.jetbrains.com/help/img/teamcity/pipelines/dk-job-reuse.png)
Parallel Tests
If your Steps initiate extensive test suites, which require a significant duration to finish, you can break these suites down into smaller batches and run each batch on its own agent. While this approach does increase the number of deployed agents, it can substantially accelerate the execution speed by as much as 75%.
![Parallel Tests slider Parallel Tests slider](https://resources.jetbrains.com/help/img/teamcity/pipelines/dk-parallelTests-slider.png)
To allow Steps to run their tests in parallel, navigate to the Optimizations section of Job settings and toggle on the corresponding option. The slider allows you to choose the number of batches and shows the potential performance profit.
Running parallel tests is supported by Maven and Gradle steps.
Sparse Checkout
If this Job setting is enabled, the Job utilizes the git sparse-checkout
command to limit the number of files downloaded with each checkout. The Job will track only folders specified as Steps' Working directories (see Step Settings) instead of the entire repository. This setting is useful for bulky monorepos that are too slow to clone.
Dependency Cache
Real-world applications often require retrieving dependencies from external sources (JAR files from Maven Central, NPM packages, GitHub Package Registry files, and others). The Enable dependency cache option allows TeamCity to cache these dependencies downloaded during the initial pipeline run. Subsequent runs can then reuse cached dependencies instead of re-downloading them, boosting the speed and cost-efficiency of your pipelines.
Cached dependencies are stored on the server as hidden artifacts, making them immediately available for subsequent runs regardless of which cloud agent builds the pipeline. However, it is worth noting that the scope of cached dependencies is limited to the parent Job. Jobs with the same dependencies do not benefit from caches produced by other Jobs, whether from the same or different pipelines.
Currently, this feature only supports the Maven build step. We expect to support other runners in the following release cycle.