CloudBees CI on traditional platforms 2.303.2.3

A new Synchronize bundles from workspace with internal storage build step has been added to Freestyle jobs in the operations center to synchronize controller CasC bundles from an SCM repository when bundles are added, updated, or deleted from the SCM tool. This build step eliminates the need to use an Execute shell build step with custom scripts to synchronize the CasC bundles. For more information, refer to Loading controller CasC bundles from an SCM tool to the operations center.

The User Activity Monitoring plugin is now installed automatically to the operations center and controllers and aggregates user activity data from connected controllers in the operations center. The User Activity Monitoring plugin also tracks usernames and emails, allows you to filter activity based on a specified number of days or months, and performs basic user deduplication automatically.

The casc-bundle-list CLI command and GET /casc-bundle/list HTTP API endpoint now include usedBy and availableFor in the response, to list the names of controllers currently assigned to the CasC bundle and controllers that can be assigned to a CasC bundle based on the bundle’s availability pattern, respectively. For more information, refer to Configuration as Code (CasC) CLI and Configuration as Code (CasC) HTTP API.

When creating or exporting a CasC items.yaml file, the JDK format in Freestyle jobs has been simplified.

The HA default timeout of 10 seconds was too aggressive for most customers, and frequently resulted in HA failover.

If the Jenkins Configuration as Code plugin was not installed and Check for updates was selected from the CloudBees Configuration as Code export and update screen, the update page failed to load.

If any of the files in a CasC bundle were renamed and the updated bundle was loaded to the operations center or a controller, a non-descriptive NullPointerException was returned.

When the casc-bundle/regenerate-token HTTP API endpoint was called, no response was returned and the token was not properly reset.

If a CasC bundle was updated and Reload Configuration was selected from the Configuration as Code export and update screen, the bundle was loaded without verifying if the YAML was valid, potentially resulting in an inconsistent bundle state.

If the parent field in the CasC controller’s bundle.yaml file was updated to use bundle inheritance, when the controller was restarted, the parent bundle was ignored and the change was not applied.

If the cascBundleToken and licensing essential properties were removed from the operations center’s items.yaml file, controller item creation may not have been successful.

When a Freestyle job item was created using CasC, the build step and post-build step were duplicated on each instance restart and in the exported CasC configuration.

A malformed controller bundle stored in the operations center’s jcasc-bundles-store directory prevented the operations center from starting.

This issue has been resolved. The optOutProperty is now configurable in the operations center items.yaml file for controller items. If the operations center CasC bundle is updated and Reload Configuration is selected from the Configuration as Code export and update screen, a warning is no longer displayed and the operations center properly restarts.

If two Freestyle jobs were created and one of the Freestyle jobs had a BuildTrigger, when the current CasC configuration’s item.yaml file was exported, an error occurred.

If Reload Configuration was selected from the CloudBees Configuration as Code export and update screen or if the operations center instance was restarted, job properties defined in the operations center CasC items.yaml file were duplicated for Freestyle jobs, Organization folders, and properties without a set method.

Organization scans no longer worked because teams were deprecated in the BitBucket Teams API.

When you used the publishEvent step to trigger downstream jobs from upstream jobs, the same trigger event was being registered multiple times.