Description

If jobs are added to Build Queue by starting them manually, they are added to the list in the required order (according to priorities). However, this is not the case when jobs are triggered automatically based on upstream/downstream relationship - they are re-sorted only after some observable timeout:

• If new job is added to Build Queue by triggering it from upstream one, the new job stays on top of Build Queue job list (the last to run) even if its priority is higher (priority number is smaller) than any other job in the Build Queue. Refreshing the main page continuously shows the same job list order.
• After some timeout, refreshing the main page finally re-sorts the job list in the Build Queue according to priorities.

In order to easily observe this behaviour, use quiet down mode ("Manage Jenkins" => "Prepare for Shutdown") to keep jobs in the Build Queue without running them.

Steps to reproduce

• Create 2 priority groups:
  high_priority_group (e.g. priority number = 3)
  low_prirority_group (e.g. priority number = 5)

• Create 3 jobs:
  low_a (priority = low_priority_group)
  high_b (priority = high_priority_group)
  high_c (priority = high_priority_group)

• Configure job high_c as downstream of high_b. In other words, when high_b competes, high_c is supposed to be started.

• Set quiet down mode ("Manage Jenkins" => "Prepare for Shutdown").

• Schedule both low_a and high_b jobs in any order manually. Build Queue will list low_a first and high_b second as expected (high_b to be run first). Refresh Jenkins main page to confirm this.

• Cancel quiet down mode for a while to get high_b job started. Set quiet down mode again to be able to see Build Queue sorting mode when high_c is triggered automatically.

• As soon as high_c is triggered automatically, it is first listed at the top of the Build Queue (in a wrong order) which says low_a is to be run first. Refresh Jenkins main page to confirm this.

• After a while refreshing Jenkins main page re-sorts jobs in the Build Queue to correct order.

The problem is that without quiet down mode, the low_a job with lower priority will start ahead of high_c job (which is triggered automatically by upstream high_b job).