FinalBuilder 4 introduces a new feature: Estimated Progress. It's a progress bar that increments by one every time an action completes while your build runs, and the total is dynamically calculated. It's the total, and more specifically the calculation of the total that I'm going to shed some light on in this post. But first, here's a quick screenie of what the progress bar looks like during a build:
Estimated Progress was a bit of a controversial issue for us. On one hand it'd be great to see how your build is going as a percentage, but on the other, it's something that is almost impossible to predict accurately due to the very dynamic ways people can set up their build process (eg. loops, conditions, case statements, etc). So, we needed a way to predict the total progress somehow.
- When a build first starts, the progress is set to zero and the progress bar total is calculated.
- First the log archive is queried to find the last successful build. If there was a last successful build, then the amount of actions that executed in that build is used to set the total (this was a cinch to get a count of the last actions, as the log files are now a relational database).
- If there was no last successful build, then FinalBuilder calculates how many actions are in your build process and uses that as the total.
Now, we realise that the above two methods will not be adequate for some build processes. For example, a build process may have two modes (eg. Full and BugFix). The two different modes may have very different progress totals, and using the last successful build action count method will only work some of the time. Thanks to the beta testers, we've introduced a new script method “SetEstimatedProgressTotal” which takes a single integer parameter which allows the progress total to be set to any value at any time during the build process.
So, how can you use this?
Well, lets use the same example above - your build process has Full and BugFix modes. You know (because you've run a Full build enough times) that a Full build will run 469 actions, and that a BugFix build runs only 210 actions. Your build process will have some logic at the start which figures out if a Full build or BugFix build is required, and using that same logic it can call the script function for the full build (in JScript):
if (FullBuild){
SetEstimatedProgressTotal(469)
} else {
SetEstimatedProgressTotal(210)
}
This gives you complete control over the estimated progress, and it can be set at any time during your build. Of course, you could also use a persistent project variables (ooh, better blog about this soon) to set the total progress... so you can make it as complicated as you want! For the FinalBuilder build process, we rely on the default behaviour as the last successful build is a very good indication for how many actions will execute in the next build.