Plugin adds ability to set priority for build configurations.
Plugin Development Status
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.
<TeamCity Data Directory>/pluginsfolder.
- Restart the server.
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
b are configurable coefficients (internal properties
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.
Sources on GitHub
Issue in the tracker.