CloudBees CI release highlights

What’s new in CloudBees CI 2.426.3.3

Watch video

Security fixes

Security vulnerabilities were fixed and backported from Jenkins

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

New Features

Cross-replica script console

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.

Feature Enhancements

Display replicaset summary in managed controller management page

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.


Support hibernating High Availability (HA) controllers

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


Rolling Upgrades with High Availability (HA)
  • Proxy configuration screens to new replicas during a rolling upgrade

    When performing a rolling upgrade of a High Availability (HA) controller, some replicas may run newer versions of CloudBees CI. If a user’s web session is still associated with an older replica, all configuration pages are now transparently redirected to a newer replica.

  • Configuration synchronization blocked from newer to older replicas

    In a High Availability (HA) controller controller during a rolling upgrade, any configuration changes that occur on newer replicas are no longer reloaded by older replicas. The configuration changes will continue to be synchronized from older to newer replicas, or with replicas that have the same versions.

  • Builds adopted by older HA replicas during rolling upgrade no longer allowed

    Sometimes, during a rolling upgrade of a High Availability (HA) managed controller, a build from a newer replica was adopted by an older replica. This is no longer allowed. Builds can only be adopted by replicas that run the same or a newer version of CloudBees CI.


Completed builds not loaded from newer replicas during rolling upgrade

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.


Improvements to rolling restart

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.

The HA management page now displays the uptime for each replica and a note if the replica is part of an old replica set that will be replaced. The footer (for all users) will also display a warning when the sticky session is on a replica that is part of an old replica set.


Changes to High Availability (HA) controllers are now applied directly without an explicit stop/start cycle

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

Whether enabling/updating/disabling autoscaling, or updating CPU or memory resources, or any other field that would affect the deployment resource, it will trigger a rolling restart of the controller to apply the changes. This applies whether using the UI or Configuration as Code.


CloudBees Pipeline Explorer Related Builds View

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.


CloudBees Pipeline Explorer Build Failure Analyzer Integration

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.


CloudBees Pipeline Explorer Feature Enhancements
  • Add the ability to disable search input to prevent search failures

    When the index size is too big compared to the limit configured, the search is prevented by disabling the search input.

  • Context badges do not show node or parallel badges

    Node or parallel badges are now shown in the context badges (available in test insights and issue explorer).

  • Issue explorer rename

    Renamed “Issue Explorer” to “Unsuccessful steps”.

  • Change the name displayed for failing tests in the Test Insights drawer to include the test class name

    The entry for each failing test now shows the class name of the test, and now excludes the names of the stages that contain the step that recorded the failing test.


New endpoint to download all available Configuration as Code schemas

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:

  • JENKINS_URL/core-casc-schema-download/download/bundle-descriptor.json for the bundle descriptor

  • JENKINS_URL/core-casc-schema-download/download/plugin-catalog.json for the plugin catalog

  • JENKINS_URL/core-casc-schema-download/download/plugins.json for the plugins file

  • JENKINS_URL/core-casc-schema-download/download/items.json for the items file

  • JENKINS_URL/core-casc-schema-download/download/rbac.json for the RBAC file

  • JENKINS_URL/core-casc-schema-download/download/variables.json for the variables file


HashiCorp Vault integration: Support for Custom AppRole Paths in Authentication Configuration

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.

Resolved Issues

Links to CloudBees Pipeline Explorer from Pipeline Steps View take your tree view preferences into account when applying filters

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.


Errors occur when the managed controller is restarted after HA is disabled

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.


Synchronize completed build metadata between HA replicas

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.


Accidental clean up of active HA cluster logs

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


Improved performance for the Kube Agent Management views

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


Resources are not set for the Configuration as Code Bundle Retriever container

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


Branch migration is not reverted on unexpected failure

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.


Incorrect strategy used to compute the Configuration as Code item deletion report

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

Configuration as Code item deletion report now uses the strategy of the updated bundle.


Wrap private authentication token as HMAC512

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.


Incorrect messages returned in CloudBees CasC Client Plugin validation log

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

  • Some plugins can not be installed

  • Some items could not be created

The issue is resolved and the log no longer returns those messages.


Configuration as Code bundle retriever log files are no longer truncated if the pod restarts

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.


Manually set availability patterns wiped out on migration

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.

The indicated availability pattern will be applied to bundles that match the bundle name in all branches.


Remote Configuration as Code bundle checkout endpoint and CLI now provide a clear error if there is a problem checking out one of the bundles

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).


HashiCorp Vault Plugin support for complex KV2 mount names

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

This issue is resolved. The mount name for the KV2 Vault secret engine is now split into a different form field that allows you to specify a complex mount name separately and to access it correctly.

If the Vault KV2 credentials are configured with Configuration as Code, it is recommended that you update the Configuration as Code configuration and specify the mountName separately.


Add JVM options field back to Shared Agents

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.

Known Issues

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.


Unable to configure Pod Templates in the operations center via the UI

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


Error when renaming an existing EC2 cloud

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.