CloudBees CI on modern cloud platforms 2.426.3.3

Refer to the CloudBees Security Advisory January 24, 2024 for more information.

In a High Availability (HA) controller, under Manage Jenkins > CloudBees CI High Availability, there is now a Script Console link in the sidebar that allows you to run a Groovy script on each replica. The return value is a map of collected results. You can also POST to /manage/highAvailability/scriptText with a script parameter to use this system from automation.

To make it easier to see what is happening with each of the replicas pods of a managed controller, a list of the replica pods with their names is now added to the managed controller management page. This list is visible for both managed controller in High Availability mode and those that are not in High Availability mode. In addition, when a rolling restart is in progress, a message indicating this will be visible on this management page.

It is now possible to use hibernation for controllers configured with High Availability mode.

To avoid potential problems with nonforward-compatible changes to the format of build records, replicas in a High Availability (HA) controller that run an older version of CloudBees CI will decline to load records from builds completed in newer replicas. This makes these newly completed builds temporarily invisible. After a rolling upgrade completes, all replicas continue to load all of the completed builds.

A rolling restart of a High Availability (HA) managed controller no longer marks the initiating replica as being in quiet-down mode that previously displayed a yellow bar where a message was expected. Load balancing avoids scheduling new builds on any replicas in the old replica set as soon as a new replica is available.

When updating the configuration of a HA controller in the operations center, changes are applied directly without requiring an explicit start/stop cycle.

Pipeline Explorer users can now access a panel that shows the builds related to the current build. The tree view also shows the related builds in the stage in which the build was triggered. Related builds include builds triggered in the current build and the build that triggered the current build.

The CloudBees Pipeline Explorer users that have installed the Build Failure Analyzer (BFA) plugin can now access a side panel and view indications that are found after a BFA scan and are also marked in the logs. Users can run manual BFA scans to manage and rerun the scans as needed.

Now it is possible to download the schema files used during the Configuration as Code Bundle validation. It is available through the UI (JENKINS_URL/core-casc-schema-download/) or through the following endpoints:

Introduced an enhancement that allows users to specify custom paths while creating an AppRole in the authentication process. If no path is provided, it will resort to the current default behavior.

When you navigate to the CloudBees Pipeline Explorer from the Pipeline Steps View for a node step and your preferences prevent node steps from being shown, the CloudBees Pipeline Explorer now activates the filter for the stage that contains the node step.

After HA was disabled for a managed controller and restarted, the Deployment was deleted, but then errors prevented the restart from completing and the StatefulSet from being created. This issue has been resolved.

A build that runs in one replica of a High Availability (HA) controller is invisible to other replicas until it finishes. The build metadata can then be edited. These changes are now reflected in all of the replicas.

The garbage collection of old High Availability (HA) cluster logs might try to accidentally clean active logs. This issue is now resolved.

Groovy views in the Kube Agent Management plugin were rewritten to jelly for better performance.

Resources request and limits are now set for the Configuration as Code Bundle Retriever container.

Only some failures were being captured, we have extended the range of exceptions that will be treated and, therefore, perform a rollback on migration in case of error.

The Configuration as Code item deletion report used the active strategy to compute the report instead of the strategy specified in the updated bundle.

Private authentication tokens used by the Configuration as Code bundle retriever to communicate with Operations center were incorrectly wrapped as RSA keys. The keys are now correctly wrapped as HmacSHA512.

The validation log for the CloudBees CasC Client Plugin (cloudbees-casc-client) incorrectly returned the following messages even though the plugin worked properly:

Log files for the Configuration as Code bundle retriever are now written to <JENKINS_HOME>/logs/casc-retriever and they will persist across pod restarts. Additionally, log files are rotated on startup as well as on a daily basis.

Now, when you manually migrate the CloudBees CasC Server (cloudbees-casc-server) plugin from 1.X to 2.X via the UI, the set availability patterns are migrated and preserved in the new version.

If there is an error that tries to perform a checkout operation on a remote bundle store, the REST API and CLI now returns an error message and a cause of the error. Additionally, the response code is set appropriately to indicate an error (HTTP 500 for the REST API and 1 for the CLI).

If the mount name for the KV2 Vault secret engine contained forward slashes ( // ), the validation returned a permission denied error.

The JVM options field was removed from Jenkins OSS. This fix brings it back as a specific configuration field for operations center Shared Agents. At the same time, this makes the launcher configuration homogeneous between Shared Agents and Shared Clouds.

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.

A recent update to the way pod templates were managed caused issues upstream to where the operations center is unable to manage pod templates from the UI. A workaround making updates via the API is still available

When the name of an existing cloud node is updated, the user receives a 404 error after selecting save. This is because the cloud page uses the cloud name as part of its URL. When the user saves the name, Jenkins sends the user to the URL with the old cloud name. Please note that all node changes are successfully saved.

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

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