Bamboo Data Center 10.0 Early Access Program release

pskierczynski · June 29, 2024, 2:25pm

This post is about the previous (rc3) version. For the changes in the newest one (rc5) look here

We are pleased to announce the availability of the Bamboo Data Center 10.0 Early Access Program (EAP) release.

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

Due no earlier than Aug 14, 2024, Bamboo 10.0 is our next platform release and will contain breaking changes.

Important things to note about this EAP release:

Do not use this EAP release in production environments. For all production use and testing of Bamboo, use the latest official release 9 instead.
The general availability release is still underway and may contain some minor API changes. However, this EAP release is intended to contain a complete picture of Bamboo 10.0’s API.

Using the EAP

EAP is available for download as a zip archive for Windows x64 and tar.gz archive for Linux. For installation instructions, refer to documentation.

Overview of changes in the EAP

Supported platform changes

With this release, both Bamboo DC Nodes and Agents require Java 17. Support for running on Java 11 has been removed.

Bamboo 10.0 also removes support for the following platforms:

Repositories:
- Perforce
Database:
- Postgres 12
- Oracle 18c

Dark theme

Bamboo 10.0 features both dark and light themes to offer a modern visual experience.

To experiment with new themes, select your profile avatar on the upper right of the screen, and under Themes choose the needed option. Note that although the Original theme is currently accessible, there are intentions to phase it out in upcoming releases.

Additionally, the look and feel will not apply color choices to both themes. If your instance uses a custom header color, it will default to the light theme.

If your app incorporates visual elements, developers should check our guidelines for preparing your Data Center app for the dark theme, while designers should explore how to utilize tokens.

Platform 7 upgrade

Bamboo 10.0 includes an upgrade to Atlassian Platform 7. This upgrade puts us in a better position to respond to security changes with reduced disruption and breaking changes for your apps.

As part of this work, we have:

upgraded numerous Atlassian and third-party components to benefit from the latest security patches and bug fixes
removed ‘gray APIs’ (unsupported third-party and cross-product libraries with their dependencies).
reduced public JAVA API in Atlassian Plugins, WRM, Web Fragments, and LESS

Read more about how to prepare for the Platform 7 upgrade here.

REST v2

Platform 7 and Bamboo 10.0 have rearchitected the Java APIs used to implement REST resources, which we’re calling REST v2.

Note that this isn’t a change to Bamboo REST API, which remains largely unchanged. These changes will only impact app developers. The underlying libraries, Jackson and Jersey, have been upgraded to the latest versions. REST v2 also makes use of JAX-RS 2.

The REST v2 upgrade guide contains advice and examples on how to upgrade your app to use REST v2.

Endpoint default security annotations

We’ve enabled better control access to endpoints with new annotations. From Bamboo 10.0, only licensed users can access resources without specified access criteria annotations. Make sure you review:

@AdminOnly
@AnonymousSiteAccess
@LicensedOnly
@SystemAdminOnly
@UnlicensedSiteAccess
@UnrestrictedAccess

Reviewing these will ensure that the intended users can access your application endpoints. You may need to make changes to endpoints such as Struts Actions, Filters, Servlets, and REST resources.

Visit Prepare your Data Center app to comply with secure endpoint defaults for full details.

For development or testing purposes, this new behavior can be disabled by setting bamboo.security.endpoint.annotation.default.to.licensed.access property to false. This flag may be unavailable in the later releases and is not recommended for production environments.

WebSudo support

Bamboo 10.0 adds support for WebSudo to further protect admin pages against malicious access. This feature creates an extra layer of protection by prompting admins to re-enter their passwords to access administrative functions. Apps can opt into web sudo by adding the @WebSudoRequired annotation to REST APIs that require admin access. Similarly, servlets that require admin access should call WebSudoManager.enforceWebSudoProtection. More details can be found on Adding WebSudo support to your app.

Struts security improvement

Bamboo 10.0 removes support of Struts Dynamic Method Invocation feature. It affected few links which used to pass method name as part of URL in format strutsAction!method.action, most visible change is related to userlogin!doDefault.action link which was changed to userlogin.action.

sopel · July 1, 2024, 2:40pm

Thanks @pskierczynski, I’m unable to even just start Bamboo 10.0.0-rc3 though:

The EAP download page just shows a never ending wait spinner across various browsers
I’m usually testing via AMPS/SDK anyway, but this doesn’t work either, see below for details

AMPS / SDK

Just FYI, I’m using Java 17 via Amazon’s OpenJDK (versions 8/11 worked fine for years):

$ java -version
openjdk version "17.0.11" 2024-04-16 LTS
OpenJDK Runtime Environment Corretto-17.0.11.9.1 (build 17.0.11+9-LTS)
OpenJDK 64-Bit Server VM Corretto-17.0.11.9.1 (build 17.0.11+9-LTS, mixed mode, sharing)

I’m usually performing initial smoke testing via the SDK as follows:

$ atlas-run-standalone --product bamboo -v 10.0.0-rc3 -u 8.13.5 --jvmargs -Datlassian.dev.mode=false -Dupm.plugin.upload.enabled=true

So here I’ve been using the latest AMPS version 8.13.5 where Bamboo still starts up, but fails at runtime with a 500 - Internal server error, presumably due to not being Platform 7 (P7) ready.

However, using 8.14.0 or even the latest 8.17.1 doesn’t even start up Bamboo at all:

AMPS/SDK log excerpt incl. stack trace fragments

$ atlas-run-standalone --product bamboo -v 10.0.0-rc3 -u 8.17.1 --jvmargs -Datlassian.dev.mode=false -Dupm.plugin.upload.enabled=true
[...]
INFO] Copying plugins-viewer-plugin-2.1.0.jar to /home/ec2-user/uaa/taws/amps-standalone-bamboo-10.0.0-rc3/target/bamboo/home/shared/plugins/plugins-viewer-plugin-2.1.0.jar
[WARNING] Error injecting: org.apache.maven.plugins.help.EffectivePomMojo
java.lang.NoClassDefFoundError: org/apache/maven/model/InputLocation$StringFormatter
    at java.lang.Class.getDeclaredConstructors0 (Native Method)
[...]
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356)
Caused by: java.lang.ClassNotFoundException: org.apache.maven.model.InputLocation$StringFormatter
    at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass (SelfFirstStrategy.java:50)
[...]
ERROR] Failed to execute goal com.atlassian.maven.plugins:amps-maven-plugin:8.17.1:run-standalone (default-cli) on project standalone-pom: Unable to execute mojo: Execution null of goal org.apache.maven.plugins:maven-help-plugin:3.4.0:effective-pom failed: A required class was missing while executing org.apache.maven.plugins:maven-help-plugin:3.4.0:effective-pom: org/apache/maven/model/InputLocation$StringFormatter

Can you please advise how we can test Bamboo 10.0.0-rc3 via the stablished AMPS/SDK workflows (maybe I’m missing required flags for P7 or so)?

vdebone · July 2, 2024, 9:32am

Thanks for letting us know about the issue with the EAP page, we are looking into the issue.

For AMPS, the reason you are seeing 500s is because from Bamboo 10 we require Tomcat 9, and there was a small bug with enforcing the container version, for which we will be soon releasing a fix for. For now you can workaround the issue by enforcing the container version with --container tomcat9x.

Also, I hope it was a copy-paste mistake, but while testing your command, I noticed that you used double dashes on --v and that too caused issues. It should be either -v or --version. I could not reproduce the stack trace with 8.17.1.

sopel · July 2, 2024, 11:19am

Thanks @vdebone, the --v has indeed been an editing error (now corrected), I tried to shorten --version to make room for -u 8.13.5 in the code snippet w/o scrolling

Though promising, opting into Tomcat 9 via --container tomcat9x does not work either unfortunately, in fact it seems the flag isn’t even (fully) recognized:

I’ve tried --container tomcat9x and -c tomcat9x
I’ve tried using it as the first and last argument
I’ve tried --container asdf, which didn’t result in an error (though using --cantainer tomcat9x correctly complains about an ‘Unrecognized option’)

Here’s the (now actually copied) command line, the exception remains identical:

AMPS/SDK log excerpt incl. stack trace fragments

$ atlas-run-standalone --product bamboo -v 10.0.0-rc3 -u 8.17.1 --container tomcat9x --jvmargs -Datlassian.dev.mode=false -Dupm.plugin.upload.enabled=true
[...]
[INFO] Copying plugins-viewer-plugin-2.1.0.jar to /home/ec2-user/uaa/taws/amps-standalone-bamboo-10.0.0-rc3/target/bamboo/home/shared/plugins/plugins-viewer-plugin-2.1.0.jar
[WARNING] Error injecting: org.apache.maven.plugins.help.EffectivePomMojo
java.lang.NoClassDefFoundError: org/apache/maven/model/InputLocation$StringFormatter
[...]
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356)
Caused by: java.lang.ClassNotFoundException: org.apache.maven.model.InputLocation$StringFormatter
    at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass (SelfFirstStrategy.java:50)
[...]
[ERROR] Failed to execute goal com.atlassian.maven.plugins:amps-maven-plugin:8.17.1:run-standalone (default-cli) on project standalone-pom: Unable to execute mojo: Execution null of goal org.apache.maven.plugins:maven-help-plugin:3.4.0:effective-pom failed: A required class was missing while executing org.apache.maven.plugins:maven-help-plugin:3.4.0:effective-pom: org/apache/maven/model/InputLocation$StringFormatter

Given you are unable to reproduce that stack trace, do you have any idea how to debug this further?

Note that I’m using the SDK release 8.2.8, which is the latest version available as an RPM package, even though the TGZ package is at 8.2.10 already (oddly 8.2.8 still ships Maven 3.5.4, even though the MPAC release notes claim an update to 3.9.5):

atlas-version output

$ atlas-version

ATLAS Version:    8.2.8
ATLAS Home:       /usr/share/atlassian-plugin-sdk-8.2.8
ATLAS Scripts:    /usr/share/atlassian-plugin-sdk-8.2.8/bin
ATLAS Maven Home: /usr/share/atlassian-plugin-sdk-8.2.8/apache-maven-3.5.4
AMPS Version:     8.1.2
--------
Executing: /usr/share/atlassian-plugin-sdk-8.2.8/apache-maven-3.5.4/bin/mvn --version -gs /usr/share/atlassian-plugin-sdk-8.2.8/apache-maven-3.5.4/conf/settings.xml
Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z)
Maven home: /usr/share/atlassian-plugin-sdk-8.2.8/apache-maven-3.5.4
Java version: 17.0.11, vendor: Amazon.com Inc., runtime: /usr/lib/jvm/java-17-amazon-corretto.x86_64
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.10.217-205.860.amzn2.x86_64", arch: "amd64", family: "unix"

vdebone · July 2, 2024, 11:35am

The container change should fix the 500s errors you were getting, can you try with the command that worked plus the container change? The container won’t kick in until later.

For this stack trace you are getting, can you try to simply run atlas-run-standalone --product bamboo -u 8.17.1? I suspect it should throw the same error, given this is happening before anything is started, and we can narrow it down to AMPS, not Bamboo 10.0 EAP.

sopel · July 2, 2024, 12:09pm

Yup, simply running atlas-run-standalone --product bamboo -u 8.17.1 yield the identical error for Bamboo 9.6.3 indeed, thx!

Conversely, using the latest working AMPS release 8.13.5 with Tomcat 9 successfully starts up Bamboo 10.0.0-rc3

$ atlas-run-standalone --product bamboo -v 10.0.0-rc3 -u 8.13.5 --container tomcat9x --jvmargs -Datlassian.dev.mode=false -Dupm.plugin.upload.enabled=true

Can you advise whether using AMPS 8.13.5 is sufficient for Bamboo 10 compatibility testing, given later releases seem to contain various Platform 7 related fixes, e.g. around banned dependencies in releases 8.14.0 and 8.15.4?

As for the AMPS error, given it’s Caused by: java.lang.ClassNotFoundException: org.apache.maven.model.InputLocation$StringFormatter, this seems to indicate an incompatibility between AMPS >= 8.14.0 and Maven 3.5.4, so I should probably try upgrading Maven to a more current version like 3.9.5 that’s supposed to be shipped with AMPS anyway by now?

sopel · July 2, 2024, 12:24pm

Confirmed, I’ve just updated the SDK from 8.2.8 to 8.2.10 (which actually ships with Maven 3.9.5), and this allowed me to start up Bamboo 10.0.0-rc3 with the latest AMPS 8.17.1 and Tomcat 9 as follow:

atlas-run-standalone --product bamboo -v 10.0.0-rc3 -u 8.17.1 -c tomcat9x --jvmargs -Datlassian.dev.mode=false -Dupm.plugin.upload.enabled=true

Thanks for the debugging session @vdebone, much appreciated

vdebone · July 2, 2024, 2:14pm

Glad that it worked for you! And yes, let’s stick to the latest AMPS when testing the compatibility

RomanStoffel · July 9, 2024, 11:58am

We’ve started to look into Bamboo 10.

First, Bamboo apps are not OSGi apps by default with the Maven ‘confluence-maven-plugin’?
I’ve added the Osgi manifests now to get more insights.

Here are the problems I have:

(fixed, see below) I get this error when installing:

Caused by: java.lang.ClassNotFoundException: com.atlassian.plugin.web.model.AbstractWebPanel not found by ch.mibex.bamboo.sonar4bamboo [129]
        at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1591) ~[org.apache.felix.framework-7.0.5.jar:?]
        at org.apache.felix.framework.BundleWiringImpl.access$300(BundleWiringImpl.java:79) ~[org.apache.felix.framework-7.0.5.jar:?]
        at org.

I think the web-model classes should be exported? This class is the parent class for panels. We do import it in the Osgi manifest:

com.atlassian.plugin.web.model;resolution:=optional

2nd: The com.atlassian.bamboo.v2.build.agent.capability.AbstractFileCapabilityDefaultsHelper has the method Predicate<File> getValidityPredicate method. That Predicate is from Guava, which is not exported anymore. How are we supposed to override that method?

Update
1st: fixed by implementing the com.atlassian.plugin.web.api.model.WebPanel instead of using the AbstractWebPanel

achystoprudov · July 10, 2024, 8:56am

Hi @RomanStoffel , thank you for reporting. We will check option to export Guava for plugins or consider replacing Guava Predicate with java.util.function.Predicate and release Bamboo 10.0.0-rc4 in nearest future

remie · July 10, 2024, 9:23am

Can you please align this with the other product teams? For those that have shared code between products, having differences in which 3rd party modules are public API will make it even more complex to support Platform 7

rlander · July 10, 2024, 11:49am

+1, the right fix is to remove Guava from your public API. If one app exports Guava it creates a dependency management nightmare for cross product apps.

If you do not remove it, a cross-product app cannot bundle Guava for Bamboo, but would be required to for Bitbucket/Jira/Confluence.

RomanStoffel · July 10, 2024, 12:18pm

I got this exception on my actions:

2024-07-10 13:51:34,165 ERROR [http-nio-6990-exec-2] [StrutsActionHelper] action method [ default ] not found on [ ch.mibex.bamboo.sonar4bamboo.config.SonarServerConfigAction ]
java.lang.NoSuchMethodException: ch.mibex.bamboo.sonar4bamboo.config.SonarServerConfigAction.default()
        at java.base/java.lang.Class.getMethod(Class.java:2227) ~[?:?]
        at com.atlassian.bamboo.struts.StrutsActionHelper.getActionMethod(StrutsActionHelper.java:38) ~[atlassian-bamboo-web-10.0.0-rc3.jar:?]

However, the BambooActionSupport.doDefault is still defined and no hint of .default?
So, I’ve added a default method. Then I got this error:

java.lang.NoSuchMethodException: ch.mibex.bamboo.sonar4bamboo.config.SonarServerConfigAction.add()
        at java.base/java.lang.Class.getMethod(Class.java:2227) ~[?:?]
        at com.atlassian.bamboo.struts.StrutsActionHelper.getActionMethod(StrutsActionHelper.java:38) ~[atlassian-bamboo-web-10.0.0-rc3.jar:?]
        at com.atlassian.bamboo.struts.StrutsActionHelper.getActionClassMethod(StrutsActionHelper.java:44) ~[atlassian-bamboo-web-10.0.0-rc3.jar:?]
        at com.atlassian.bamboo.struts.BambooMappedAction.of(BambooMappedAction.java:99) ~[atlassian-bamboo-web-10.0.0-rc3.jar:?]

So, the method pattern seems to have changed from doAction to action only? Is that documented somewhere? I certainly missed that announcement.

RomanStoffel · July 10, 2024, 12:52pm

We made more progress. Now we are stuck on the Guava predicates issue, as mentioned before.

io.atlassian.util.concurrent.LazyReference$InitializationException: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'ch.mibex.bamboo.sonar4bamboo.tasks.maven.Maven3TaskConfigurator': Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [ch.mibex.bamboo.sonar4bamboo.tasks.maven.Maven3TaskConfigurator]: Constructor threw exception; nested exception is java.lang.NoClassDefFoundError: com/google/common/base/Predicate
	at io.atlassian.util.concurrent.LazyReference.getInterruptibly(LazyReference.java:156)
	at io.atlassian.util.concurrent.LazyReference.get(LazyReference.java:116)
	at io.atlassian.util.concurrent.ResettableLazyReference.get(ResettableLazyReference.java:95)

This class inherits from the AbstractFileCapabilityDefaultsHelper where the getValidityPredicate returns a Guava predicate

We’ll wait for rc4 and will the try again.

achystoprudov · July 10, 2024, 1:16pm

yeah @remie @rlander I can confirm that we missed that part of Platform 7 migration and going to remove usage of Guava API from Bamboo API classes at next 10.0 RC

achystoprudov · July 10, 2024, 1:17pm

can you please show how xwork actions are defined at atlassian-plugin.xml?

RomanStoffel · July 10, 2024, 1:32pm

The definitions looks like this:

    <xwork key="sonar4bamboo.serveradmin.xwork" name="Configure Sonar Plugin">
        <package name="sonar4bamboo" extends="admin" namespace="/admin/sonar4bamboo">
            <action name="viewSonarServerConfigs" class="ch.mibex.bamboo.sonar4bamboo.config.SonarServerConfigAction" method="default">
                <result name="success" type="freemarker">/templates/sonarconfig/viewSonarServerConfigs.ftl</result>
            </action>
            <action name="addSonarServerConfig" class="ch.mibex.bamboo.sonar4bamboo.config.SonarServerConfigAction" method="add">
                <result name="input" type="freemarker">/templates/sonarconfig/editSonarServerConfigs.ftl</result>
            </action>
            <action name="createSonarServerConfig" class="ch.mibex.bamboo.sonar4bamboo.config.SonarServerConfigAction" method="create">
                <result name="success" type="redirect">/admin/sonar4bamboo/viewSonarServerConfigs.action?action=added</result>
                <result name="error" type="freemarker">/templates/sonarconfig/editSonarServerConfigs.ftl</result>
                <result name="input" type="freemarker">/templates/sonarconfig/editSonarServerConfigs.ftl</result>
            </action>
            ...
        </package>
    </xwork>

Looks like older Bamboo required or at least supported up to Bamboo 9 to add a do{method} style of methods. In Bamboo 10 the mapping is 1:1.

It is not a blocker, but something we where not aware of. The do prefixed might be deprecated for a while already? However, the BambooActionSupport class still has a doDefault method, giving the wrong impression that this still works.

achystoprudov · July 10, 2024, 1:51pm

Actually “default” method name support was removed when Bamboo introduced support for JDK 8. Since long time mapping at xwork action method should be exact name of method at Action class, so for your case it should be method=“doDefault” and doDefault method should be declared at Struts Action

RomanStoffel · July 17, 2024, 9:36am

Is there soon an rc4? I’m mostly wondering because other Atlassian Platform 7 releases currently quickly releasing new updates. I want to be sure I didn’t miss some updates.

achystoprudov · July 19, 2024, 10:08am

We’re removing Guava from bamboo-api and bamboo-core public API and going to release rc4 next week