CloudBees CI on modern cloud platforms 2.492.2.2

Starting with this release, the YahooUI library will be disabled by default. This may cause user interface rendering issues with custom or unmaintained community (Tier 3) plugins.

When using the trackProgressAwaitResult mode of the triggerRemoteJob Pipeline step, the build number of the downstream job was not recorded in metadata used by build visualization tools, such as CloudBees Pipeline Explorer, until the downstream build completed. Now, the build number of the downstream job is available in metadata once the downstream job starts, as long as the job starts within the configured startedTimeout time span for the step, which now defaults to one hour.

The CloudBees CI search feature has adopted the keyboard shortcut search changes in Jenkins, to focus the search box using CMD+K (on macOS) or CTRL+K (on Windows/Linux).

The Elasticsearch Reporter plugin previously used the SHA-1 hashing algorithm, which was considered insecure. The plugin now uses the SHA-512 hashing algorithm for signature.

You can now store the master.key file in a custom location, and configure the system to fail if the file is not found.

Replicas of a High Availability (HA) controller should terminate quickly when requested so that replacement replicas can take over. A recent fix in Kubernetes tightens the default termination grace period for an High Availability (HA) controller to 30 seconds. Now, if a replica fails to exit within 15 seconds, a thread dump is printed to the system log. Users can capture the thread dump for analysis, for example, if they are streaming Kubernetes pod logs.

When users select the button to generate a new support bundle, the bundle is generated in the background, and a progress bar is displayed. The browser no longer blocks while waiting for the bundle to generate, which can take some time. The browser prompts the user to download the support bundle ZIP file once the generation is completed.

Previously, the support bundle separated logs for each replica into individual files. This setup can be cumbersome when debugging High Availability (HA) issues. All replica logs are now displayed in an aggregated file to simplify this process. Each log entry includes a tag identifying the replica from which it originates. This change significantly improves the diagnosis and resolution of High Availability (HA) issues.

Previously, under specific conditions, JUnit-format test results in a Pipeline build running in an High Availability (HA) controller may be malformed. This caused CloudBees Pipeline Explorer to throw an error and block the display of the build results.

Previously, exporting Configuration as Code configurations on High Availability (HA) controllers not configured using a CasC bundle resulted in a NullPointerException error. Now, users can export Configuration as Code configurations without any problem.

Within High Availability (HA) controllers, links to agents connected to replicas other than the one holding the sticky session are handled via a reverse proxy. This reverse proxying failed when the agent URL included the manage/ infix, as is typical of links from the Manage Jenkins screen.

In the 2.452.2.3 (June 2024) release, the Java HTTP client used by controllers to make specific requests to the operations center was changed to a different implementation. The new implementation imposed a 10-second timeout on all requests. This timeout was too short for the operations center to serve some responses, especially during shared agent provisioning under certain circumstances. While the operations center would eventually respond, the controller would time out quickly and report a non-specific network error.

The shared agent provisioning client in a controller using HTTP transport (mandatory in High Availability (HA) controllers, but used by default on non-High Availability (HA) controllers did not properly handle provisioning failures from operations center, such as a lack of capacity for a given label despite its earlier reported availability. While the controller would recover, it first printed a verbose stack trace to the system log, obscuring the original failure details and potentially misleading users into thinking a more serious issue had occurred.

Previously, if a controller or a replica of an High Availability (HA) controller had leased all shared agents (or agents from a shared cloud) matching a given label, a different controller or replica of the same High Availability (HA) controller may be told by operations center that this label cannot be provisioned using the shared agent system.

Builds using the triggerRemoteJob step displayed incorrect links to downstream builds in the logs, missing the mandatory trailing slash. On a High Availability (HA) controller, when the downstream build was running on other replicas, this caused an HTTP 404 (Not Found) error. These links are fixed and redirect to the downstream jobs without showing any error.

When the Jenkins CLI build command triggered a build in a High Availability (HA) controller using the -f (follow) option, the CLI displayed an error even when the build started in the controller. This behavior was confusing, as users were unsure whether the build failed to launch or the build CLI command failed on the client side. This issue is now resolved. The CLI build command works with High Availability (HA) controllers the same way it works with any Jenkins or CloudBees CI instance.

The controller-side code to track shared agents worked under normal conditions on High Availability (HA) controllers but could experience occasional file corruption or logical errors under heavy load.

If users edit a completed build (for example, adjusting the description) in an High Availability (HA) controller, and this build includes test results published by the junit plugin, under certain circumstances, attempts to inspect that build from a sticky session running on another replica could result in errors.

The replicas/exited/ directory, which contains relevant data related to exited replicas, now displays in the High Availability (HA) support bundles.

When a permanent Windows WebSocket agent with multiple executors is connected to an High Availability (HA) controller using java.exe, some conhost.exe processes are launched. When the main agent is disconnected and reconnects, it searches for existing Java processes corresponding to cloned executors. This search mistakenly matched conhost.exe processes, sometimes causing confusing messages about multiple processes already running for a given agent (executor) in the launch logs of the primary (configurable) agent.

Under some conditions, an High Availability (HA) controller replica proxying a WebSocket agent connection to another replica might produce an HTTP 502 Bad Gateway error. Due to an error, the replica instead produced an HTTP 500 error and printed a confusing stack trace in the controller log.

The Stage View plugin (pipeline-stage-view) displayed incorrect links to builds missing the required trailing slash (/). On an High Availability (HA) controller, this could result in HTTP 404 (Not Found) errors or other issues when the build was currently running on a different replica than the one serving the sticky session for the user.

Fixed incorrect credential coding for tokens as all the credentials were getting encoded instead of only encoding Basic Authentication credentials. This resulted in authentication failures from JFrog Artifactory, when using access tokens (JWT) or access reference tokens (base64).

When setting the WorkspaceLocatorImpl\$Deleter.CLEANUP_THREAD_LIMIT property, the set thread limit would increase over time as branch jobs were removed due to some incorrect logic. This could cause high thread counts in high load environments. This issue is now fixed, so the thread limit no longer increases and stays at the value initially set for the property.

On the System configuration page, the CasC Items configuration section was renamed CasC Variable Resolution Configuration and the context-sensitive help to enable or disable the variable resolution was updated to include Role-Based Access Control.

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 show duplicate entries for the plugin.