CloudBees CI release notes

After assessing the viability of our supported plugins, CloudBees will no longer support the CloudBees Amazon AWS CLI plugin (cloudbees-aws-cli) after December 2025, due to the APIs that this plugin relies on, reaching their end of life by AWS.

This end-of-life announcement allows CloudBees to focus on driving new technology and product innovation as well as maintaining existing products that are actively used by customers.

After December 2025, the plugin will lose functionality when upgraded. Instead of dynamically installing the AWS SDK CLI plugin to CloudBees CI agents during runtime, CloudBees strongly recommends that you add it to the agent definition, so it is always available at runtime. The AWS Credentials plugin allows you to define and provide proper AWS credentials for your agents, so shell steps can be used to invoke the AWS CLI, similar to the CloudBees Amazon AWS CLI plugin (cloudbees-aws-cli). For more information, refer to CloudBees Amazon AWS CLI plugin end-of-life announcement.

For more information regarding this end-of-life announcement, please contact your CloudBees Support.

In a CloudBees High Availability (HA) controller, when fetching job builds from the API, the builds are fetched internally from multiple replicas. As a result, the final response requires the number field for sorting the builds. Furthermore, without the number field, the output isn’t very useful. Therefore, when fetching the builds, the API request tree parameter now also requires number to be present, as in api/json?tree=builds[number,…​],arg2,arg3, and so on.

An HTTP 400 Error displays if number is not present.

In a CloudBees High Availability (HA) controller, the /computer/api/json endpoint returns aggregated output from all replicas. The displayName of a computer uniquely identifies it. It’s also used to fetch the correct state of the computer from the replica to which the agent is connected. Without the displayName, the output isn’t handy. Now, the request requires the displayName and returns an HTTP 400 Bad request error if not included.

When fetching the computer tree, the request should resemble /computer/api/json?tree=computer[displayName,…​],arg2,arg3.

API requests with double slashes (//) are now rejected with an HTTP 400 Bad Request response. The problem occurs when URLs have an extra slash, causing requests to be routed incorrectly.

Agents.SeparateNamespace.Enabled=true|false is now a required argument in the CloudBees CI Helm chart. You must pass this argument to your Helm chart or include it in your custom values file prior to installing or upgrading CloudBees CI on modern cloud platforms, or the installation or upgrade will fail with the following error:

CloudBees strongly recommends that you use a separate namespace for agents to prevent pods from accessing sensitive information on the operations center. If separate namespaces are not used for agents, an administrative monitor is now displayed in CloudBees CI. To use a separate namespace for agents:

In previous CloudBees CD/RO releases, a unified CloudBees Software Delivery Automation Helm chart was delivered to install CloudBees CI, CloudBees CD/RO, and CloudBees Analytics in Kubernetes environments. However, starting with CloudBees CD/RO release v2025.03.0, the CloudBees Software Delivery Automation Helm chart was deprecated and is not supported for future releases.

If you are currently using the CloudBees Software Delivery Automation Helm charts, CloudBees has provided automation scripting and instructions to help migrate your environments. For more information, refer to KBEC-00522 - Migrate from CloudBees Software Delivery Automation Helm chart to product Helm charts.

Breaking change: Any Windows agent will stop working in FIPS mode if configured with WinRM (Windows Remote Management).

The Amazon EC2 plugin (ec2-plugin) bundles the com.hierynomus:smbj library, which is not FIPS compliant. Therefore, Windows Agents will no longer work in FIPS mode because the class which uses the aforementioned library cannot be created.

As an alternative, use an SSH server and the Unix Launcher. Refer to the following steps:

Do not use the init script (it must be empty) if there is no shell interpreter configured. Otherwise, Windows will continue to hang.

Starting with this release, CloudBees CI requires Kubernetes 1.28 or later. Older Kubernetes versions 1.27 and below are no longer supported.

If you are using Kubernetes 1.27 or earlier, you must upgrade to at least Kubernetes 1.28 before upgrading to this CloudBees CI release.

CloudBees is currently planning the removal of Blue Ocean-related plugins, including Blue Steel (CloudBees CI Teams), from CloudBees Assurance Program (CAP). Please consider using CloudBees Pipeline Explorer (cloudbees-pipeline-explorer) as an alternative to Blue Ocean and managed controllers as an alternative to team controllers. Please contact CloudBees support if you are leveraging these features and need further discussion or assistance.

A change was made as a part of the CloudBees CI 2.462.2.2 release where the list of agent protocols are no longer configurable, either through the GUI or Configuration as Code.

This has a side effect on instances being managed by Configuration as Code, as these instances, when running in versions which includes the agents protocol in their jenkins.yaml file. The existence of this agents protocol prevents the instance from starting if you are running on a version higher than 2.479.1.3 for operations center, client controller or managed controller.

Once you remove this section, everything should return back to normal.

The Promoted Builds plugin was removed from CloudBees Assurance Program, and now the corresponding integration with the CloudBees Template system was also removed. This means that the template association of any existing promotion will be lost and no new ones can be created.

The Hazelcast library used in High Availability (HA) controllers was upgraded from the 5.3 line to the 5.5 line. This transition does not support a rolling upgrade. If you were previously running 2.462.3.3 or 2.479.1.x (either of the October 2024 releases), the upgrade to this (or a newer version) should be automatic, but it will involve a temporary outage of the controller, similar to a simple restart of a non-High Availability (HA) controller. If you ran an older release, it is recommended that you first upgrade to one of the October releases; otherwise, you can upgrade directly but only by first manually turning off all replicas of the old version (for example, by using the Reprovision gesture in the case of a managed controller).

As of the CloudBees CI 2.479.1.3 release, Java 11 is no longer supported and you must migrate to Java 17. For information on how to migrate from Java 11 to Java 17, refer to Migrate to Java 17. Please contact CloudBees Support if you have any concerns or questions.

The OpenId Connect Authentication (oic-auth) plugin now requires that the Issuer is set to enforce security and there is no option to disable this requirement as it is mandated in the Open ID Connect specification. As such, users who do not use automatic configuration via the well-known endpoint must first update to 4.355.v3a_fb_fca_b_96d4 and configure the Issuer before updating to this version.

Additionally, if using manual configuration and a JWKS (JSON Web Key Set) Server URL has not been specified, either enable disable token validation or set the JWKS (JSON Web Key Set) Server URL before you upgrade to this version.

Failure to do so will result in users unable to login, or CloudBees CI failing to start. Additionally, this removes the option to send the scopes when requesting the access token. Users of non-conformant OPs that require this functionality should remain on the previous version until the provider fixes their implementation.

Upgrade to Apache Tomcat 10 required

The CloudBees CI 2.462.3.3 release for traditional platforms is the last release to support running CloudBees CI in Apache Tomcat 9. You must upgrade to Apache Tomcat 10 before the next CloudBees CI release. Please contact CloudBees Support if you have any concerns or questions.

End of support to run CloudBees CI in Apache Tomcat

If you run CloudBees CI in Apache Tomcat, it was deprecated and CloudBees CI’s support ends after October 2025. An Administrative Monitor was added to advise customers on how to migrate from Tomcat to a CloudBees Linux package. For more information about the migration, refer to Migrate CloudBees CI on traditional platforms from Tomcat to a CloudBees Linux package. Please contact CloudBees Support if you have any concerns or questions.

As of the CloudBees CI 2.462.3.3 release, this is the last release to support Java 11. In the next CloudBees CI release, Java 11 will not be supported. For information on how to migrate from Java 11 to Java 17, refer to Migrate to Java 17. Please contact CloudBees Support if you have any concerns or questions.

When changing the value of the storage class name using Configuration as Code bundles, the incorrect value of the storage class name is shown on the controller provisioning screen.

When using Configuration as Code to provision controllers, every controller item in the bundle may need to be updated by specifying the storageClassName attribute for each clusterEndpoints and kubernetes objects. For example:

If you have pod templates that leverage the jenkins-agent ConfigMap, you need to migrate its configuration to the new idiom provided by the Kubernetes plugin. * Check "Inject Jenkins agent in agent container" or add agentInjection: true to the pod template step, or agentInjection true in the declarative pipelines. * Remove volume mounting in the jenkins-agent ConfigMap, and the associated command (the new option injects the required command and arguments automatically). The jenkins-agent ConfigMap will be removed from the Helm chart in late 2025.

To increase our security posture, we now use the distroless variant of Red Hat UBI to reduce the attack surface of our container images.

If you build a derivative container image based on the one that CloudBees provides, it is an incompatible change, and you will need to update it as our images no longer contain a package manager. This is the case for the operations center, the managed controller images, and also agent images.

If you use agent images, tools like which, vi, are no longer available. You can use the shell builtin command -v as an alternative to which. If you need additional tools for interactive agent debugging, consider using Kubernetes debug containers .

The following Dockerfile example displays an image extension that adds a new system package.