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?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.