CloudBees CI on modern cloud platforms 2.504.1.6

As previously noted in the 2.492.2.2 release, starting with this release, the YahooUI library has been removed. This may cause user interface rendering issues with custom or unmaintained community (Tier 3) plugins.

SDA Analytics kept support for some SCM plugins that were not in CloudBees Assurance Program, including Subversion (subversion), Mercurial (mercurial), Gitea (gitea), and multi-SCM (multiple-scms). They are now removed.

A new service has been added to CloudBees CI. The Configuration as Code controller Bundle Service reduces operations center load and avoids a single point of failure. By using this new service, users can now offload Configuration as Code bundle distribution from the operations center to a dedicated service for better performance and reliability. It is built-in with the Helm chart, making it easily enabled during installation, with seamless integration into the user’s CloudBees CI environment.

The /label/$name/ page on a High Availability (HA) controller displayed inconsistent results. This depended on which replica hosted the sticky sessions and which replicas agents were connected to. Now, this page displays all permanent or cloud agents defined in the controller, with their online/offline status icons, regardless of which replica handles the request.

Managed controllers now offer a new health check endpoint. This allows for more reliable failure detection, particularly for High Availability (HA) controllers. Enabling this new option is recommended for any controller running the same version as operations center.

Quiet Down mode in a controller prevents the acceptance of new builds. This mode is useful when restarting the controller. However, in a High Availability (HA) controller, one replica is always available (restarts are managed by rolling restart). As such, Quiet Down mode isn’t required, so the synchronization of the Quiet Down status among replicas isn’t performed. Quiet Down mode is maintained for backward compatibility with non-High Availability (HA) controllers. Now, an administrator monitor appears to the user when they put a replica in Quiet Down mode.

CloudBees CI on modern cloud platforms now attempts to detect that Pod Security Standards (PSS) are enforced in the Kubernetes cluster. If PSS is not enforced in the Kubernetes cluster, an administrative monitor is displayed in CloudBees CI. For more information, refer to Pod Security Admission for CloudBees CI on modern cloud platforms.

Previously, the CloudBees Pipeline Explorer plugin (cloudbees-pipeline-explorer-plugin) had a hard dependency on the Operations Center Context plugin (operations-center-context). This is now optional. If features that are supported by the Operations Center Context plugin are not in use (for example, the triggerRemoteJob Pipeline step), the Operations Center Context plugin may be disabled or uninstalled.

CloudBees CI no longer supports the older versions of Kubernetes which supports PodSecurityPolicy. Therefore, usage analytics about PodSecurityPolicy are no longer useful.

The appearance of table elements has been updated to align with recent improvements to the Jenkins UI.

When a Pipeline build completed High Availability (HA) controller, the workflow-completed/flowNodeStore.xml file was written by the replica managing the build. Other replicas were notified that they could now load the completed build. However, they weren’t instructed to wait until the expected timestamp of this file was observed. This could lead to problems loading the build from other replicas, depending on the file system (such as NFS).

When using many permanent outbound agents on High Availability (HA) controllers , the recommended CloudBees High Availability retention strategy experienced a performance issue at high scale. This issue caused excessive CPU usage and could even cause queue processing to hang.

When adding, updating, or removing nodes in a controller, the retention strategies of all other nodes were checked.

On a High Availability (HA) controller with multiple builds of a given job running across multiple replicas, the Next and Previous buttons in CloudBees Pipeline Explorer would only navigate among completed builds or builds running on the replica hosting the sticky session. Now, these links reflect the newest build older than the displayed build, or the oldest build newer than the displayed build, respectively, even on High Availability (HA) controllers.

During a rolling upgrade of a High Availability (HA) controller connected to operations center, a race condition could occur when the replica connected to operations center shuts down. The remaining replicas, detecting the connection as offline, would simultaneously attempt to switch to the fallback security realm via SecurityEnforcer#useFallbackIfOffline.

The managed controller’s URL is displayed only after the underlying pod is ready and the load balancer registers routing. Previously, users were shown the URL immediately after provisioning. Navigating to the URL at that point could result in a 503 Service Unavailable error until the initial pod readiness process was completed. Now, users remain on the provisioning page where the live pod status is visible. This change prevents premature redirection and improves clarity during startup.

The High Availability (HA) retention strategy no longed does unnecessary checks when shutting down a replica.

If the High Availability (HA) controller replica were already terminating, operations relying on Hazelcast availability would fail and generate unnecessary exceptions.

When configuring an inbound permanent agent on a High Availability (HA) controller with multiple HA executors, the main (Status) page of the agent, when offline, displayed incorrect instructions for connecting it. These instructions were inappropriate because you should connect only directly to the main agent.

Users should connect only to the original agent when configuring a multi-executor inbound agent on a High Availability (HA) controller. This agent automatically launches additional processes to handle the extra executors. Previously, this constraint wasn’t enforced, which could result in duplicated processes or other unexpected behavior. Now, direct attempts to launch any executor other than the original agent are blocked.

When applying a rolling restart to a High Availability (HA) controller, some replicas could briefly switch to the offline backup security realm.

The Backend Status section of a non-HA managed controller’s manage page incorrectly displayed Statefulset 1/1 replicas even when the controller pod was not ready. This issue is now resolved. The section now displays Statefulset 0/1 replicas until the pod is ready and changes to Statefulset 1/1 replicas when the pod is ready to serve traffic, updating with a live page refresh.

When writing Pipeline build logs, CloudBees Pipeline Explorer also writes a log-metadata file, which contains information used to support various CloudBees Pipeline Explorer features. Errors when writing logs or restarting CloudBees CI may result in this metadata becoming out of sync with the main log file.

Controller Lifecycle Notifications can cause thread spikes and memory issues when managing a large number of controllers. To avoid such issues, the maximum number of parallel http requests is now limited by default.

When the global configuration of the CloudBees Hashicorp Vault plugin contains a trailing slash (/) in the Vault URL, the request to revoke the self client token fails. The token is not revoked and the Jenkins logs are spammed with Revoke self client token error errors.

If a plugin catalog was used to install non-CloudBees Assurance Program plugins to a controller, the CloudBees Update Center may have incorrectly indicated that a new version of the plugin was available for installation, when the catalog’s version of the plugin was already installed to the controller.

Fixed a resource naming inconsistency where the Red Hat OpenShift service exposure resources were named incorrectly. This also resolves an issue that prevented the resources from displaying properly in the UI.

When you search for a specific plugin under the Available tab in the operations center Plugin Manager, the search results show duplicate entries for the plugin.

If a managed controller is installed in its own namespace and Agents.SeparateNamespace.Enabled=true is passed to the Helm chart or included in the custom values file, all agents will run in the cbci-builds namespace by default, where cbci is the namespace of the operations center, and the agents are not installed in a namespace corresponding to the managed controller. This also prevents agents with service accounts from being installed in a namespace corresponding to the managed controller, and could potentially lead to security vulnerabilities since a managed controller admin could tamper with agents for another managed controller.

Under certain conditions, after applying a new Configuration as Code Bundle without restarting the controller (using the Reload Configuration option), users might see the following message in the Manage Jenkins section of the affected controller:

When upgrading or restarting CloudBees CI, the controller or operations center fails to start and returns a Messaging.afterExtensionsAugmented error. The operations center can also fail to start with an OperationsCenter.afterExtensionsAugmented error. Refer to CloudBees CI startup failure due to IndexOutOfBoundsException related to corrupt messaging transport files for a workaround for this issue.