Adds the ability to assign different priorities to jobs, the lower the priority a job has, the sooner the job will run.
This can be very helpful, when one wants to add low priority jobs, but wants to have higher-priority jobs run first. This is especially true when hardware is limited, or when there are different groups of jobs that should share resources (equally).
The plugin is build around some basic concepts:
- Queue Strategy
- Job Group
- Job Inclusion Strategy, and
- Priority Strategy.
First, the Queue Strategy describes how the priority of a job is interpreted. It will translate the job's assigned priority to a corresponding weight in the queue. The queue is, then, sorted based on the assigned weight.
With the Priority Sorter, you will need to group your jobs into Job Groups. A Job Group's Job Inclusion Strategy decides whether a specific job should be included in the group.
The priority of the job is then set by the Priority Strategy, and each Job Group can have any number of priority strategies.
When a new job is queued, the following will happen:
- The Priority Sorter will go through the configured Job Groups
from top to bottom.
- When it finds a Job Group where the job is to be included, it
will look through the Priority Strategies from top to bottom
- When it finds a Priority Strategy that matches its criteria, it will use this strategy to assign a priority to the Job.
- When it finds a Job Group where the job is to be included, it
will look through the Priority Strategies from top to bottom
- The Priority Sorter will then consult the Queue Strategy to translate the priority to a weight, i.e. a position in the queue.
There are three included Queue Strategies, each of which will sort the Queue differently.
Each job will be assigned a priority, and, the lower the priority, the sooner the job will be run.
Each Job will be assigned a priority, but the queue will try to share the resources equally over different priorities in a round-robin fashion.
The same as Fair Queuing, but jobs with a lower priority will be run more frequently those with higher a priority. Remember, that the lower the priority assignment, the higher the importance.
This setting describes which jobs are included in a Job Group, and is relatively self explanatory. It is worth mentioning the "Jobs Marked for Inclusion" setting. When this is selected, you are requested to enter a name of the Job Group. This name will then be an available option on each job, providing an alternative "bottom-up" way to group jobs, rather than the default "top-down" approach of the other strategies.
It is possible to assign the priority, based on different Priority Strategies.
This setting describes what priority a job should have, and is self explanatory. It is worth mentioning the "Take the Priority from Property on the Job" setting. When selected, a drop-down - where you can select a priority - appears on all projects that would generate jobs to be included in this group.
The main configuration options are available on the Jenkins configuration page. Configuration options for Priority Strategy are available on its own page, accessible from the root actions menu.
On the main configuration page, you can select the number of priorities you would like to use, as well as a default priority to use where no other priority could be assigned.
Please note that lower number means higher priority! See details on
the screen regarding the specifics on each strategy.
On the main menu, you will find the link to a page where you can assign priorities to each Job
On this page you will be able to assign jobs to groups, and priorities to jobs.
Please note that all matching is done top to bottom by first match!
You can limit access to this functionality to administrators, by checking the appropriate check-box on the main configuration page.
If a job from a Run Exclusive job group gets started, jobs from other groups will remain blocked, and will not get executed until all jobs from the Run Exclusive job group are complete, regardless of priority.
Since a job can get a different priority each time it is started, the view column cannot show the "correct" priority for the Job.
The column will show the priority used the last time the job was launched, and, if the job has not been started yet, the column will show Pending.
Here's one way to use this plugin. The use-case is we have some parameterized jobs where we can only execute one run of each job at a time for business reasons, and each run can take a long time to execute. This means there can be a long queue of runs, even if we have executors available. Occasionally, there will be "urgent" runs that must execute next, without having to abort and re-queue existing runs. With this plugin, we can make it so that such runs will "jump the queue" and be scheduled ahead of other, lower-priority runs.
First, we must configure the plugin from the Jenkins configuration page.
Scrolling down to the Priority Sorter section, let's configure the Absolute strategy, with 5 levels of priorities and a default priority of 3. Let's also only let administrators configure job priorities by checking the Only Admins can edit job priorities checkbox:
Let's activate the Save button and move to the next part.
Next up we will configure the rules to make it possible for some runs to "skip the line" by letting users enter a priority level as one of the run's parameters. Runs with a parameter value that doesn't parse as an integer or without that parameter at all will get the default priority. Let's go to "Job Priorities" from the root actions menu.
First, we activate the Add button. We can provide a description for this Job group, but ours will be simple enough that it should not need one.
Next, we check the Use additional rules when assigning a priority to a job checkbox and activate its Add button.
Let's pick the Use Priority from Build Parameter strategy,
and we'll keep the default Build Parameter Name of BuildPriority:
We'll keep defaults for everything else and activate that Save button.
First off, the job(s) we will be modifying must already be parameterized
so that there's a difference between successive runs,
otherwise we have no way of distinguishing the runs,
and we therefore have no need for priorities.
For our example, we'll have a Pipeline job called Sequential
that users can queue when they have work that needs to be done on
a particular item.
As such, the job already has a ItemId parameter.
Let's add a BuildPriority parameter and we'll make it easy for our users
by using a "choice" parameter type, defaulting to the lowest priority.
Here's what our Pipeline script might look like:
properties([
disableConcurrentBuilds(), // "Do not allow concurrent builds"
parameters([ // "This project is parameterized"
// The job already had this parameter, to distinguish runs.
string(
name: 'ItemId',
trim: true,
description: 'The ID of the item to be processed.',
),
// We add this parameter to give higher-priority runs the
// ability to start sooner, ahead of lower-priority runs.
choice(
name: 'BuildPriority',
choices: ['5', '4', '3', '2', '1'],
description: 'Lower number means higher priority. ' +
'Runs with equal priority will execute in the order they were queued.',
),
]),
])
if (!env["ItemId"]) {
echo "No value provided for ItemId, nothing to do."
manager.buildNotBuilt()
return
}
node() {
// pretend we're doing work on the item with ID ItemId
sleep time: 1, unit: 'MINUTES'
}Let's pretend we have just created a new Sequential job with the
Pipeline script as above. Since it has never run before,
let's queue a run to configure the job for subsequent runs.
This will complete rapidly due to the early return.
Now that the job is aware of its properties (such as the parameters), we can queue some runs to test out our new priority scheme. Let's use the following parameter values and queue them quickly, so that we have queued all of them before run 2 finishes:
| ItemId | BuildPriority |
|---|---|
| Alpha | 5 |
| Bravo | 5 |
| Charlie | 1 |
| Delta | 5 |
| Echo | 1 |
After about 5 minutes, we can inspect the runs via their Parameters page to find out in what order they ended up running. Here's what we observe:
| Run | ItemId | BuildPriority |
|---|---|---|
| 2 | Alpha | 5 |
| 3 | Charlie | 1 |
| 4 | Echo | 1 |
| 5 | Bravo | 5 |
| 6 | Delta | 5 |
Run 2 started right away because there were no other runs in the queue to compete with. We then see that both high-priority runs executed in the order they were queued, followed by the two low-priority runs, also in the order they were queued.
This is exactly what we wanted!
Priority Sorter Plugin has support for use of Configuration as Code plugin.
To provide priority configuration follow below example:
unclassified:
priorityConfiguration:
jobGroups:
- id: 0
priority: 1
description: "Complex"
runExclusive: true
usePriorityStrategies: true
priorityStrategies:
- priorityStrategy:
id: 0
priorityStrategy:
userIdCauseStrategy:
priority: 1
- priorityStrategy:
id: 1
priorityStrategy:
upstreamCauseStrategy
jobGroupStrategy:
folderBased:
folderName: "Jenkins"
- id: 1
priority: 2
description: "Simple"
runExclusive: false
usePriorityStrategies: false
jobGroupStrategy: allJobsGlobal settings for priority sorter can be configured like this:
unclassified:
prioritySorterConfiguration:
onlyAdminsMayEditPriorityConfiguration: true
strategy:
absoluteStrategy:
defaultPriority: 3
numberOfPriorities: 5For more examples see tests resources.
In version 3.x, the option "Allow priorities directly on Jobs" has been removed in favor of the Priority Strategy "Take the priority from Property on the Job" (see above). Legacy Mode is removed (see above regarding upgrading from version 1.x).
Version 2.x is a complete rewrite of the plugin, but still supports
running in version 1.x compatibility mode. However if you are
satisfied with the functionality of 1.x, there is little point in
upgrading.
Upgrading from version 1.x to version 3.x will remove all
1.x configurations. Therefore, if you need to keep configured
values, upgrade to 2.x, first, switch to Advanced Mode, and then
upgrade from 2.x to 3.x.
To get some inside information on how, and why, a certain job gets a certain priority, you can turn on some extra logging.
- Logger: PrioritySorter.Queue.Items
- To get more info on the assigned priorities, and state transition of the items in the queue, set the log level to FINE.
- To get more info on how the jobs are matched to job groups, and rules to get the priority, set the log level to FINER.
To get logging on when the Queue Sorter is active, use:
- Logger: PrioritySorter.Queue.Sorter, with the level set to
FINE.
- To see all items sorted (the queue) by the Queue Sorter, set the log level to FINER.
- For recent versions, see GitHub Releases
- For versions 3.6 and older, see the changelog archive
Please report issues and enhancements through the Jenkins issue tracker.