-
Suggestion
-
Resolution: Won't Do
-
None
-
None
-
0
-
1
-
Bamboo agents build to the revision that was latest at the time the build entered the queue.
If the build festers in the queue for a while and more commits are made then the agent should build to the revision at the time the build was taken from the queue.
Eventually bamboo will run a build with the latest revision because it will detect the more recent changes.
However users should have an option to choose 'Checkout to latest regardless' and force the agent to update to the latest revision.
[BAM-3947] Bamboo SVN should have 'force checkout to latest' option to build to latest revision when build is picked _from_ the queue
Rodrigo Tartajo
added a comment - This bug is the source of what I call "The first commit in the morning" problem:
Setup:
Bamboo has a project with two plans, each plan runs the same set of tests on slightly different environments, each plan takes 2 hours to run.
When the first commit of the morning happens, one of the plans starts while the other is queued (only 1 bamboo machine). If that first commit broke any test in the first plan, you would need to wait 6/8 hours to see the results with the fix:
- 2 hours for the second plan with just one commit to run.
- 2 hours for the first plan to run: is was queued with the last revision available when it finished the previous run, so the fix for the failure is still not included (the fix was committed during the run on the second plan).
- 2 hours for the second plan with your fix, to run, It is possible that the breakage only happens on the first plan, then:
- 2 hours for the first plan, with your fix, to run.
If this feature is implemented, the waiting time for the fix would be just 4 hours, for the second plan to finish (without your fix), and for the first plan to complete with your fix.
Rodrigo Tartajo
added a comment - This bug is the source of what I call "The first commit in the morning" problem:
Setup:
Bamboo has a project with two plans, each plan runs the same set of tests on slightly different environments, each plan takes 2 hours to run.
When the first commit of the morning happens, one of the plans starts while the other is queued (only 1 bamboo machine). If that first commit broke any test in the first plan, you would need to wait 6/8 hours to see the results with the fix:
2 hours for the second plan with just one commit to run.
2 hours for the first plan to run: is was queued with the last revision available when it finished the previous run, so the fix for the failure is still not included (the fix was committed during the run on the second plan).
2 hours for the second plan with your fix, to run, It is possible that the breakage only happens on the first plan, then:
2 hours for the first plan, with your fix, to run.
If this feature is implemented, the waiting time for the fix would be just 4 hours, for the second plan to finish (without your fix), and for the first plan to complete with your fix. 
Jacobo de Vera
added a comment - This bug wastes a lot of computing power running tests against buggy builds when those bugs have long been fixed. This seems like a minor change with a huge impact, please reconsider actioning this.
Jacobo de Vera
added a comment - This bug wastes a lot of computing power running tests against buggy builds when those bugs have long been fixed. This seems like a minor change with a huge impact, please reconsider actioning this. 
Fabian Nilius
added a comment - I totally agree. With our build system, it happens that build are in queue for about 20 Minutes, and it is useless to build the then outdated version of the code.
Fabian Nilius
added a comment - I totally agree. With our build system, it happens that build are in queue for about 20 Minutes, and it is useless to build the then outdated version of the code. 
Hi everyone,
Thank you for your interest in this issue.
While this suggestion has gathered significant interest, we're unable to implement all of the excellent suggestions you make. We don't plan to work on this for the foreseeable future.
We understand this decision will be disappointing to everyone who voted for this issue. While we believe this suggestion would improve the product, after careful review of the most pressing needs of our customers, we've decided to prioritise other areas of the Bamboo roadmap, including:
We hope that you appreciate our candid and transparent communication. You can learn more about our approach to highly voted server suggestions here.
To learn more on how your suggestions are reviewed, see our updated workflow for server feature suggestions.
Kind regards,
Bamboo Team