If you are using a version of Bamboo prior to version 1.2, you will need to upgrade Bamboo to version 1.2 before you can upgrade to version 2.0. Note that the upgrade process from version 1.0.x is different from the upgrade process from version 1.1.x. Please follow the appropriate instructions below:

Upgrading from Bamboo 1.1.x

You will need to:

1. Upgrade to Bamboo 1.2 — please see the Bamboo 1.2 Upgrade Guide.
2. Then upgrade to Bamboo 2.0, as per the 'Upgrading from Bamboo 1.2.x to 2.0' instructions below.

Upgrading from Bamboo 1.0.x

You will need to:

1. Upgrade to 1.1.2 first — please see the Bamboo 1.1.2 Upgrade Guide. (This step is necessary as there is an issue with the upgrade process from the 1.0.x series that we're currently looking into.)
2. Then upgrade to Bamboo 1.2 — please see the Bamboo 1.2 Upgrade Guide.
3. Then upgrade to Bamboo 2.0, as per the 'Upgrading from Bamboo 1.2.x to 2.0' instructions below.

It is strongly recommended that you back up your xml-data directory before proceeding. For full instructions please follow the Bamboo upgrade guide.

You will need to re-index your Bamboo instance post upgrade, please consult step 6 of the Bamboo upgrade guide for more details.

1. Adding a Broker URL property.

Bamboo uses a messaging broker to communicate with it's remote build agents. To ensure this works properly, a URL must be specified. This URL is where Bamboo will set up its embedded broker. Remote agents will also be provided with this URL on startup.

To specify the broker URL, please add a bamboo.jms.broker.uri property in your bamboo.cfg.xml file, located inside the Bamboo home directory. For example:

<property name="bamboo.jms.broker.uri">tcp://HOSTNAME:54663</property>

where HOSTNAME is the canonical name of your Bamboo server.

Please note, as remote agents use this URL to communicate to the server, you should take care not to specify localhost as the host name in the broker URL.

If no broker URL is found in bamboo.cfg.xml, Bamboo will default the broker URL to tcp://HOSTNAME:54663 in the bamboo.cfg.xml file, as seen in the example above. Bamboo will also append the parameter wireFormat.maxInactivityDuration=0 by default to any broker URL coming from bamboo.cfg.xml.

2. Changes to Server Configuration

JDK support

Bamboo 2.0 requires JDK 1.5 (i.e. JDK 1.4 is no longer supported). Please note that this does not affect the actual builds: it is only the Bamboo server itself that must be running JDK 1.5.

Database changes

The release of 2.0 will include some changes to column names in the database as follows:

• In the BUILD_DEFINITION table, the column XML_DATA will be changed to XML_DEFINITION_DATA
• In the BUILDRESULTSUMMARY_CUSTOMDATA table, the column CUSTOM_INFO_DATA will be changed to CUSTOM_INFO_VALUE

These fields have also had types changed to CLOB to increase their maximum lengths.

Plugins

If you are using external or custom plugins, please make sure that your plugins compile against Bamboo 2.0 before upgrading.

3. Changes to Build Queues and Build Plans

Bamboo 2.0 introduces the concepts of agents and capabilities. To preserve the functionality of your existing plans, JDKs, Builders and Build Queues, the following will automatically happen during the upgrade:

Conversion of Build Queues to Agents

Prior to Bamboo 2.0, you could have multiple build queues. In Bamboo 2.0, there is now only one build queue, but multiple agents (see diagram).

As part of the upgrade process,

• Each of your build queues will be converted to a local agent.
• If, prior to the upgrade, the build queue accepted builds from all plans, the agent will be given the following capability (and every plan will be given an equivalent requirement): 
  • Key: bamboo.1.2.queue
  • Value: ALLOW_ANY_BUILDS
• Or if, prior to the upgrade, the build queue only accepted builds from specific plans, the agent will be given the following capability (and the relevant plans will be given an equivalent requirement):
  • Key: bamboo.1.2.queue
  • Value: <name of old queue>

If you wish to change this after the upgrade, please see Agents and capabilities and Configuring a Job's Requirements.

Conversion of Builders to Capabilities

Prior to Bamboo 2.0, your builders (e.g. Maven) were defined globally. In Bamboo 2.0, builders are now defined as agent capabilities and specified as plan requirements.

As part of the upgrade process,

• Each of your builders will be converted to a local server capability (that is, it will apply to every local agent).
• Every plan will continue to have the same builder that it had before the upgrade.

If you wish to change this after the upgrade, please see Configuring capabilities and Configuring a Job's Requirements.

Conversion of JDKs to Capabilities

Prior to Bamboo 2.0, your JDKs (e.g. JDK 1.5) were defined globally. In Bamboo 2.0, JDKs are now defined as agent capabilities and specified as plan requirements.

As part of the upgrade process,

• Each of your JDKs will be converted to local server capabilities (that is, it will apply to every local agent).
• Upon conversion, the labels of each of your JDKs will upgraded to the Bamboo 2.0 JDK label format, (i.e. 'JDK 9.9.9_99').
• Upon conversion, two more generic versions of the labels will be created for each JDK, (i.e. 'JDK 9.9' and 'JDK').
• Every plan will have its requirements upgraded, to keep the association with the same JDK that it had before the upgrade.

If you wish to change this after the upgrade, please see Configuring capabilities and Configuring a Job's Requirements.

4. Changes to Repositories

Bamboo 2.0 introduces the concepts of agents and capabilities. To preserve the functionality of your existing Repositories, the following will automatically happen during the upgrade:

Conversion of Perforce P4 Client Application Location to a Capability

With the introduction of remote agents in Bamboo 2.0, the location of the Perforce P4 client application now needs to be specified as a capability. To create build plans using Perforce as repository, a local server capability must be created for the P4 client application location. In addition, agent-specific remote capabilities must be created for each remote agent using Perforce.

As part of the upgrade process,

• A local server Perforce capability will be created for the Perforce P4 client application location. The upgrade task reads this information from the system's environment variables. If the Perforce P4 client application location has not been specified as an environment variable, the local server capability will need to be set up manually.

The upgrade task will not create agent-specific Perforce capabilities for any remote agents. These capabilities will need to be set up manually.

Please see 2024-08-21_07-46-38_Perforce for further details on Perforce capabilities.

Minimum repository version requirement for CVS and Perforce

Due to internal changes, Bamboo is no longer compatible with the following:

• CVS server version 1.11.1p2 and below.
• Perforce server version 2005.1 and below.

If you are planning on upgrading to Bamboo 2.0, please consider upgrading your repository server version.

5. Changes to Jetty (Bamboo Distribution Only)

Jetty has been upgraded from version 5 to version 6 in Bamboo 2.0. This means that if you have set up Bamboo to use the jetty.xml file, it will no longer work. You will need to update the configuration to be compatible with Jetty 6.

If you are already using the latest Bamboo 2.0 Beta, no additional upgrade tasks are required. Your Beta license key will continue to function until it expires. We encourage you to consider purchasing a license, if you wish to continue using Bamboo 2.0.