Projects with same priority needs to build in the order they were entered into pending build queue. (Bug #209)

Added by Aldus Monitor over 4 years ago. Updated almost 3 years ago.

Status:New Start date:10/05/2012
Priority:Normal Due date:
Assignee:Daniel Nauck % Done:


Category:CCNet - Build Server Spent time: -
Target version:1.9
Affected version:1.5


Projects with same priority needs to build in the order they were entered into pending build queue.

  • Add a date/time entry to the item in the pending build que.
  • When something is triggered multiple time the queue should retain the original timestamp.
  • When selecting what to build make sure priority is first for order and then in FIFO order.
Extra feature:
  • Make a configuration setting to allow manually triggered tasks (CCTray or WebDashboard) to bypass pending build que. I.e. if many tasks are on the pending build queue then the manually triggered task should go infront of all other tasks that were triggered by other automatically triggers (like intervall trigger) but it should still be in order of priority and FIFO of other manually triggered tasks.


Updated by Ruben Willems about 4 years ago

  • Target version deleted (1.8.3)

Updated by Aldus Monitor over 3 years ago

I really would like to put my vote to get this fixed in either 1.8.4 or 1.9 because the problem we get when projects build in wrong order really makes a mess. Sometimes requiring us to redo a whole nightly build. Very difficult with around 50 project per server and with 3 servers.

Long description:

In the old mailing list I think there was a suggestion to a solution too. Just cant find it anymore.

Updated by Ruben Willems over 3 years ago

  • Target version set to 1.8.5

Updated by Ruben Willems over 3 years ago

did you have a look at Queue_Configuration
in that old example in the link you provided, what Q configuration was used?

Updated by Aldus Monitor over 3 years ago

I have the default setting on Duplicates attribute. I will change my to "ApplyForceBuildsReAdd" (since I do not have priorities today). During daytime when different teams use "force build" on their projects the first guy that hits "force build" must be first in queue even if his project has the lowest priority. That is why I must have all projects on same priority. During nightly build there is a dependency that must be maintained (where priorities might solve the problem). Duplicates attribute only lets you configure order of the same project triggered through force build, not different projects (I hope I am right?).

I expect it to be hard to reproduce the problem so I think the approach to solving this is to find in what case the order of trigging is lost.
Simple example that might be possible to following through the code. Imagine this scenario:
  • Project A has a long build time. Lets say 12h and it starts building at 01:00 (am).
  • Project B is triggered through interval trigger at 03:00
  • Project C is triggered through interval trigger at 06:00

Build order must now be A->B->C independent on the build length. All projects are same priority. Something in current code manages to make the build order be A->C->B sometimes (seemingly random).

I guess this must be through a sorting (non-stable) algorithm or a collection that is based on priority only (and not trigger-timestamp + priority). Maybe the "scramble" of the order is in it self caused by another event, I am hoping someone can find somewhere in the code where the order could be scrambled or reversed.

(In my real world case I usually get problems when projects build slower than expected and overlap in time. Normally most of projects are distributed so that the nightly build times do not overlap. I roughly have a configuration of maybe 20 projects triggered at 01:00 am. Then another 20 projects triggered at 05:00. First group must build before second group. If first group is slow one night then some of the second group projects ends up building before the first group.)

Updated by Aldus Monitor over 3 years ago

Is there any way I can help (except installing a new version which is difficult with my rather large setup)? Review some code?

Updated by Ruben Willems over 3 years ago

a patch would be great :-)

or a small config with something like batch programs that simulate the problem?
They may just contain a sleep or so

Updated by Ruben Willems almost 3 years ago

  • Target version changed from 1.8.5 to 1.9

Also available in: Atom PDF