You are viewing the documentation of TeamCity 10.x and 2017.x, which is not the most recently released version of TeamCity.
Go to the latest TeamCity documentation or refer to the listing to choose the documentation corresponding to your TeamCity version.

Skip to end of metadata
Go to start of metadata

This page lists the options to manage the queue builds manually. Automatic build queue optimization is detailed in the separate section.

On this page:

Manually Reordering Builds in Queue

To reorder builds in the Build Queue, you can simply drag them to the desired position.

Moving Builds to Top

  • For any queued build, do one of the following:
    • on the Build Queue page, click the arrow button next to the build sequence number  to move the build to the top of the queue.
    • click the build number or build status link anywhere in the UI, and, on the queued build page, click the Actions menu in the top right. Select the Move to top action. The queue position will change. For a composite build, the whole build chain will be moved to the top of the queue.
  • For a running composite build which has dependencies that have not yet started, click the build number or build status link anywhere in the UI, and, on the running build page, click the Actions menu in the top right. Select the Move queued dependencies to top action. All queued dependencies of this build will be moved to the top of the queue.

Managing Build Priorities

In TeamCity you can control build priorities by creating Priority Classes. A priority class is a set of build configurations with a specified priority (the higher the number, the higher the priority. For example, priority=2 is higher than priority=1). The higher priority a configuration has, the higher place it gets when added to the Build Queue.
To access these settings, on the Build Queue tab, click the Configure Build Priorities link in the upper right corner of the page.


Note that only users with the System Administator role can manage build priority classes.

By default, there are two predefined priority classes: Personal and Default, both with priority=0.

  • All personal builds (Remote Run or Pre-tested Commit) are assigned to the Personal priority class once they are added to the build queue. Note that you can change the priority for personal builds here.
  • The Default class includes all the builds not associated with any other class. This allows to create a class with priority lower than default and place some builds to the bottom of the queue.

To create a new priority class:

  1. Click Create new priority class.
  2. Specify its name, priority (in the range -100..100) and additional description. Click Create.
  3. Click the Add configurations link to specify which build configurations should have priority defined in this class.

This setting is taken into account only when a build is added to the queue. The builds with higher priority will have more chances to appear at the top of the queue; however, you shouldn't worry that the build with lower priority won't ever run. If a build spent long enough in the queue, it won't be outrun even by builds with higher priority.

Removing Builds From Build Queue

To remove build(s) from the Queue, check the Remove box next to the selected build and confirm the deletion. If a build to be removed from the queue is a part of a build chain, TeamCity shows the following message below comment field: "This build is a part of a build chain". Refer to the Build Chain description for details.

Also you can remove all your personal builds from the queue at once from the Actions menu.

Since TeamCity 10.0 it is possible to remove several builds of paused build configurations from the queue.

Limiting Maximum Size of Build Queue

It is possible to limit the maximum number of builds in the queue. By default, the limit is set to 3000 builds. The default value can be changed using the teamcity.buildTriggersChecker.queueSizeLimit internal property.

When the queue size reaches the limit, TeamCity will pause automatic build triggering. Automatic build triggering will be re-enabled once the queue size gets below limit. While triggering is paused, a warning message is shown to all of the users.

(info) While automatic triggering is paused, it is still possible to add builds to the queue manually.

See also:

Concepts: Build Queue

  • No labels

1 Comment

  1. Is there a way to prioritise personal builds for a particular project/build configuration over personal builds for other configurations? It seems all personal builds end up in the same priority class.