Child pages
  • Build Queue Priorities
Skip to end of metadata
Go to start of metadata

The plugin is bundled since TeamCity 6.0. The recent version is described in the online documentation for the latest TeamCity version.

General Info




Apache 2.0


free, open-source

Plugin Description

Plugin adds ability to set priority for build configurations.

Plugin Development Status

Production quality.

TeamCity Versions Compatibility

The current plugin version is designed to work with TeamCity 5.1 and later.
The plugin is bundled with TeamCity 6.0 EAP.


Directly from public TeamCity server: last successful build


Plugin introduces a concept of priority classes. Priority class allows you to associate certain priority (number in the range -100..100) with some build configurations.

Priority is only considered when build is added to the queue. The higher the priority of the priority class is, the more chances there are the build will be added at the top of the queue. Since builds with low priority should start too, one of the parameters affecting position of the newly added build, is the "time spent in the queue" of other builds. If some build has been waiting in the queue long enough, it won't be outrun even by a build with higher priority.

Note that there are built-in priority classes, which can't be removed. They have some "special" properties. For example, "Personal" class is used for personal builds (Remote run or Pre-tested commit) only, i.e. any personal build added to the queue will be assigned to this priority class.

There is also "Default" class. All of the builds not associated with any other class will be assigned to "Default" class. This allows to create a class with priority lower than default, i.e some low priority builds are always placed at the bottom of the queue.

Page to edit priority classes is available from Build queue page and can be accessed by users with System administrator role only.

Installation instructions

  1. Put into <TeamCity Data Directory>/plugins folder.
  2. Restart the server.

Algorithm details

Every time a new build is added to the queue, priorities of all the builds are recalculated and the new build is placed in the position i, such that

priority of build at position i-1 >= priority of new build > priority of build at position i+1 (i = 0 at the top of the queue).

We use the following formula to recalculate priorities of builds in the queue:

buildPriority = a * timeSpentInTheQueue / estimatedBuildDuration + b * buildConfigurationPriority

where a and b are configurable coefficients (internal properties teamcity.buildqueue.waitWeight and teamcity.buildqueue.priorityWeight respectively) with default values of 1.0. Changing the internal properties requires the server restart.

So when the build waits in the queue for amount of time equals to the estimated build duration, its priority increased by one. This helps lower priority builds to eventually start.

If you want the higher priority builds to be always placed closer to the top of the queue - set a = 0, but keep in mind that lower priority builds can starve, if there are always some higher priority builds to run.

If you want to run more of the faster builds you can set b = 0. In this case the faster build is, the faster its priority grows, so faster builds will likely to start sooner, but slower builds can starve.


If you believe you've faced a bug: Issue Tracker 
If you want to ask a question or discuss: Forum

Sources on GitHub

Issue in the tracker.


  • No labels