CloudBees CI on modern cloud platforms 2.440.2.1

Starting with this release, CloudBees CI supports Internet Protocol version 6 (IPv6) with the following considerations.

The High Availability (HA) controllers do not permit agents with multiple executors to be attached. The recommended alternative has been to define multiple agents that use the same computer, but this can be complicated to set up. There is now a new option on static agents that run on an High Availability (HA) controller that allows an executor count above one to be defined. This results in one or more extra agents with similar configuration to be automatically created and managed; in the case of inbound agents, connecting the original agent automatically launches the new agent processes on the same computer for the extras.

When running in a Kubernetes cluster with multiple availability zones, replicas of the same controller will now prefer to spread across different zones. This relies on the standard Kubernetes node label topology.kubernetes.io/zone.

The CloudBees HashiCorp Vault plugin now supports User/Private Key and File credentials.

CloudBees CI on modern cloud platforms now supports Kubernetes 1.28 only when running on Amazon EKS.

When running in High Availability (HA) mode without an IPv4 network interface, Hazelcast support for IPv6 is automatically enabled.

When you run CloudBees CI in High Availability (HA) mode, the REST API endpoint /computer/api/json now returns an aggregated list of agents across all replicas.

Previously, the replicas/live/ directory of a support bundle from a High Availability (HA) controller included a predefined list of information from each other replica, regardless of which components were requested for the bundle. Now, it includes a subset of the selected components that are meaningful for this context.

In a High Availability (HA) controller, only one replica at a time holds a socket open to the operations center. Previously, the Operations center sidebar link from other replicas (depending on your sticky session) would display a page that indicates this replica did not hold that connection. Now, the same view is displayed from any replica, including the running connection log.

Now, the default method to expose controllers outside of the cluster when configuring a Cluster Endpoint is to use Route when installing the operations center in OpenShift.

Display an admin monitor to alert admins that the global default for pipeline jobs is not set to the maximum durability, or if individual jobs are overriding it to something else. You can also check to see if the disable resume property is not set on any pipeline jobs. These properties are not compatible with High Availability (HA) mode.

If a proxy is set up, there should be a pattern in the No Proxy Host list that matches the replica’s address. If a replica address does not match any of the proxy patterns in No Proxy Host, an administrative monitor is displayed to warn about potential issues.

If a Configuration as Code bundle that is currently assigned to a controller is removed from the remote bundle store, an administrative monitor is displayed which lists those controllers who are impacted by the missing bundle.

In previous releases, the way pod templates were managed caused issues upstream where the Operations center was unable to manage pod templates from the UI.

When you run a controller in High Availability (HA) mode, it needs access to the Kubernetes API to discover other nodes in the cluster.

In some cases, a replica can claim ownership of an outbound agent configured with High Availability (HA) mode, causing it to become unavailable for other replicas.

When using static outbound agents configured with High Availability (HA) mode, there were connection delays when a build was requesting them.

Interactions with the Pipeline Template Catalogs are now correctly applied to both replicas when running a controller in High Availability (HA) mode.

Now, when a new proxy configuration is set, or a proxy configuration is edited, the proxy configuration will be synced across the replicas without requiring a restart. This does not work for deleting the proxy, as currently an onChange event is not fired in this case. This means that if you want to delete a proxy, you will need to restart, or manually remove the proxy from all replicas.

Previously, this plugin (that adjusts the Blue Ocean theme: color and some other styling) was forcibly installed on all controllers, even if Blue Ocean was not in use or installed. This caused some confusion with an administrative monitor active on High Availability (HA) controllers that prompts you to remove Blue Ocean (which is not compatible with High Availability).

Under some circumstances, a High Availability (HA) controller replica can attempt to adopt a running build from another replica being cycled out by a rolling restart, but fail to do so within one minute. This lets another replica adopt the build instead and potentially can lead to data corruption. Changes to the blocking behavior should now avoid some of these cases.

When you configure a Pipeline project on a HIgh Availability (HA) controller to not allow concurrent builds (or not configure a freestyle project to allow concurrent builds), multiple builds of the project could have run on different replicas. Now, the controller tracks whether a build of the project is running on any replica, and if so, it blocks new builds from being started on any replica.

When a managed controller was configured to be provisioned in a distinct namespace from Operations center, the persistent volume claim jenkins-home-$name-0 was created in the same namespace as Operations center, preventing the controller’s Deployment from starting. Provisioning has been corrected to create the PVC in the same namespace as the other resources.

For plugins defined as exceptions in the plugin catalog, the version in CAP was installed while the version defined as the exception was offered as an upgrade.

If operations center checks out controller bundles that have structural errors, meaning the file is not a valid yaml file, the OC gets blocked and does not start. Besides, the error log does not provide enough information to figure out the bundle causing the error.

The Invalid Bundle Assignment administrative monitor does not notify about the bundles that have an incorrect state.

The operations center endpoint /openid/loadUserByUsername returned a HTTP 403 status when it should return a 200 status with a load status being either USERNAME_NOT_FOUND or USER_MAY_OR_MAY_NOT_EXIST.

When a communication error occured between the controller and the operations center, some resources associated with the HTTP exchange were not released. This resulted in a memory leak and thread retention.

When running a connected controller on Java 17 with a proxy configured with username/password authentication, the Operations center single sign-on did not work due to a limitation in a Java HTTP client. Now the proxy configuration is ignored and the controller contracts the Operations center directly regardless of proxy settings.

An earlier regression fix enabled API/CLI calls to be made through the Operations center SSO using username/password (an API token is still strongly encouraged). However, the fix omitted external groups such as those from LDAP. These are now set correctly.

When configuring a FINE logger for RBAC and restarting a controller, a NullPointerException would appear in the logs and block the proper loading of RBAC Groups permissions.

The SSH based agents fail to launch. This was caused by a bug in Jenkins where a thread pool was not initialized correctly with a context ClassLoader. This context caused the class loader to be dependent on the initialization order and previous calls to the thread pool. This bug has been fixed.

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.

When using Configuration as Code in controllers that run in High Availability (HA) mode, the CloudBees Configuration as Code Export and Update screen may display inconsistent information about the bundle along with two buttons: Restart and Reload. This is caused by information not being properly synchronized between replicas. Furthermore, users may experience the following problems when trying to use one of the two buttons on that page:

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.440.1.3:

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