CloudBees CI on modern cloud platforms 2.492.1.3

CloudBees CI on modern cloud platforms now supports Kubernetes 1.31 on Azure Kubernetes Service, Amazon Elastic Kubernetes Service and Google Kubernetes Engine. With this release, the minimal supported version of Kubernetes is 1.27. For more information, refer to Supported platforms for CloudBees CI on modern cloud platforms.

The triggerRemoteJob step now supports the quietPeriod parameter. A change was also made to the High Availability (HA) emulated build step to propagate quietPeriod to triggerRemoteJob. Previously, quietPeriod was ignored in the High Availability (HA) emulated build step and a warning was shown.

When using a mode awaiting the downstream result, the triggerRemoteJob step now has an option allowAbort: true to abort the downstream build if the upstream build is aborted, permitting a whole tree of work to be cancelled with one gesture. This provides parity with the Pipeline build step.

The CloudBees Pipeline Explorer plugin (cloudbees-pipeline-explorer-plugin) had a hard dependency on the Pipeline: Build Step plugin (pipeline-build-step). This is now optional. If the Pipeline: Build Step is enabled and the build step is used, it will be displayed in the CloudBees Pipeline Explorer. If the Pipeline: Build Step is not in use, it may be disabled or uninstalled.

When running builds in a High Availability (HA) controller, the replica name handling the build appeared in the build logs every time a build was adopted. Being a technical identifier and transient when running CloudBees CI on modern cloud platforms, it did not give the end user much useful information.

The Pipeline build step does not work reliably in High Availability (HA) controllers. The CloudBees CI step triggerRemoteJob can be used as a High Availability (HA) compatible replacement, but rewriting existing Pipeline scripts to make use of it could be troublesome. There is now an option to automatically translate all usages of the build step to the triggerRemoteJob equivalent. Most options and behaviors of the original step are supported. The Pipeline: Build Step plugin can be disabled or uninstalled when you enable the emulation. The High Availability (HA) Pipeline policy rule does not flag usages of build in the Pipeline scripts when the emulation is enabled.

High Availability (HA) only supports aggregations APIs (namely /job/xxx/api/json, /computer/api/json and queue/api/json) with only the /api/json variant and mandatory ?tree parameter, as discussed in the HA considerations documentation. However, the APIs would have returned non-aggregated output if the ?tree was missing or non json variants such as /api/xml or /api/python were invoked. Now, these unintended requests return HTTP 400 bad request with appropriate messages.

Pipeline builds running in a previous controller session are now loaded asynchronously, rather than blocking startup as before, allowing the controller to begin serving traffic. For High Availability (HA) controllers starting from zero replicas (after hibernation or a total outage), builds may be resumed on multiple replicas to balance load. If the Maximum load per replica is exceeded, the resumption of builds are paused until load goes back down. Also, the High Availability (HA) status screen now displays more information about load.

Previously on the $JENKINS_URL/computer and $JENKINS_URL/manage/computer pages, the High Availability (HA) build queue widget incorrectly showed an empty queue even if items were actually enqueued, while on the $JENKINS_URL and $JENKINS_URL/manage pages, the queue was correctly displaying them. All four pages now display the High Availability (HA) build queue widget and list items that have been enqueued.

When you browse workspace links for a running pipeline in another replica, the node link can result in an HTTP 404 not found message. Now, the link leads to the node screen as expected.

In High Availability (HA) controllers, the Manage Jenkins > CloudBees CI High Availability > Script Console page offered an example of usage of the ReplicatedGroovy utility that did not work. The result of each replica’s script must be a serializable object.

When replaying a build in a High Availability (HA) controller and the build gets load balanced to another replica, it could be scheduled with an incorrect sandbox status.

The list of computers/executors in a High Availability (HA) controller included only computers that were already online, or those known to the replica with the sticky session. Agents are now added to the list shared among replicas as soon as the controller starts to launch them.

This fix avoids exposing an internal IP to a caller impersonating an agent node from outside the cluster infrastructure.

Browsing a build workspace through a replica that does not own the corresponding running build resulted in an HTTP 404 error message. Now, files in the workspace can now be accessed from any replica.

While High Availability (HA) controllers supported permalinks such as lastStableBuild, with the link resolving to the newest matching build regardless of the replica it ran on, the cache system was not reliable under heavy load conditions. Now, the cached system is reliable under heavy load conditions.

Previously, the Google Compute Engine plugin (google-compute-engine) CleanLostNodesWork was disabled in High Availability (HA) because it lead to the deletion of active agents in other replicas. Now the CleanLostNodesWork works with High Availability (HA) and is active again.

The implementation of this strategy had a non-concurrent safe caching system that could lead to incorrect results when multiple multibranch projects were indexing at the same time.

On a High Availability (HA) controller with multiple permanent agents (including the case of a single editable agent with multiple High Availability (HA) executors) using an outbound launcher, if two queue items asked for the same label at about the same time (for example, in parallel blocks of the same build), only one agent would be launched; the other items would remain in the queue despite available offline agents for up to a minute. Now, many agents are needed to launch the workload immediately.

To support FIPS, CloudBees CI Docker images were updated to enforce RedHat™ patches. However, these enforcements were mistakenly applied to non-CloudBees CI Docker images. These patches are now disabled.

Configuration as Code (CasC) did not allow defining more than one object in the navigators list of an organization folder. This differed from the GUI configuration options. Users can now define more than one SCM navigator.

The Link Pod Templates - Kubernetes clouds in this controller was offered to manage permission users, but the destination Cloud page was only available to admin users, leading to a non permission error. Fixed the link to only appear in case the user has administration permission.

Fixed a regression where scm.userRemoteConfigs[0].credentialsId was null due to a previous security fix.

The Configuration as Code Bundle Retriever service no longer fails to start on OpenShift due to permission issues.

The Configuration as Code Bundle Retriever was not accessible from outside of the Kubernetes cluster on OpenShift because it was missing a route and network policy.

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.

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

CloudBees CI users running versions 2.479.1.4, 2.479.2.3, and 2.479.3.1 with the Firefox web browser will be unable to unpack compressed tar archives with the .tgz suffix due to a bug in Eclipse Jetty 12.0.0 through 12.0.14. The issue has been fixed in Eclipse Jetty 12.0.15 and will be included in a future release of CloudBees CI.