Changes for 5.10

On this page

See also

Stash rebranding information

We've renamed Stash to Bitbucket Server and Bitbucket to Bitbucket Cloud in the Bamboo GUI to maintain consistency with Stash/Bitbucket rebranding.

The changes in the UI don't affect the internal use of APIs.

Platform upgrades

We're introducing the following changes:

JDK8 as a minimum runtime and compile requirement

Bamboo 5.10.x doesn't run or compile on JDK less than 8.

Plugin developers can now use all new shiny Java 8 goodies including streams and lambdas.

Bamboo runs on Tomcat 8

Bamboo 5.10.x runs on Tomcat 8.

For more information about upgrading your project configuration, see Starting Bamboo and running integration tests in the upgrade guide.

Servlet API upgrade (3.0.1)

Bamboo 5.10.x runs on Tomcat 8 and therefore provides servlet API 3.0. Make sure that your plugin is compatible with the servlet API 3.0. 

For more information, see Building plugins against custom versions of Bamboo in the upgrade guide.

Plugins framework (4.0.4)

This is an upgrade of the way in which Bamboo transforms and loads plugins.

SAL upgrade (3.0.2)

For more information, see SAL 3.0 Upgrade Guide.

Soy Renderer upgrade

The new soy compiler used by Bamboo is more restrictive when it comes to the template syntax. Make sure that your templates are properly compiling in runtime.

REST 3.0 upgrade We've upgraded REST to 3.0.2.

Dropped support for MySQL storage engines other than InnoDB

Bamboo 5.10.x runs only with the InnoDB storage engine.

Security improvements: class serialization

Now you can control the Java classes that are serialized in Bamboo and that are required specifically for Bamboo agent-server communication. 

If your plugins are depending on serializing classes (Bandana on Agent-Server messages), you must whitelist the classes or the plugins will stop working.


If you have access to the Bamboo home directory, you can edit the whitelist file in the Bamboo configuration directory (<config-dir>/serialization-whitelist.list), which is usually placed in the <bamboo-home>/xml-data/configuration directory.

  • the file is just a plain text file with class names (java.lang.Class#getName()) listed, each in new line
  • updates to this file do not require restarts of Bamboo or agents
  • the serialization-whitelist.list file already contains default Bamboo whitelisted classes


Plugin vendors can implement a new plugin module to list additional whitelisted classes used by their plugin:

module name serializableClassWhitelistProvider
class that needs to be implemented from Bamboo API

This change does not require restarts of Bamboo or agents.


Example of a configuration directory file




Example of plugin module usage

  • atlassian-plugin.xml
  <serializableClassWhitelistProvider key="serializable.class.whitelist.git" class="com.atlassian.bamboo.plugins.git.GitSerializableClassWhitelistProvider" />


public class GitSerializableClassWhitelistProvider implements SerializableClassWhitelistProvider
    public Iterable<String> getWhitelistedClasses()
        return ...;

Other API changes


The following methods were removed without replacement as plugins shouldn't modify the values:

void setFirstBuildNumber(int firstBuildNumber);

void setLastBuildNumber(int lastBuildNumber);

void setNextBuildNumber(int nextBuildNumber);


Accessing next build number has been deprecated.

 * The next build number represents the number of the next build result that's to be executed
 * @return a build number, starting with 1
 * @deprecated 5.10 this is a piece of internal data and should not be used
int getNextBuildNumber();


Return type change. The method incorrectly returned Map<String, Artifact> instead of Multimap<String,Artifact>

Multimap<String, Artifact> getVersionArtifacts();

This method has been removed.

     * Retrieve plan artifact. Artifact is found by label (taken from artifactSubscription) and planResultKey.
     * @param planResultKey identifier of source plan
     * @param clientKey identifier of plan or deployment doing the download
     * @param artifactSubscription download details (e.g. target path, copy pattern)
     * @param artifactRetrievalConfig handler specific configuration
    ArtifactRetrievalStatus retrieve(@NotNull final PlanResultKey planResultKey,
                                     @NotNull final ResultKey clientKey,
                                     @NotNull final ArtifactSubscriptionContext artifactSubscription,
                                     @NotNull final ArtifactRetrievalConfig artifactRetrievalConfig) throws Exception;

Method signature changes.

 * Retrieves a plan artifact from artifact storage.
 * @param buildLogger           to use
 * @param planResultKey         the plan result that contains the artifact
 * @param artifactSubscription  the artifact subscription used to identify artifact
 * @param buildWorkingDirectory working directory of current build
 * @param availableArtifacts    artifacts found in source result
 * @return true if retrieval was successful, false otherwise
boolean retrieve(@Nullable final BuildLogger buildLogger,
                 @NotNull final PlanResultKey planResultKey,
                 @NotNull final ArtifactSubscriptionContext artifactSubscription,
                 @NotNull final Map<String, String> artifactHandlerConfiguration,
                 @NotNull final File buildWorkingDirectory,
                 @NotNull final Multimap<String, Artifact> availableArtifacts);

 * Retrieves an artifact from artifact storage. The important difference for that method is, that NO subscription
 * information is updated. Useful for retrieving artifacts in non standard way (cross-plan for example)
 * If versionArtifacts parameter is specified, the method will first try to match requested artifact with the content of the map.
 * If match is found, information in {@link Artifact} object will be used to find artifact in the storage.
 * @param buildLogger
 * @param planResultKey
 * @param clientKey
 * @param artifactDefinitionContext
 * @param destinationPath
 * @param artifactHandlersConfiguration
 * @param buildWorkingDirectory
 * @param availableArtifacts
 * @return
boolean retrieve(@Nullable BuildLogger buildLogger,
                 @NotNull PlanResultKey planResultKey,
                 @NotNull ResultKey clientKey,
                 @NotNull ArtifactDefinitionContext artifactDefinitionContext,
                 @NotNull String destinationPath,
                 @NotNull Map<String, String> artifactHandlersConfiguration,
                 @NotNull File buildWorkingDirectory,
                 @NotNull final Multimap<String, Artifact> availableArtifacts);	


This method has been added. It returns runtime data that complements static task configuration.

Map<String, Serializable> getRuntimeTaskData();


Plan directory information REST API

Future changes to on-disk directory layout

A future release of Bamboo will make changes to the layout of the on-disk directory structure for artifacts and logs. These changes are necessary to make functionality more robust. If you are relying on scripts or other tools that examine data in the Bamboo home directory, you will need to update them to ensure that they continue to work.

To make this easier, we have added a resource to the Bamboo REST API to retrieve information about where on disk log files and artifacts will be stored in 5.9 so that you can prepare for the changes.

For more information, see Plan directory information REST API.

Was this page helpful?

Have a question about this article?

See questions about this article

Powered by Confluence and Scroll Viewport