CloudBees CI on modern cloud platforms 2.492.3.5

With this release, the jsoup API plugin (jsoup-api) is now part of the CloudBees Assurance Program envelope. This plugin was added to CloudBees Assurance Program because of the Analysis Model API (analysis-model-api) plugin dependency on jsoup. The Analysis Model API plugin was also added to CloudBees Assurance Program.

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

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

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

Some steps in a Jenkins pipeline can’t resume after a controller restart. If one of these steps fails, the build log displays a SynchronousResumeNotSupportedException error.

The High Availability (HA) status page now displays the up-time for the High Availability (HA) cluster. This indicates how long the cluster has been running with one replica.

When the High Availability (HA) plugin is active, the com.cloudbees.jenkins.replication.warhead.ReplicationServletListener.enabled property should be set to true. This property might have a different value if not configured when starting a High Availability (HA) replica in a traditional setup. Alternatively, in a modern setup, the controller might have been in High Availability (HA) mode but was migrated to non-High Availability (HA) mode without disabling or uninstalling the High Availability (HA) plugin. A warning now appears for these inconsistencies.

Previously, Pipeline Milestone steps didn’t work in High Availability (HA) controllers with multiple replicas. The milestone step is now fully compatible with controllers running in High Availability (HA) mode.

A new admin monitor alerts Jenkins administrators if the controller receives duplicate GitHub events. Although duplicates don’t affect functionality, they slightly increase performance overhead.

In CloudBees Pipeline Explorer, the contextual menus in the log view, map view, and filter by tree view panel have been refactored to improve the user experience.

The CloudBees CI Groovy Checkpoint plugin (workflow-cps-checkpoint) now supports restarting a build from a checkpoint directly from CloudBees Pipeline Explorer.

CloudBees Pipeline Explorer now supports restarting a build directly from a stage in the log view and map view.

New radio buttons have been added to allow users to explicitly choose the source when provisioning a new connected controller through Configuration as Code. Users upgrading from a previous version of the plugin will have their configuration migrated automatically.

managed controllers are now created by default with fsGroupChangePolicy set to OnRootMismatch. This change prevents unnecessary file ownership changes, improving startup time.

Previously, when you made configuration changes to a managed controller from the operations center, the license information was checked and updated synchronously if required. This caused delays in form submissions, especially under high load. Now, the license check and update process is asynchronous, which improves responsiveness.

The support bundle generated for controllers running in High Availability (HA) mode now includes all rotated custom logs. The rotated logs are merged and aggregated, with each entry tagged by the replica name.

The plugins.yaml file handled file:///path/to/plugin.jpi URLs but not the equivalent file:/path/to/plugin.jpi URLs. It might also have mishandled URL encoding paths with spaces or other meta characters.

Under specific circumstances, complex Pipeline builds could fail to resume after a controller restart, resulting in a StackOverflowError in deserialization code. This issue stemmed from excessive nesting of program objects, especially when using Declarative syntax.

When a High Availability (HA) controller replica exits, any builds it was running are offered for adoption by other replicas. Any agents currently in use by that build remain reserved for it. If the adoption process is slow (for example, if the build record takes a long time to load), a permanent (non-cloud) agent occupied by that build might incorrectly be considered available for other builds. This could result in workspace corruption as unrelated tasks run. If several minutes pass, the original build might abort.

On a HA controller, when a job configured to disable concurrent builds started a new build, a second build could sometimes be scheduled after the first build completed. Now, duplicate builds no longer occur.

If the CloudBees Pipeline Explorer tree view was filtered and then manually closed, a display issue could occur after a refresh (either a manual refresh or a refresh due to auto-polling) that prevented the tree view from displaying.

When opening a contextual menu from a CloudBees Pipeline Explorer stage, a browser error related to an aria-hidden attribute may have been returned. This issue has been resolved.

A build display issue has been fixed for downstream builds in the CloudBees Pipeline Explorer map view.

In CloudBees Pipeline Explorer, copying the URL or log content to the clipboard now works correctly, even after selecting and then deselecting a line or range of lines in the log view.

If controllers were configured to use Websockets to connect to the operations center and the controllers or operations center were restarted, the controllers may not have automatically reconnected to the operations center and an error may have been returned. This was due to an asynchronous call when establishing the channel, that resulted in a race condition between closing the channel and reinitializing. Upon connection request, controllers now successfully reconnect to the operations center, and an error is no longer returned.

Previously, the Operations Center Context plugin (operations-center-context) may have used temporary directories with weak file permission to transfer files. This issue has been resolved. Appropriate file permissions are now enforced for temporary directories to transfer files.

When using CasC 2.0 (apiVersion:2.0), if there are non-CloudBees Assurance Program plugins installed on the controller using the plugin.yaml file, the plugins are no longer unnecessarily downloaded every time the CasC bundle is applied.

User properties were propagated from the operations center to controllers when signing in with a username and password using SSH. However, this did not occur when interacting with controllers that used a username and an API token. Therefore, for non-interactive users (for example, service accounts) that only called the Jenkins API using API tokens, if the operations center was unavailable, these service accounts could no longer sign in to controllers. This issue has been resolved, so user data propagation is now also performed when using API tokens.

The GitHub plugin configuration failed to load during the operations center startup. Refer to GitHub Plugin settings not loaded on startup after upgrading for more information.

Previously, the Shared Clouds UI permitted configuration renaming, although it was unsupported. This caused errors. The UI is now fixed and configuration renaming is no longer supported.

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.

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.