CloudBees CI on modern cloud platforms 2.555.2.36753

CloudBees CI Windows agent images based on nanoserver-1809 are no longer available. If you use Windows agent images, update your configuration to use images based on nanoserver-ltsc2019.

Starting with this release, CloudBees CI on modern cloud platforms now supports Red Hat OpenShift 4.20 and 4.21 and Azure Kubernetes Service (AKS) 1.35. For more information, refer to Supported platforms for CloudBees CI on modern cloud platforms.

The Configuration as Code (CasC) definition for the CloudBees Unify connection configuration has changed. This change applies to both single-controller and multi-controller integrations. If you use CasC to configure the CloudBees Unify integration, you must update your jenkins.yaml file.

The following plugins have been added to the operations center CloudBees Assurance Program since 2.555.1.36488:

The following plugins have been added to the controller CloudBees Assurance Program since 2.555.1.36488:

The CloudBees CI MCP Router is now generally available (GA). The CloudBees CI MCP Router connects MCP-compatible tools (for example, Claude Code, GitHub Copilot, Amazon Q Developer, and Goose) to CloudBees CI, enabling you to securely access and manage jobs, builds, and resources across your CloudBees CI environment.

CloudBees CI on modern cloud platforms support of Kubernetes Gateway API for traffic routing is now generally available (GA). Gateway API replaces Ingress-based routing with HTTPRoute resources managed by a shared Gateway.

When using operations center SSO, users are opted in to metadata synchronization by default, meaning CloudBees CI automatically propagates most user properties (with a few fixed exceptions) from the operations center to the controller on every sign-in. This caused confusion for users trying to configure API tokens directly on the controller. The API token configuration section in the user security page now displays a notice that API tokens must be configured in the operations center when synchronization is active.

The Skip next build feature now has an option to allow builds to be scheduled but block them from running until the skip expires or is removed. This option is available for jobs, folders, and skip groups via a new checkbox when activating the skip.

CloudBees CI and Jenkins controllers now send all data to CloudBees Unify through a single integration, including controller metrics, system health, plugin usage, build data, and test results. Previously, two separate plugins were required: the CloudBees Platform Insights plugin for dashboard metrics and the CloudBees Platform Integration :: Controllers plugin for build data, each requiring separate installation, configuration, and authentication on every controller.

When an agent template is configured with a startup script, CloudBees CI did not wait for the startup script to complete before making the provisioned agent available to the controller. CloudBees CI now waits for the startup script to complete successfully before marking the agent as ready.

The Google Compute Engine plugin (google-compute-engine) now supports disk mapping for agent VMs. Previously, only a single boot disk was supported. With the new Disk Mapping option (diskMapping in Configuration as Code), you can attach one or more secondary disks to agent VMs. You can attach disks in any of the following ways:

High Availability (HA) controllers do not support the Jenkins core “quiet down” / “prepare for shutdown” mode, but they now support features of the CloudBees Skip Next Build plugin (skip-plugin) that offer equivalent functionality. The administrative monitor in the Jenkins core mode has been updated to reflect this alternative.

When using the Google Compute Engine plugin (google-compute-engine) in High Availability (HA) controllers, some configurations are required, as detailed in HA and the Google Compute Engine plugin. A new administrative monitor validates these configurations and can automatically apply the required fix.

Three plugins supporting CloudBees Analytics, an older integration between CloudBees CI and CloudBees CD/RO, have been updated to clarify that they are not related to CloudBees Unify. The plugin metadata and documentation now explicitly state that these plugins are not part of the CloudBees Unify integration.

Aborting a remote job from upstream could fail intermittently, causing the downstream job to continue running. Remote jobs now abort reliably when triggered from upstream.

On occasion, an item configuration file such as $JENKINS_HOME/jobs/folder/jobs/item/config.xml was missing, perhaps due to an earlier failure to delete the job. This prevented the item from loading and printed a warning during startup. Such malformed item directories are now moved aside during startup, so long as the directory timestamp is at least a day old, preventing warnings and delays on subsequent restarts.

Previously, when an OpenID Connect (OIDC) identity provider returned an error (such as access_denied), the CloudBees SSO Relay Service failed because the code parameter was null and incorrectly treated as required. This resulted in a JSON error response to the browser, which could not process it, breaking the authentication flow. Now, the code parameter is optional, and OIDC error parameters (for example, error and error_description) are forwarded as query parameters in the redirect back to CloudBees CI, where pac4j handles them gracefully.

Previously, a race condition in Configuration as Code (CasC) bundle ID generation could produce empty/blank bundle IDs that were persisted in access control entries. During the next polling sync, a blank entry resolved to the bundle store root directory, causing the entire cb-casc-bundles-store directory to be recursively deleted.

When using an outbound permanent agent with multiple replicas in a High Availability (HA) controller, changes to the launcher configuration were not reliably applied during the next executor launch. Launcher configuration changes are now applied consistently across all replicas.

When a problem occurred deleting a child of a computed folder, such as a branch project inside a Multibranch Pipeline folder, CloudBees CI printed the error to the branch indexing log, which was overwritten after the next index refresh. CloudBees CI now logs these errors to the system log, where they are accessible to administrators and included in support bundles.

Previously, in certain error conditions, a corrupt Pipeline build could remain indefinitely in the list of running builds. This could lead to issues such as high memory usage. Now, Pipeline builds that started more than a certain amount of time ago (by default, 30 days) will not be resumed and will be marked as aborted. This change helps prevent resource leaks caused by builds that never terminate cleanly.

Previously, under certain timing conditions, a High Availability (HA) controller could throw a NullPointerException from AgentOwnership.OnNodeOwnershipImpl during startup. This exception is no longer logged.

When the Pipeline: Declarative plugin (pipeline-model-definition) was not enabled, attempts to run a Declarative Pipeline (pipeline {…}) would silently succeed. Now an error is printed, as if a Pipeline step is missing.

Private keys stored in HashiCorp Vault without a trailing newline caused the sshagent Pipeline step to fail with error in libcrypto or invalid format when using a HashiCorp Vault SSH Private Key credential. Now, keys returned by getPrivateKeys() always end with a newline, matching the behavior of the SSH credentials plugin (ssh-credentials).

Previously, Pipeline scripts using SimpleTemplateEngine or GStringTemplateEngine with the default constructor leaked a GroovyClassLoader per build. These leaked classloaders were parented to the Jenkins core classloader and were invisible to cleanUpHeap. Constructor calls are now intercepted to parent the classloader under the Pipeline hierarchy, allowing normal cleanup.

When a controller attempted to load a Pipeline build from disk but failed to reconstruct its flow graph (list of stages and steps), CloudBees CI saved the original metadata and replaced it with a placeholder indicating the metadata was broken and could not be used. However, under some circumstances, the cleanup and replacement process caused worse problems, such as deadlocks, than it solved. The placeholder system is now disabled by default. Persistent metadata corruption in a build is now displayed as-is when viewing the build, without further changes to disk.

The Manage Old Data monitor lists Jenkins objects with fields that could not be loaded from XML due to plugin changes. Previously, this included global configuration, jobs, users, and builds. Including builds could cause severe performance problems in some cases. Build records are now omitted from the monitor.

High Availability (HA) controller stop and deprovision operations failed to delete Kubernetes resources added via the UI or Configuration as Code after the controller started. All custom resources added after startup are now properly cleaned up during stop and deprovision operations.

The operations center Role-Based Access Control (RBAC) roles were missing the watch verb on serviceaccounts and rolebindings. During deprovisioning, the fabric8 client may need to watch these resources to confirm their deletion. On clusters with higher API latency, this omission caused 403 Forbidden errors, which aborted the cleanup chain and reported deprovisioning as failed. The required watch verb has been added to prevent these intermittent failures.

High Availability (HA) controllers running external Kubernetes agents routed into the cluster via WebSocket record the sticky session cookies produced by the ingress and use them to optimize subsequent connections, allowing agents to connect directly without a reverse proxy via another replica. Previously, this logic was limited to a single cookie due to a limitation in the Remoting launcher script. This limitation has been resolved as of jenkins/inbound-agent:3355, which is now included in CloudBees CI. This release also includes fixes for WebSocket agents routed through Istio Gateway.

Inclusion of a job or folder in a skip group can now be configured more concisely via Configuration as Code in items.yaml. Additionally, per-job and per-folder skips can now be defined via Configuration as Code, including an absolute timestamp for the expiration.

When using skip next build groups in a High Availability (HA) controller, other replicas did not reliably reflect changes to skip group definitions.

Previously, changes to certain global settings on an High Availability (HA) controller (for example, manipulating the activity of skip groups) were not always propagated to other replicas if the resulting XML returned exactly to a previous value. This has been resolved.

Previously, the initial greeting sent to Slack when a build completed did not indicate the outcome of the build. Due to changes in Slack behavior, the notification in the UI no longer showed whether the build was successful unless you selected Details. The greeting now includes the same header text and leading status icon shown in other parts of the UI since CloudBees CI 2.541.3.36065, making the build outcome immediately visible in Slack notifications.

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.