CloudBees CI release highlights

What’s new in CloudBees CI 2.440.3.7

Watch video

Upgrade Notes

Operations center CloudBees Assurance Program plugin changes since 2.440.2.1

The following plugins have been added to the Operations center CloudBees Assurance Program since 2.440.2.1:

  • CloudBees Platform Insights Plugin (cloudbees-platform-insights)


Controller CloudBees Assurance Program plugin changes since 2.440.2.1

The following plugins have been added to the Controller CloudBees Assurance Program since 2.440.2.1:

  • CloudBees Platform Insights Plugin (cloudbees-platform-insights)


New Features

HashiCorp Vault AWS credentials now supported

The CloudBees HashiCorp Vault plugin now supports AWS credentials.


HashiCorp Vault GitHub App credentials now supported

The CloudBees HashiCorp Vault plugin now supports Vault GitHub App credentials.

Feature Enhancements

Configuration as Code Plugin Management 2.0

The new API version of the CasC Plugin Management offers a smoother experience for users configuring their instances using Configuration as Code and performing activities around plugin management.

The API v2 of Plugin Management improves the user experience by:

  • Simplifying the usage of the plugin.yaml and plugin catalog files

  • Calculating and downloading hard dependencies for listed plugins

  • Generating a report of that lists all installed plugins

Reduction of plugin catalog use in benefit of plugins.yaml file Plugins to install are now all listed in the plugins.yaml file. The Plugin Catalog is only needed for pinning plugin versions.

The listed plugins can be retrieved in different ways:

  • From the Update Center with no additional configuration. This is the default method.

  • From a URL using the proper credentials (if needed).

  • Using Maven GAV coordinates from a repository. The repository configuration is also part of the plugins.yaml file.

  • From a local filesystem.

Dependency Calculation Dependencies are now managed by CasC for CAP and non-CAP plugins. CasC installs all mandatory dependencies for CAP and non-CAP plugins listed in the plugins.yaml file

CasC Plugin Report When you configure your CloudBees CI instance using CasC, a CasC plugin report with all the effectively installed plugins is created in the plugin-installation-report.json file within your $JENKINS_HOME folder.


Added an administrative monitor to warn about usage of CloudBees High Availability retention strategy on inbound agents.

The CloudBees High Availability (HA) retention strategy is only supported for outbound agents (for example, using SSH). It is not supported for inbound agents.

An administrative monitor will be displayed when any agent is incorrectly configured, and a migration task will revert the retention strategy of the impacted agents to "Always".


Display an administrative monitor when the High Availability (HA) setting of maximum load per replica has been exceeded

In a High Availability (HA) controller, it is possible to configure a maximum load per replica that will cause new queue items to be rejected. When the controller has reached that threshold, it now displays an administrative monitor that notes this fact.


CloudBees Pipeline Explorer Feature Enhancements

The CloudBees Pipeline Explorer now uses a special icon for the input steps in the tree view, and displays them in all cases. Also, when an input step is waiting for input, the banner at the top of the CloudBees Pipeline Explorer is now highlighted to draw more attention to it.

Updates have been made to the header and users can now configure the build details display.


Include information about agent launches from other High Availability (HA) replicas in support bundles

The list of support components included in a High Availability (HA) controller now includes the missing log files from the agent launches.


Administrative Monitor is shown if there are non-recoverable errors when checking out controller bundles

A new Administrative Monitor is shown if there are non-recoverable errors when checking out the controller bundles.


Blue Ocean removal

Blue Ocean plugins will soon be removed from CAP. Customers are advised to use CloudBees Pipeline Explorer instead.

Resolved Issues

Pod Templates updates in the operations center are not automatically propagated to controllers

When changes are made to Pod Templates in a Kubernetes Shared Cloud in the operations center, the changes are not automatically applied in the controllers.

The issue is now resolved.


Pipeline Template Catalogs fail to load

After upgrading to CloudBees CI version 2.440.2.1, the global Pipeline Template Catalogs fail to load with a CannotResolveClassException: globalTemplateCatalogManagement. The issue has been fixed.


Fixed excessive memory usage by the Plugin Usage Analyzer plugin

The Plugin Usage Analyzer had a flaw where it held on to all of the Pipeline runs that it wanted to analyze before performing the analysis of their usage. This caused CloudBees CI to use an excessive amount of memory when the analysis was running. This is now fixed by the Plugin Usage Analyzer plugin only holding in memory the pipeline runs of the current pipeline that is being analyzed (a maximum of 5).


CloudBees Pipeline Explorer Resolved Issues
  • CloudBees Pipeline Explorer did not support non-default values for the crumb request field for POST requests Previously, if you modified the default crumb request field, some features in the CloudBees Pipeline Explorer did not work correctly. This included the abort and rebuild buttons and the ability to save user preferences. This issue has been resolved.

  • Build artifacts panel displays an incorrect action button The "Build artifacts" drawer now dynamically loads the correct information.

  • The "Show node steps in tree" preference in the CloudBees Pipeline Explorer always resets to false after a controller restart The "Show node steps in tree" preference in the CloudBees Pipeline Explorer always reset to false after a controller restart. The preference now maintains its configured value across restarts. This issue has been resolved.

  • CloudBees Pipeline Explorer shows redundant context badges in the log view between lines from steps from the same stage If two steps in a stage have more than one line of consecutive log output, the CloudBees Pipeline Explorer shows a redundant context badge between them. Since they are from the same stage, you do not have to display a badge. This issue has been resolved.

  • The "Show steps in stage" feature did not work correctly in the CloudBees Pipeline Explorer The “Show steps in stage“ menu option for stages in the tree view only showed steps that were immediate children of the selected stage, instead of showing all descendant steps as intended. This issue has been resolved.

  • Users' Console URL provider set on a controller could be reset after synchronization with the operations center If a plugin provides an alternate Console URL provider that is only installed on the controller, but not on the operations center, then the Users' Console URL provider settings that are set on the controllers with values provided by that plugin could be reset after synchronization with the operations center.

    This behavior is now corrected.


Fixed AggregatedResultsIcons when security was enabled

If a folder was using AggregatedResultsIcons and the CloudBees CI instance was using any security realm, the icons were not visible.

Now, the icons are visible.


High Availability (HA) controller hibernated immediately after first startup

When you configure hibernation on a High Availability (HA) controller to apply immediately during first startup, by defining it in a Configuration as Code bundle, the controller can mistakenly believe it was quiescent and hibernate itself instead of staying awake pending activity.


Updating controller image via cluster operation did not trigger a rolling restart of the High Availability (HA) controller to apply the new image

When using a cluster operation updating controller image of a HA controller, it is expected that a rolling upgrade will occur automatically. However, it doesn’t.

This condition is fixed. Now, after updating the container image via cluster operation, a rolling upgrade is triggered automatically.


HorizontalPodAutoscaler resource deleted when reprovisioning a High Availability (HA) managed controller

When selecting the Reprovision gesture on an High Availability (HA) managed controller that defined horizontal pod autoscaling (by configuring a distinct minimum vs. maximum replica count); the autoscaling resource was deleted but not recreated leading to the deployment being left at one replica.


High Availability (HA) script console ran scripts as an anonymous user

The High Availability (HA) script console did not work for scripts that required a particular CloudBees CI authentication; for example, to look up a project by name. Now, the Groovy script will run under the logged in user’s authentication.


High Availability (HA) Groovy library migration could break checkout by tag

An administrative monitor on a High Availability (HA) controller warns you if you have configured a Pipeline library to check out to a shared location, and offers to migrate the configuration to use a per-build checkout, including optimizations for the clone technique. If there is a library configured with plain Git, after migration it was not possible to clone a library by tag (as opposed to branch) unless the configurations were manually adjusted to include tags in the advanced clone options. Now the clone options will include tags. The behavior is unchanged for derivative Git-based configurations; at least the GitHub Branch Source plugin is able to clone a library by tag even with clone options suppressing the tag retrieval, since the refspec in that case encodes the tag name.


Silence warnings in a system log for fields with no getters

Periodically, in the logs of a controller, a warning is emitted related to a missing getter. The warnings in a system log for fields with no getters have now been silenced.


Removed a confusing Hazelcast log message when using High Availability (HA)

By default, Hazelcast logs the "The Jet engine is disabled" message on startup. This message can be interpreted as a warning by administrators, prompting for action.

The CloudBees CI High Availability (HA) functionality does not rely on this component, so we have removed it to clarify any confusion.


New pods running previous CloudBees CI versions could be created during HA rolling upgrade

During a rolling upgrade of a High Availability (HA) managed controller, if one of the pods from the old replica set was unexpectedly terminated (for example, because of a crash), it could be replaced by another pod still running the old version, even after newer pods had started. This is now prevented.


BundleUpdateLog continues reading the plugins after removing the bundle

The BundleUpdateLog no longer tries to read the plugins after removing the bundle.


Folder Configuration as Code export is showing SSH private keys in plain text

In the exported YAML, the key privateKeys was showing the SSH private keys in plain text.

This key has been removed from the export.


Failure to install a profile plugin was not always reported

In some conditions, when using a profile to install plugins at startup, if a plugin in the profile cannot be installed as it was not found, the failure may not have been reported correctly in the logs.

Following this change, any failure is reported.

Known Issues

Failed parsing of data in the User Activity Monitoring plugin leads to incomplete data

Failed parsing of data from the User Activity Monitoring plugin will overwrite the user activity database. All user activity data that is logged up to that point in time is lost, in order to avoid this, refer to this knowledge base article Why is my user activity missing?.


HTTP Client used for Operations Center to Controllers connection leads to performance issues

Because of known issues in the Java HTTP Client, there could be performance issues in Operations Center to Controllers interactions in heavily loaded environments.

More details about this issue and workarounds are documented in Operations Center Client leaks HTTP Clients since version 2.401.1.3.


Saving shared cloud from GUI lost WebSocket checkbox

If a shared cloud (as opposed to a single agent) was defined in 2.426.x (or earlier) with an inbound launcher and a specific launch configuration, particularly the Use WebSocket checkbox (also tunnel and custom work dir settings), configuring and resaving that cloud in the GUI in 2.440.x will silently drop that configuration, potentially breaking a working setup.

As a workaround, avoid resaving such shared clouds using the GUI. Use Configuration as Code with YAML or REST or CLI with XML if some unrelated aspect of the cloud needs to be adjusted.


Reconfiguring static inbound WebSocket agent improperly added blank tunnel

After reconfiguring a static inbound agent in the GUI using fields, such as WebSocket, deprecated in 2.440.x, the suggested launch instructions incorrectly include -tunnel (with no argument) even if that field had been left blank.

As a workaround do the following:

  • manually remove -tunnel from the command line before using

  • reconfigure the agent using Configuration as Code YAML or REST or CLI XML to not include the tunnel field


Inbound shared agents aligned with new Remoting CLI options

Certain options for the inbound agent launcher, particularly the checkbox for WebSocket, were removed from the configuration GUI in 2.440.x, in favor of passing the corresponding option such as -webSocket on the CLI. In the case of inbound shared agents or clouds, this did not suffice since the operations center was responsible for launching the cloned agent that connects to the controller. This makes it impossible to create new shared agents or clouds using WebSocket transport via GUI configuration.

As a workaround, configure fields, such as webSocket, in the agent/cloud launcher definition via Configuration as Code YAML or REST or CLI upload of XML; or copy a working agent/cloud item instead of creating one from scratch.


Duplicate Pipeline Template Catalogs in the Configuration as Code for controllers jenkins.yaml file on each instance restart

If a Pipeline Template Catalog is configured in the Configuration as Code jenkins.yaml file and the id property is not defined, the catalog is duplicated on each instance restart and in the exported Configuration as Code configuration.


Error updating the plugin installation report prevent the bundle from being applied

New Configuration as Code bundle versions installing new plugins cannot be reloaded. An error appears and the new bundle is not applied. If the Configuration as Code bundle has new plugins to install, the instance must be restarted.