- A new Freestyle job build step has been added to the operations center to synchronize Configuration as Code (CasC) for Controllers bundles from an SCM repository (BEE-8195)
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 has been improved (BEE-7394)
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.
When upgrading, existing user activity data is automatically migrated. If using the operations center to manage multiple controllers, a cluster operation, API token, and scripts are no longer required to aggregate data or run reports. The operations center automatically aggregates the controller data, stores the existing migrated events, retrieves all new events, and allows you to generate reports from the User Activity dashboard.
For more information, refer to Counting and monitoring user licenses with the CloudBees User Activity Monitoring plugin.
- The CasC for controllers
casc-bundle-listCLI command and
GET casc-bundle/listHTTP API endpoint have been improved (BEE-6351)
casc-bundle-listCLI command and
GET /casc-bundle/listHTTP API endpoint now include
availableForin 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.
- The Java Development Kit (JDK) format for CasC Freestyle jobs has been improved (BEE-7150)
When creating or exporting a CasC
items.yamlfile, the JDK format in Freestyle jobs has been simplified.
The legacy JDK format is backwards compatible and still valid when creating or exporting the CasC
- Increased High Availability (HA) default timeout (BEE-106)
The HA default timeout of 10 seconds was too aggressive for most customers, and frequently resulted in HA failover.
The default timeout has been increased to 30 seconds. You can change the default timeout setting in the Jenkins configuration settings.
- If the Jenkins Configuration as Code plugin was not installed, the CloudBees Configuration as Code export and update screen failed to load (BEE-5523)
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.
This issue has been resolved. If Check for updates is selected, the new version of the bundle is now detected and the update page properly loads. Once the updated bundle is applied, the instance can be safely restarted.
- The operations center and controllers using CasC returned a non-descriptive NullPointerException (BEE-6193)
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.
This issue has been resolved. A validation is now performed before the bundle is loaded and a descriptive error is returned.
casc-bundle/regenerate-tokenHTTP API endpoint did not reset the token in the operations center (BEE-7364)
casc-bundle/regenerate-tokenHTTP API endpoint was called, no response was returned and the token was not properly reset.
casc-bundle/regenerate-tokenHTTP API endpoint now supports the generated bundle ID or the full controller name. The new token is also returned as part of the response if the call ends successfully.
- An updated CasC bundle was loaded without verifying the YAML was valid (BEE-7373)
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.
This issue has been resolved. The CasC bundle is now verified before it is reloaded. If it contains invalid YAML, the bundle is not loaded.
- If an existing CasC controller bundle was updated to use bundle inheritance, the update was not applied to the CasC bundle (BEE-7399)
parentfield in the CasC controller’s
bundle.yamlfile was updated to use bundle inheritance, when the controller was restarted, the parent bundle was ignored and the change was not applied.
This issue has been resolved.
licensingessential properties are no longer exported in the operations center CasC
licensingessential properties were removed from the operations center’s
items.yamlfile, controller item creation may not have been successful.
These properties are no longer exported as part of the current configuration’s
items.yamlfile and you do not need to add the properties to the
items.yamlfile. Both properties are now handled internally.
- Duplicate build steps and post-build steps defined in the CasC
items.yamlfile on each instance restart (BEE-7611)
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.
This issue has been resolved. The build steps now correspond with the build steps defined in the CasC
- The operations center startup failed if controller bundles contained invalid YAML (BEE-7647)
A malformed controller bundle stored in the operations center’s
jcasc-bundles-storedirectory prevented the operations center from starting.
This issue has been resolved. The controller bundle YAML files stored in the operations center’s
jcasc-bundles-storedirectory are now validated. Bundles containing invalid files are ignored and a warning is logged.
- If the
optOutPropertywas included in the operations center CasC
items.yamlfile for controller items, a warning message was displayed and the operations center failed to restart (BEE-7679)
This issue has been resolved. The
optOutPropertyis now configurable in the operations center
items.yamlfile 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.
- An error occurred when exporting a Freestyle job with a
If two Freestyle jobs were created and one of the Freestyle jobs had a
BuildTrigger, when the current CasC configuration’s
item.yamlfile was exported, an error occurred.
This issue has been resolved. The error no longer appears and the items are properly exported. The
BuildTriggeralso now has a threshold for triggering.
- Top-level job properties defined in the operations center CasC
items.yamlfile were duplicated (BEE-8207)
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.yamlfile were duplicated for Freestyle jobs, Organization folders, and properties without a set method.
This issue has been resolved.
- BitBucket Teams API was deprecated, causing scans to stop working (BEE-8087)
Organization scans no longer worked because
teamswere deprecated in the BitBucket Teams API.
The API has been updated to use the new
- Job reloads registered the same trigger event multiple times (BEE-7121)
When you used the
publishEventstep to trigger downstream jobs from upstream jobs, the same trigger event was being registered multiple times.
This issue has been resolved. Now,
WorkflowJobcan only be registered one time.
- Spaces in configuration for
systemdcaused Java startup to fail (BEE-7072)
After upgrading, you may find that Java fails to start, causing an error. This could result from having spaces in the
To configure CloudBees CI to support spaces in the
systemdconfiguration, add the following arguments to the Jenkins service configuration file:
JENKINS_JAVA_OPTIONS+=("-Dkey=value with spaces")
For most RedHat and CentOS distributions, the service configuration file is located at: /etc/sysconfig/cloudbees-core-oc.
- Move/Copy/Promote error (BEE-9464)
Some Move/Copy/Promote operations fail with an error when you attempt to use them between two non-local controllers. When this occurs, Move/Copy/Promote operations do not work for any non-local scenarios until the controller is restarted.
This is a known issue. It will be fixed in a future release. If you experience this issue, please refer to the following knowledge base article for more information and a workaround:
- Folder and Pipeline job properties defined in the operations center CasC
items.yamlfile are duplicated (BEE-8679)
If Reload Configuration is selected from the CloudBees Configuration as Code export and update screen or if the operations center instance is restarted, Folder and Pipeline job properties defined in the operations center CasC
items.yamlfile are duplicated. This will be corrected in a future version.
- RPM package upgrade to
2.303.2.3is creating a new instance (BEE-9139)
After upgrading the RPM package and starting the service, the
JENKINS_HOMEenvironment variable fails to be detected (as well as other environment variables), this causes a new
JENKINS_HOMEto be created in
$user.home/.jenkinsand the service will use that directory to start up. None of the projects and configurations are lost but they are not shown nor available on the new instance.
The workaround is to not upgrade the RPM package but only the
If the RPM upgrade already happened, the recommended path forward is to stop the service and downgrade the RPM. Since the
JENKINS_HOMEcontent has not been modified or upgraded by the service, this data does not need to be restored from a backup taken from before the upgrade (this is usually required when you downgrade the RPM). Then, upgrade the
warfile only to the new version.
This issue has been resolved in release 2.303.2.5.