| << Back to previous view |
|
[QB-675] The build queue is inverted and fills up with confusing information now
|
|
| Status: | Resolved |
| Project: | QuickBuild |
| Component/s: | None |
| Affects Version/s: | 3.0.11 |
| Fix Version/s: | 3.0.12 |
| Type: | Improvement | Priority: | Major |
| Reporter: | Roger Perkins | Assigned To: | Unassigned |
| Resolution: | Fixed | Votes: | 0 |
| Remaining Estimate: | Unknown | Time Spent: | Unknown |
| Original Estimate: | Unknown | ||
| Description |
|
The build queue in 3.x now adds new builds to the start. I have a lot of configurations that are checked every 5 minutes for changes, these now go onto the front of the queue and very rapidly push the currently building jobs off onto the fourth page. Surely the new queue items should go on the end as they did in QB 2.x?
The build queue is also full now of what is very confusing items for my users. It seems the condition check for a configuration is now deffered until it makes it to the front of the queue, resulting in the queue filling up with dozens and dozens of entries that will ultimately do nothing and make it very hard to see what is actually scheduled to run in the queue. |
| Comments |
| Comment by Roger Perkins [ 14/Oct/10 11:13 AM ] |
| Is there a reason now why jobs are put onto the queue to have the build condition evaluated now rather than evalutating it before deciding to add to the queue? I had a job go wrong and block the queue for 7hrs overnight, it's still clearing the backlog and there's 840 odd jobs shown in the queue (compared to previously when you'd only see one's that had passed the build condition). If you've not even run the build condition check, at the very least you could collapse all the aggregate all of them items waiting on checking the build condition together. It still makes the queue look way busier than it actually is (and more scary) |