How do I work with Triggering builds

Still need help?

The Atlassian Community is here for you.

Ask the community

Purpose

The following will provide you with a better understanding on considerations to be taken when setting up repository triggering in Bamboo.

Bamboo interfaces with several Repository host (e.g. Stash, Bitbucket, Git, GitHub, Subversion ...), selected under Bamboo administration >> Overview >> Build resources >> Linked repositories or Plan configuration >> Repositories tab; and to each of them you may have different repository triggering methods to select from. We will be addressing the most common issues when delegating Bamboo to communicate with your repositories checking for repository changes.

The following content is related to:

When adding Repository polling - periodically, you are telling Bamboo to send a request against your repository for changes and if changes are found, Bamboo should trigger a new build. Issues start happening when your use case start on increasing and more and more request start being made against your repository.

(info)   The following scenario will use Subversion as Repository host.

When it comes to Git, there is a caching system in place. If there are multiple requests to the same repository (e.g. different branches), only one request will be sent out.

Lets take the following example and evaluate the scenarios:

  • in Bamboo there is only one plan (e.g. PROJ-PLAN) that has a repository setup
  • Repository host has been selected as Subversion
  • Repository polling - periodically has been added with its default 180 seconds frequency

Based on the configuration above, Bamboo will communicate with the SVN repository every 180 seconds checking whether or not there are changes.

Plan KeyTypeTriggeringPolling Frequency (seconds)Change Detection (seconds)
PROJ-PLANPlanPeriodically180~3

At a later time, the decision is made to allow Bamboo to create Branches and run builds on those as well. As a result, you have created extra 10 branches:

Plan KeyTypeTriggeringPolling Frequency (seconds)Change Detection (seconds)
PROJ-PLANPlanPeriodically180~3
PROJ-PLAN0BranchPeriodically180~3
PROJ-PLAN1BranchPeriodically180~3
...



PROJ-PLAN9BranchPeriodically180~3

Based on the configuration above, Bamboo requests changes from the repository every ~16.36 seconds:

Polling Frequency / # of Plan keys == 180 / 11 == 16.36

Based on the scenario above, since Bamboo gets a response from the repository within ~3 seconds (change detection), we understand that Bamboo has enough time to perform change detection and consume the data from the repository.

Expanding on the example above, consider the following table that outlines a growth scenario as you create new Plans (1 >> 2 >> 3 >> 4 >> 5) in Bamboo, all with the same amount of branches (11):

Plan KeyTypeTriggeringPolling Frequency (seconds)Change Detection (seconds)Polling Frequency / # of Plan keys
PROJ-PLANPlanPeriodically180~3180 / 11 = 16.36

PROJ-PLAN

PROJ-A

PlanPeriodically180~3180 / (11*2) = 8.18

PROJ-PLAN

PROJ-A

PROJ-B

PlanPeriodically180~3180 / (11*3) = 5.45

PROJ-PLAN

PROJ-A

PROJ-B

PROJ-C

PlanPeriodically180~3180 / (11*4) = 4.09

PROJ-PLAN

PROJ-A

PROJ-B

PROJ-C

PROJ-D

PlanPeriodically180~3180 / (11*5) = 3.27

PROJ-PLAN

PROJ-A

PROJ-B

PROJ-C

PROJ-D

PROJ-E

PlanPeriodically180~3180 / (11*6) = 2.72

As you can see from the table above, the value of the Polling frequency / # of Plan keys progressively decreases and eventually is less than the value of Change Detection. When this happens, Bamboo will not able to attend to all the requests and they will start be queued (com.atlassian.bamboo.trigger.polling.PollingTriggerQuartzJob).

Based on what has been mentioned above, there are two possible workarounds:

  1. increasing Polling Frequency to be higher than the Change Detection interval
  2. delegating Subversion the task to notify Bamboo about changes in the repository (preferable)

Solution

1. Increasing Polling Frequency 

Before increasing the Interval, it is important to review the amount of time Bamboo takes to collect the changes from your repositories.

In order to to it so, you have to:

  1. go to Bamboo administration >> Overview >> System >> Log settings and add the following:

    Classpath

    com.atlassian.bamboo.v2.trigger.DefaultChangeDetectionManager

    Type

    DEBUG

  2. in the Bamboo logs, you should find entries as per following:

    2016-04-12 17:18:34,899 DEBUG [10-BAM::PlanExec:pool-17-thread-2] [DefaultChangeDetectionManager] Collecting changes for PROJ-PLAN
    2016-04-12 17:18:34,899 DEBUG [10-BAM::PlanExec:pool-17-thread-2] [DefaultChangeDetectionManager] Collecting changes for plan: PROJ-PLAN
    2016-04-12 17:18:34,900 DEBUG [10-BAM::PlanExec:pool-17-thread-2] [DefaultChangeDetectionManager] Collecting changes for repository RepositoryDataImpl{id=2064385, pluginKey='com.atlassian.bamboo.plugin.system.repository:svn', name='Repository A - Subversion', description='null', global=false, markedForDeletion=false, repositoryRef=com.atlassian.bamboo.repository.RepositoryReference@7753d8f7, webRepositoryViewerRef=com.atlassian.bamboo.repository.WebRepositoryViewerReference@70d5db4a, configurationRef=com.atlassian.bamboo.repository.RepositoryConfigurationReference@13dc3db7}
    2016-04-12 17:18:34,918 DEBUG [10-BAM::PlanExec:pool-17-thread-2] [DefaultChangeDetectionManager] Collecting changes for repository RepositoryDataImpl{id=2064385, pluginKey='com.atlassian.bamboo.plugin.system.repository:svn', name='Repository A - Subversion', description='null', global=false, markedForDeletion=false, repositoryRef=com.atlassian.bamboo.repository.RepositoryReference@7753d8f7, webRepositoryViewerRef=com.atlassian.bamboo.repository.WebRepositoryViewerReference@70d5db4a, configurationRef=com.atlassian.bamboo.repository.RepositoryConfigurationReference@13dc3db7} took 3019ms

    Based on the log entry above we can notice it takes ~3 seconds (3019ms) to collect changes from one repository.

Once the information is gathered, it is time to increase the Interval so the queue can, once again, be attended.

Please, find below SQL statement that can be used to gather Triggering method used in Bamboo.

(info)   [Database] - Repository Polling - Periodically (Bamboo version) refers to the scenario above presented.

(info)   [Database] - Repository Polling - Scheduled (Bamboo version) and [Database] - Scheduled (Bamboo version) should be reviewed when the scheduled has been set up to happen frequently, working in the same way as [Database] - Repository Polling - Periodically (Bamboo version)

0 0/5 * ? * *

this schedule represents a request every 5min

2. Let Repository Server decides (preferable

Instead of leaving Bamboo with the task to retrieve information about your repository, its is beneficial for not only Bamboo but also to your Repository having the Repository server communicating with Bamboo when repository changes are made (e.g. unnecessary communication with the repository will decrease performance in both, Bamboo and repository server). In this case, you would have the option to:


Last modified on Mar 24, 2021

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.