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?
Over the next several weeks we'll be sharing some of our Getting Started guides here in the community. Throughout this series of posts, we'd love to hear from customers and non-customers ab...
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