CloudBees CI on traditional 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.

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.

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.

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 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.

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.

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.

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.