CloudBees CI on modern cloud platforms 2.528.2.34846

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

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

HA controllers now provide a view of all builds currently running across all replicas. For more information, refer to View running builds in HA controllers.

Previously, when a shared agent was leased to a controller, an outdated agent launcher syntax was used, which resulted in a warning. Now, the recommended syntax is used when leasing a shared agent, except for older agents.

The CloudBees Unified Data plugin was previously installed by default to the operations center and controllers, even though it is only required when a connection is configured to send events to CloudBees CD/RO.

Previously, HA controllers randomly adjusted the start time for scheduled builds by ~30 seconds in either direction to help distribute the work of checking for triggers across all running replicas. Regardless of which replica checks the schedule, the actual builds are always directed to the least-loaded replica. Now, scheduled builds start much closer to zero seconds past the minute, and consecutive builds are more evenly spaced, even for schedules such as * * * * * (once per minute). This change better aligns with the behavior seen in non-HA controllers. Various factors can still delay the triggering of scheduled builds or the allocation of executors after scheduling. If precise timing is required, the job itself should check the system clock and behave accordingly.

A new log feature automatically records a thread dump when a health check execution exceeds 10 seconds (default). This helps diagnose stuck readiness/liveness probes in Kubernetes, where replicas may be terminated on probe failures, preventing analysis. The thread dump threshold is configurable via the Java system property: -Djenkins.health.HealthCheckAction.thresholdTimeout=PT<xx>S (for example, PT30S for 30 seconds).

In High Availability (HA) environments, improper configuration of the Amazon EC2 plugin (ec2) can cause unstable behavior. To help prevent this, the system now displays an administrative monitor if the EC2 cloud is not properly configured. If this administrative monitor is displayed, review your EC2 cloud configuration and correct any issues to ensure stable operation.

Resolved an issue where AWS Backup jobs would fail immediately during uploads to Amazon S3 if an error occurred. With this update, backup jobs now automatically retry uploads, resulting in improved job reliability.

The Deprovision Cluster Operation is not applicable to the Kubernetes controller provisioner. This Cluster Operation was created for older provisioners that are no longer supported in CloudBees CI.

Previously, the operations center CasC folder export could expose SSH private keys in plain text. SSH private keys are now properly protected during export.

In extremely rare conditions, a shared agent (or an agent from a shared cloud) may not have had its lifecycle managed correctly, which could lead to future provisioning issues for that shared agent on the same controller. The shared agent is now properly tracked and managed on the controller.

To enhance security, the Configuration as Code (CasC) Bundle Service now verifies whether any bundle file content in the service pods has been manually modified. If changes are detected, the service automatically reverts them to match the version stored in SCM.

In rare cases, if an error occurred during the tracking of an agent’s usage, the details of this error would be lost. The code now reliably logs any such errors.

Previously, if a replica of an HA controller crashed abruptly, it could take several minutes for other replicas to determine it was safe to adopt its builds. During this period, attempting to view a build that was running on the failed replica (or its sublinks, such as CloudBees Pipeline Explorer) would display an error page. Now, users are redirected back to the job page until the build has been adopted.

Previously, the Pipeline policy rule for non-HA-compatible constructs incorrectly warned about the milestone step, which is now compatible. This warning is no longer shown.

In an HA controller, a race condition could occasionally cause a queue item to be missing from the queue widget for several minutes.

Previously, if an inbound TCP agent attempting to reconnect to a controller encountered a socket connection failure, it could repeatedly retry the same host:port without invoking the full reconnect logic to determine the correct target. In HA controller environments, especially when using an agent on the local network, this could prevent the agent from connecting to a different replica after a build adoption. As a result, reconnection could be delayed long enough for the controller to give up on the agent and abort the build.

Previously, under certain timing conditions, the GitHub status reporter could save changes to a build just after it had completed. Normally, build metadata files are considered sealed once a build is complete. In an HA controller, this could have resulted in wasted processing and a warning in the system log.

Parallel job loading (introduced in CloudBees CI 2.528.1.29783) could have prevented jobs from being loaded if they used certain Authorize Project plugin (authorize-project) or Job and Node Ownership plugin (ownership) features related to identifying a user associated with the job.

When specifying an API Server URL in the controller provisioning configuration without credentials and without namespace, managed controllers are provisioned in the {{default}} namespace instead of the controller namespace.

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.