Bamboo Data Center 11.0 Early Access Program release

Bamboo Development
, ,
1

We are pleased to announce the availability of the new version of Bamboo Data Center 11.0 Early Access Program (EAP) release (rc4).

This EAP release allows partners and customers who have written in-house apps to update and test their apps before the public release of Bamboo 11.0.

Important things to note about this EAP release:

  • Don’t use this EAP release in production environments. For all Bamboo production, use Bamboo 10.2.x, the latest official release.
  • The general availability release is still underway and may contain some changes. However, this EAP release is intended to contain a complete picture of Bamboo 11.0’s improvements.

Using the EAP

EAP can be downloaded as a zip archive for Windows x64 and a tar.gz archive for Linux. For installation instructions, head to the documentation.

Overview of changes in the EAP

Take a sneak peak of improvements that will be available when you upgrade to Bamboo 11.0. You can expect:

  • Deployment projects and environments caches
  • Migration to Apache Struts 6
  • Automatic offline agents management
  • Secure app installations with app signing

and many more. Find out more about what’s changed from the Bamboo 11 EAP release notes.

The Atlassian Bamboo team

3 Likes
2

Hey @pskierczynski

Thanks for the announcement.

We tested our app and needed to adapt a bit for the Struts 6 upgrade.
But that seems to work so far.

  1. Is the rename of the module in the atlassian-plugin.xml from xwork to struts also planned, similar to Confluence?
    https://developer.atlassian.com/server/confluence/struts-module/
  2. Would it be possible to provide some documentation about the Struts module in the Bamboo docs? Even if it’s just references the official and Confluence docs? https://developer.atlassian.com/server/bamboo/bamboo-plugin-module-types/

Nitpicking: the 11 EAP is also not mentioned in the content he: EAP releases | Atlassian Support | Atlassian Documentation (just in the navigation tree on the left).

Thanks in advance.
Markus

3

That’s great to hear @MarkusSutterMibexSof ! For 1. we don’t have any plan of renaming right now. And for 2. you can pretty much follow the Confluence documentation taking into consideration the module name.

4

@vdebone
Thanks for the answer.

Regarding the docs. It’s more about when a developer works on Bamboo apps, he/she will search in Bamboo docs, so I would expect to at least find a reference there about that module which would forward me to more context. Thanks for helping make the Bamboo developer docs the source of truth for Bamboo apps. :slight_smile:

5

We now found a problem with the EAP 11.0.0-rc4.

When accessing static method of class com.atlassian.bamboo.plugins.maven.task.Maven3Config from artifact: atlassian-bamboo-plugin-maven we get the following exception when accessing it from a running task:

error   06-May-2025 16:06:28    Caused by: java.lang.ClassNotFoundException: com.atlassian.bamboo.plugins.maven.task.Maven3Config not found by ch.mibex.bamboo.sonar4bamboo

Did something change regarding OSGI exports or so of this dependency?

6

Hi Markus, atlassian-bamboo-plugin-maven app initialization was migrated to use spring-scanner which generates much more strict OSGi configuration.
Can you please share what exact code you need to use from that plugin and we will fix that export at future versions of 11.0.x or provide workaround.

7

Hi @achystoprudov
Thanks for the info.
We currently use only the mentioned class com.atlassian.bamboo.plugins.maven.task.Maven3Config in this app we tested.
When do we can expect a 11.0.x release with a fix for that?

For which modules did you make that switch to SpringScanner with a more strict export?

So that we can check proactively?

Thanks in advance.

PS: would be also nice to inform here in the EAP channel shortly before the final release actually shipped.

8

can you say what exact method you use?

9 
M3_EXECUTABLE_KEY
M3_CAPABILITY_PREFIX
getExecutableName

So I checked the impl. now, so we could probably workaround it and copy the constants and use e.g.

com.atlassian.bamboo.v2.build.agent.capability.ExecutablePathUtils#makeBatchIfOnWindows

directly if that is accessible.

10

Hi Team,

We just stumbled over an oddity with the velocity allowlist of our app in Bamboo 11.0 (can’t say if this wasn’t an issue with the release candidates, or if we missed this specifc UI test):

Other than for Jira (top part of list below), Bamboo 11.0 also blocked methods from fairly standard java.util.* classes, which we would have expected to be part of the internal allowlist!? (bottom part of list below respective comment):

  <velocity-allowlist key="ifaws-velocity-allowlist" name="IFAWS Velocity Allowlist">
    <description>
      Identity Federation for AWS velocity templates can use these Java methods
    </description>
    <method>net.utoolity.atlassian.dry.AUIMessage#asHtml()</method>
    <method>net.utoolity.atlassian.ifaws.ao.DefaultCloudProvider#getDisplayName()</method>
    <method>net.utoolity.atlassian.ifaws.api.AWSConnectorDTO2#getId()</method>
    <method>net.utoolity.atlassian.ifaws.api.AWSConnectorDTO2#getName()</method>
    <method>net.utoolity.atlassian.ifaws.api.AWSConnectorScope#getDisplayName()</method>
[...]
    <!-- KLUDGE: It looks like the Bamboo internal allowlist does not cover the same default map operations as Jira! Additionally, these are not our from our
    own classes, but apparently we are allowed to declare them? -->
    <method>java.util.LinkedHashMap#entrySet()</method>
    <method>java.util.TreeMap#entrySet()</method>
    <method>java.util.HashMap#containsKey(java.lang.Object)</method>
    <method>java.util.TreeMap$EntrySet#iterator()</method>
    <method>java.util.TreeMap$EntryIterator#next()</method>
  </velocity-allowlist>

Additionally, we had to switch some velocity context entries from String[] to an explicit List type, as we even got errors for velocity internal methods being blocked on Array iteration:

2025-05-07 20:14:32,024 WARN [http-nio-6990-exec-16] [velocity] Invocation blocked as method is not allowlisted: org.apache.velocity.util.ArrayIterator#hasNext()

Questions:

  1. Shouldn’t standard java.util collection methods be part of the default, internal allowlist (as they seem to be with Jira > 10.5)?
  2. Is it ok for us to declare those missing methods for now, even though they do not stem from our own classes? The respective docs state:

Plugins can only define allowlist entries for their own classes.

Cheers,
Henrik

2 Likes
11

yeah, I think it’s the best option to copy constants and use ExecutablePathUtils

12

Yes, that’s what we did.

Could you also give an answer to my other questions?

For which modules did you make that switch to SpringScanner with a more strict export?
So that we can check proactively?

But in general, would be helpful to warn in advance, what exported/public API gets removed/not-exported anymore.

13

It was the only affected plugin

1 Like
14

Hey,
we just found another problem, which did fall through our first testing and only occurs on remote agents.
It’s this functionality:
com.atlassian.bamboo.plugins.maven.task.MavenUtils#getMavenVersion(java.io.File)

Did you fix the export in the bugfix release 11.0.1 for these plugin?

Or what would you recommend to do?
Thanks in advance.

15

hi,
We didn’t make any updates to export of that plugin as we expect it’s not required for app vendors. Will fix it next 11.0.2 planned for first week of June

16

First of all, I’m sorry for a late response.

  1. While building velocity allowlist we went with ‘only add it, if we know it’s needed’ approach, and since most Bamboo plugins use freemarker rather than velocity, our list ended up not that long. If you think about it, with constant additions to APIs, it’s likely that even if we created exhaustive list of ‘everything plugins could possibly want to use’, it’s not guaranteed to be exhaustive once we, say, update JDK compatibility.
  2. and thus, it’s OK to add any class to the plugin’s allowlist.

That being said, I’m adding java.utils.* and velocity.* methods you’ve listed to our allowlist for the 11.0.3 point release.