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?
Thanks for signing up for Jira Ops! I’m Matt Ryall, leader for the Jira Ops product team at Atlassian. Since this is a brand new product, we’ll be delivering improvements quickly and sharing updates...
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