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.
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.
Currently, there's not option force a Job to re-run its tasks even if no new changes were found. We plan to add this feature in future release cycles.
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%.
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.