CloudBees CI release highlights

What’s new in CloudBees CI 2.452.1.2

Watch video

Upgrade Notes

People View moved to an unsupported plugin

The People View functionality has been moved to a plugin which is currently not supported in the CloudBees Assurance Program.


Operations center CloudBees Assurance Program plugin changes since 2.440.3.7

The following plugins have been added to the Operations center CloudBees Assurance Program since 2.440.3.7:

  • CloudBees CasC Shared Plugin (cloudbees-casc-shared)

  • OpenID Connect Provider Plugin (oidc-provider)


Controller CloudBees Assurance Program plugin changes since 2.440.3.7

The following plugins have been added to the Controller CloudBees Assurance Program since 2.440.3.7:

  • CloudBees CasC Shared Plugin (cloudbees-casc-shared)

  • OpenID Connect Provider Plugin (oidc-provider)


New Features

Kubernetes 1.28 and Red Hat OpenShift 4.15 support

CloudBees CI on modern cloud platforms now supports Kubernetes 1.28 on Azure Kubernetes Service, Amazon Elastic Kubernetes Service, Google Kubernetes Engine and Red Hat OpenShift 4.15. For more information refer to, Supported platforms for CloudBees CI on modern cloud platforms.

Feature Enhancements

Support for other organization folders and other item properties
  • Support for other organization folders

    Currently, GitHub Organizations, Bitbucket projects, and GitLab projects are the only organization folders that can be imported and exported using the CloudBees CasC Items plugin. Starting with this release it is possible to import and export other organization folders by adding your own SCMNavigator class.

  • Customization mechanism for item properties in CloudBees CasC Items

    If a custom or proprietary plugin allows you to add properties to one of the supported items, it is possible to customize the export and import YAML format (properties to list and aliases to apply). Please refer to the documentation to learn how to start using this mechanism.

    Supported plugins are still the same.

HashiCorp Vault cluster consistency now supported

The CloudBees HashiCorp Vault plugin now supports cluster consistency. It allows users to choose the strategy used by the Vault client to mitigate the Vault cluster eventual consistency.

The following mitigation strategies are now supported:


The CloudBees Pipeline Explorer now displays additional SCM information in the build info section
  • The CloudBees Pipeline Explorer now displays additional SCM information in the build info section For Multibranch Pipeline builds, the CloudBees Pipeline Explorer now displays information about the relevant branch or change request; for example, the branch name and change request title.

  • Removal of the CloudBees Pipeline Explorer spinner and animate in progress bar The progress bar is now displayed for the first builds and the spinner in the header was removed.

  • Enhanced accessibility via tabbing Accessibility is enhanced by using tabbing in the CloudBees Pipeline Explorer.


High Availability (HA) Enhancements
  • Serialization requirement removed on High Availability (HA) script console

    In the Script console for High Availability (HA) on a controller under /highAvailability/script, the serialization requirement has been removed. The scripts that used to cause a notSerializedException now display a result.

  • High Availability (HA) development mode notations restricted to administrators

    When development mode is enabled on an High Availability (HA) controller, the special page footer and replica annotations on such items as running builds and agents is now limited to users with Overall/SystemRead permission, normally meaning only those with Overall/Administer permission unless this permission has been enabled via system property.


Docker images signatures generated by Cosign v2

For versions 2.452.1.1 and later, customers should use Cosign 2.x to verify signed Docker images. For previous versions, use Cosign 1.x.

Resolved Issues

Saving shared cloud from GUI lost WebSocket checkbox

If a shared cloud (as opposed to a single agent) were defined in 2.426.x or previous versions with an inbound launcher and specific launch configuration (particularly the Use WebSocket checkbox and also tunnel and custom work dir settings), configuring and resaving that cloud in the GUI in 2.440.x would silently drop that configuration, potentially breaking a working setup. The issue does not apply to shared clouds configured using Configuration as Code.

This issue is resolved. Newly created clouds (or single agents) do not offer such options.


Thread contention acquiring shared agents

Excessive synchronization in the code running in a controller related to shared agents could lead to heavy thread contention and poor performance.


Inbound shared agents aligned with new Remoting CLI options

Certain options for the inbound agent launcher, particularly the checkbox for WebSocket, were removed from the configuration GUI, in favor of passing the corresponding option such as -webSocket on the CLI. This was not sufficient. In the case of inbound shared agents, this did not suffice since the operations center was responsible for launching the cloned agent that connects to the controller. Adding -webSocket to the agent startup options also did not work since it conflicts with the now deprecated -jnlpUrl. It was possible to use WebSocket shared agents only by configuring this field via Configuration as Code, or REST or CLI upload of XML. This issue is now resolved.

Shared agent usage is now aligned with the new agent.jar CLI recommendations and avoids deprecated options. You can add options such as -webSocket to the command line when connecting the agent to operations center, and should do the same in the agent startup options field. For compatibility, if the deprecated webSocket field was still defined in the agent configuration, the -webSocket option will be added to the cloned CLI; -jnlpUrl also still works for connecting the agent to operations center even though it is deprecated.


Fixed UI inconsistencies between some Configuration as Code (CasC) features and High Availability (HA)

Fixed the issue that was found when using Configuration as Code in controllers that run in High Availability (HA) mode. The CloudBees Configuration as Code Export and Update screen used to display inconsistent information about the bundle along with two buttons: Restart and Reload. This was caused by information not being properly synchronized between replicas.

Users may have experienced the following problems when trying to use one of the two buttons on that page:

  • Automatic reload bundle: Clicking this button displayed an error message.

  • Skip new bundle version: Clicking this button forced a restart, but the instance would not restart.


Duplicate entries from the REST API list of static agents in the High Availability (HA) controller

When querying the REST API for the list of computers on an High Availability (HA) controller, static agents are listed multiple times. Duplicates are now removed if the displayName field is selected, with preference given to a replica that holds the connection to the agent (if any) when the offline field is selected.


Fixed High Availability (HA) compatibility of abort previous builds on pipeline jobs

When using the abort previous builds setting on a pipeline job in High Availability (HA), if a newer builds starts, even if it runs on another replica, the previous build is aborted.


HashiCorp Vault credentials are now replaced by the credentials from Configuration as Code bundles

Prior to this fix, the HashiCorp Vault credentials within a CloudBees CI instance were not removed when applying a Configuration as Code bundle with Vault credentials to that instance.

Now, only the HashiCorp Vault credentials from the CasC bundle are kept. The other credentials are deleted from CloudBees CI (not from HashiCorp Vault).

HashiCorp Vault credentials declared in CloudBees CI that were not part of your Configuration as Code bundles but were used to view credentials from Configuration as Code added to your credentials list, this fix deletes all credentials that are not in Configuration as Code.

In the CloudBees Pipeline Explorer, update the switches display

The preference switches have issues toggling when you click on specific areas. This issue has been fixed by updating the display style.


CloudBees Pipeline Explorer no longer closing the line menu in the log view when the mouse leaves the menu

The menu for each log line in the CloudBees Pipeline Explorer used to close immediately if your mouse left the menu. The menu now stays open until you click anywhere on the page.


Allow External Agents - controller restart can result in loss of JNLP_NODE_* environment variables

In some cases, performing a restart from the operations center of a controller configured with Allow External Agents would result in the controller being provisioned without the associated JNLP_NODE_IP, JNLP_NODE_NAME, and JNLP_NODE_PORT environment variables. This is resolved and all stop/start/restart actions respect the value of Allow External Agents, setting the environment variables accordingly.


Only generate network policies for selected components

When enabled, network policies were generated for all components even if some were disabled via values.

This is now fixed, and network policies resources are now generated only if network policies are enabled and the corresponding component (operations center, controller, Agents, or Hibernation Monitor) is enabled


Error updating the plugin installation report prevent the bundle from being applied

New Configuration as Code bundle versions installing new plugins returned an error when it was reloaded and the new bundle was not applied.

This issue is now fixed.


Network policies behavior fix when installing on AWS EKS

When installing CloudBees CI on EKS with network policies enabled, the recommended setup uses AWS Load Balancer controller with ALB in front of all pods serving web traffic (operations center, managed controller, etc.).

Because ALB keeps the source IP, all inbound traffic to HTTP endpoints must be allowed for the traffic to successfully flow between ALB and pods.

The network policies rules have been updated to use network port numbers instead of port names, as support of port names seems lacking in some network policies implementations. Relying on network port numbers is more compatible in general.

If using NetworkPolicy.Enabled=true and ingress-nginx is set up in a different namespace, you should provide a pod selector. Here is an example if you set it up in the namespace named ingress-nginx.

NetworkPolicy: ingressControllerSelector: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: ingress-nginx podSelector: matchLabels: app.kubernetes.io/instance: ingress-nginx app.kubernetes.io/name: ingress-nginx app.kubernetes.io/component: controller

Known Issues

Failed parsing of data in the User Activity Monitoring plugin leads to incomplete data

Failed parsing of data from the User Activity Monitoring plugin will overwrite the user activity database. All user activity data that is logged up to that point in time is lost, in order to avoid this, refer to this knowledge base article Why is my user activity missing?.


HTTP Client used for Operations Center to Controllers connection leads to performance issues

Because of known issues in the Java HTTP Client, there could be performance issues in Operations Center to Controllers interactions in heavily loaded environments.

More details about this issue and workarounds are documented in Operations Center Client leaks HTTP Clients since version 2.401.1.3.


Some RBAC permissions would not loaded when using the FINE logger


Duplicate Pipeline Template Catalogs in the Configuration as Code for controllers jenkins.yaml file on each instance restart

If a Pipeline Template Catalog is configured in the Configuration as Code jenkins.yaml file and the id property is not defined, the catalog is duplicated on each instance restart and in the exported Configuration as Code configuration.


NullPointerException when validating Kubernetes Cluster Endpoint

When using credentials in the Kubernetes Cluster Endpoints configuration, the Validate functionality shows an Angry Jenkins in the UI and a null pointer exception in Jenkins logs.


Clouds do not disappear after the Folder configuration update by a user without Overall/Administer permissions

Clouds deselect after a user without Administer permissions edits the Folder configuration.


Pod templates page is read-only for NonConfigurableKubernetesCloud

The NonConfigurableKubernetesCloud setting on the pod template page appeared to be editable. However, it is read-only.


Duplicate Plugins in Operations center Plugin Manager UI

When searching for a specific plugin under 'Available' tab in operations center Plugin Manager, the search results shows duplicate entries of the searched plugin.