FinalBuilder Server runs an internal build queue to control when a build starts running, when a build should be re-queued and when a build should not be started at all.
The following flowchart illustrates the logic used to determine this process:
1. Replace Queued Builds
When configuring a trigger, you can decide whether you want to replace any existing builds of the same project that are currently on the build queue. This feature allows you to make sure that a trigger does not queue multiple builds up for the same project.
2. Remove Existing Builds
All builds that are for the same project as the one being started are removed from the build queue.
3. Trigger has Initial Delay
When configuring a source control trigger, you can specify a 'Quiet Period' that will force the build to start with an initial delay. This has the benefit of allowing you to check-in multiple files within in the specific time span without triggering a build for each check-in. If the build is already on the queue and the trigger triggers the build again, the delay will be reset to the value of the initial delay.
4. Bypass Build Queue
Occasionally a user will need to start a build instantly, without requiring that all conditions are met and without checking to make sure the maximum number of concurrent builds are running. When this happens the entire build queuing process is avoided and the build is started immediately (as long as its not already running). The user is prompted for this option whenever a build is started manually.
5. Build Queued
At this stage, the build is placed on the queue and will continue to wait there until the build delay has been reached.
6. Build Delay Reached
Each build on the queue has a value to indicate how long it should wait on the build queue before FinalBuilder Server attempts to start it. When the delay has been reached, the project is checked to see if it currently suspended then the build conditions are evaluated.
7. Project is Suspended
Users may decide that a project should not be started regardless of any builds conditions, this may be because they are working on the FinalBuilder project file or they are working on the machine hosting the build server. While a project is suspended it will continue to wait on the build queue until the suspension is removed or expires.
8. Build Conditions Evaluated
Each project can define a set of conditions which are tested each time the build queue attempts to start the project. Each of the conditions defined specifies whether the build should be discarded or whether it should be re-queued and how long it should be re-queued for. The build queue will test all conditions currently active on the project and for each condition that has not been met, will choose the condition that has the most impact on the build. Conditions that force the build to be discarded are considered to have the most impact on the build, and the rest are sorted by the length of the time the build delay will be increased.
9. Concurrent Build Limit Reached
A build server can specify the maximum number of concurrent builds that can be running at any one time on the configuration page. The maximum number of concurrent builds is not checked until after the conditions have been evaluated so that builds may still be discarded from the queue, which can help to free up the build server in the future.
10. Discard Builds
When a build condition is configured to discard the build and the condition is not met, the build will be removed from the queue.
11. Increase Build Delay
When a build condition is configured to queue a build when the condition is not met it will be re-queued onto the build queue and the delay adjusted according to what has been set on the condition.