Documentation for Bamboo 4.0.x. Documentation for earlier versions of Bamboo is available too.

There are several methods by which Bamboo can 'trigger' (i.e. begin executing) a plan's build:

Build Strategy

  • Code updated — ensures that a plan build only occurs when something changes in the plan's source repository (which may affect the outcome of a plan build) .i.e. whenever one or more authors check in code.
  • Scheduled build — can allow a team to structure the day according to a predictable schedule. Scheduled builds are run regardless of whether or not any code changes have occurred i.e. at scheduled times or specified time intervals.
  • Manual build — allows you to ensure that builds are only triggered manually (or by the successful builds of other plans on which this plan is dependent).
  • Initial clean build — i.e. immediately after a new plan has been created.

Build Dependency

  • Dependency — a build can be triggered whenever another plan's build is successfully completed.

The trigger method for a plan's build is listed in the 'Reason' column on the dashboard.

On this page:

Related pages:

Considerations for choosing a build strategy

This table lists Bamboo's available 'build strategies', which determine how the execution of a plan (i.e. a build) is triggered. You set a Build Strategy option on the Plan Details tab of the plan configuration.

Build strategy option

Description

Reason for choosing

Code is updated

Polling the Repository for changes

Bamboo will 'poll' the source code repository for changes based on either of the following:

  • set intervals (periodically)
  • a schedule.

If Bamboo detects a change to any code in this repository, a build of this plan will be triggered.

See Polling the repository for changes.

  • This is a 'pull strategy'.
  • This is the simplest option.
  • But it does mean that your SCM must service a 'check out' or 'update' command whenever it is polled, even if no code has changed in the repository.

Repository triggers the build when changes are committed

Bamboo will wait to receive a message from the source code repository (specified above) about any code changes in this repository. When Bamboo receives such a message, Bamboo will trigger a build of this plan.

See Repository triggers the build when changes are committed.

  • This is a 'push strategy'.
  • This option minimises server load as message events are sent only when code changes to this repository are committed.
  • But you must configure your source code management system to send message events to Bamboo about code changes in this repository.
Scheduled

Cron Based Scheduling

Bamboo will trigger a build of this plan based on a cron expression.

See Cron-based scheduling.

  • Allows you to run builds based on a schedule.
  • This option allows you to schedule builds when server load is likely to be minimal, for example, outside office hours.
  • Scheduled builds are triggered irrespective of any code changes in the source code repository.

Single daily build

Bamboo will trigger a build of this plan once per day at a specified time.

See Single daily build.

  • Can be set up to run at a time of you choice.
  • This option is suitable if a build of this plan takes a long time to complete.
  • Scheduled builds are triggered irrespective of any code changes in the source code repository.
Manual

Manual

Bamboo only triggers a build of this plan when the user chooses this function manually or through a build dependency.

See Triggering a plan build manually.

  • This option is suitable if a build of this plan will fail, perhaps due to source code problems of failing tests.
  • This frees up Bamboo agents to build other plans which are less likely to fail.

Build dependencies and build strategies

Build dependencies are "parent-child" relationships between plan builds, which can be configured so that a series of plan's builds are triggered. See Setting up plan build dependencies.

Build dependencies work together with the build strategies of plans to trigger builds of these plans. For example, you can set up Plan A to poll its repository for changes as well as configure a build dependency on a parent plan (Plan B). In this case, builds of Plan A will be triggered when code changes are detected in its repository and also when builds of Plan B complete successfully.
If you want your builds to only be triggered by successful parent builds from your build dependencies, you can do this by specifying Manual as the build strategy for your plan. See Triggering a plan build manually.

Conditional build triggers

This field is only available when configuring an existing plan.

You can choose to run builds of this plan only if other specified plans are currently passing. Those plans that must build successfully before this plan can be built. See also Setting up plan build dependencies.

To specify build trigger conditions:

  1. Click Dashboard and then the All Plans tab.
  2. Locate the plan in the list and click the edit icon  to display the plan's configuration pages.
  3. Click the Plan Details tab.
  4. Select Only run Build if other Plans are currently passing, under 'Trigger Conditions'.
  5. Specify one or more other plans by adding their full keys.

  • No labels



Log a request with our support team.



Raise an issue for our developers.



See answers from the community.



Blog and update our documentation.

Except where otherwise noted, content in this space is licensed under a Creative Commons Attribution 2.5 Australia License.