We use AccuRev and a custom Bamboo repository plugin. We have many plans set to build on AccuRev promotions using a triggered, not a polling, strategy. In earlier versions of Bamboo (v3), we had to put in some logic on our repository notification server that filtered out what plans to trigger. Otherwise, if we asked Bamboo to process all triggered plans on each promotion and build only the ones that have changes then it would overwhelm our source revision system with queries. We have about 30 plans configured for build triggering so having Bamboo send 30 queries to the AccuRev server on every promotion was too much to handle.
We are now on Bamboo v4.3 and I've been doing some tests to see if just triggering all plans with an "http://[bamboo url/api/rest/updateAndBuild.action" will still cause problems by overloading our source revision server. It looks like Bamboo v4.3 does a good job of first ignoring updateAndBuild actions against non-trigger plans. And then it looks like it limits the number of plans that concurrently query for changes.
Can anyone confirm if Bamboo does limit the number of triggered plans that concurrently query for changes? Or to put it another way, if we increase the number of plans that use build triggers, will that not increase the load we put on the rcs server on each check in?
Bamboo 5.9 will no longer be supported after June 12, 2017. What does this mean? As part of our End of Life policy, Atlassian supports major versions for two years after the first major iteratio...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot