How do I work with Triggering builds

Still need help?

The Atlassian Community is here for you.

Ask the community

Platform notice: Server and Data Center only. This article only applies to Atlassian products on the Server and Data Center platforms.

Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.

*Except Fisheye and Crucible

Summary

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

Bamboo interfaces with several Repository hosts (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 increasing and more and more request start being made against your repository.

(info)   The following scenario will use Subversion as a 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.

Let's 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 that can be used to gather the 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:

3. Enable Quiet period

If using a Git Repository, you can enable a quiet period and allow Bamboo to accumulate commits over a certain period, before triggering a build. A "quiet period" specifies a delay after a single commit is detected before the build is started. This allows multiple commits to be aggregated into a single build.


Last modified on Mar 25, 2022

Was this helpful?

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