- Configuration as Code (CasC) for Controllers now supports item creation based on CloudBees templates (BEE-10387)
When a CloudBees template is created in a controller instance, it is now possible to create an item based on the template using CasC.
- CasC for the operations center now supports the creation and exportation of shared agent and shared cloud items (BEE-3768, BEE-3769, BEE-10974, and BEE-12120)
When a shared cloud is created in an operations center instance, it is now possible to export its configuration in a YAML format that can be used to create and configure shared cloud items using CasC.
By default, shared agent and shared cloud items are configured to be taken online. To configure the shared agent or shared cloud item to be taken offline, add the
takeOnlineproperty to the
items.yamland set it to
false. For example:
Shared agent and shared cloud items for the operations center are Preview features. For more information, refer to Creating items with CasC for the operations center.
- Support for Kubernetes release 1.22 (BEE-9817)
CloudBees CI on modern cloud platforms now supports Kubernetes release 1.22.
Refer to the Supported platforms for CloudBees CI on modern cloud platforms for more information.
- Updated sidecar injector to support Kubernetes release 1.22 (BEE-10710)
Sidecar injector now supports Kubernetes release 1.22. The minimum required version for sidecar injector version 2.2.0 is now Kubernetes release 1.21.
Refer to the documentation for using sidecar injector with Kubernetes for more information.
- CasC automatic provisioning threading behavior for managed controllers has been improved (BEE-10352)
When creating managed controllers using CasC for the operations center, the following properties can now be added to the
jenkins.yamlfile to configure the automatic provisioning threading behavior for managed controllers:
duration. For more information, refer to Creating a new controller item using CasC for the operations center.
These settings can also be configured in the operations center UI by navigating to, scrolling down to CloudBees Configuration as Code managed controller provisioning, and then selecting Automatically provision managed controllers that are created using CasC. The UI has been updated to explain how each value affects the automatic provisioning behavior.
Support for the thread sleep time
waitForproperty has been removed and it is no longer possible to configure this property using CasC for the operations center. The
waitForproperty should be removed from any existing configuration in the
- Migrated the CloudBees Update Center Plugin from
Previously, HTTP communication was managed by an old version of
In this release, the underlying HTTP library has been updated to use
okhttpto provide support for Server Name Indication (SNI) and Java 11.
- The Restart Aborted Builds plugin has been improved (BEE-9301, BEE-9994, BEE-9995, and BEE-10013)
When a controller is restored from a backup:
Active Pipeline builds are now listed in the administrative monitor page if still running at the time the page is displayed. You can also navigate to the builds or abort them. Previously, it was difficult to locate all Pipeline builds that were running when a backup was taken, to inspect them for possible errors.
Aborted Pipeline builds are now listed on the administrative monitor page. Previously, if an agent was not available after a backup and restore, Pipeline builds were aborted after a few minutes but the Pipeline build was not listed on the administrative monitor page alongside aborted Freestyle builds.
The administrative monitor page is now always displayed, even if no aborted builds are currently observed or any restore actions are summarized. Previously, the administrative monitor page was only displayed if there was at least one aborted build.
If a Pipeline build is started after a controller backup is taken, when the controller is restored from the backup, new builds may reuse existing build numbers. This is typically harmless because any deployed artifacts or reports should use unique identifiers based on commit, date, or similar. However, some projects may rely on the uniqueness of the Jenkins build number.
In this scenario, a restore script can now be used to set a controller
RESTORED_FROM_BACKUPenvironment variable to any identifier. If this variable is defined when the controller starts and the environment variable is either reset or set to a different value during the last startup, a pluggable set of actions are launched to adapt to the restoration and adds
1000to the next build number of every job. This ensures subsequent build numbers are unlikely to overlap with builds that may have started after the corresponding backup.
For more information, refer to Controlling builds.
- Elements are no longer enclosed in curly brackets in the exported CasC
When the current CasC configuration is exported for a controller, elements are no longer enclosed with curly brackets in the exported
- Plugin IDs are no longer enclosed in curly brackets in the exported CasC
When the current CasC configuration is exported for a controller or the operations center, the plugin IDs are no longer enclosed with curly brackets in the exported
- Exported CasC items only include supported items and properties (BEE-8957)
If a CasC item cannot be exported or an error occurs when a property is exported, the exported item now only contains the properties that were successfully exported.
If an error occurs when a property is exported, a descriptive message is now included in the exported YAML file.
- The cloudbees-installation-manager and cloudbees-assurance plugins are now compatible with Guava 30+ (BEE-10591) (BEE-8532)
These two plugins have been updated to be compatible with both current Jenkins versions and upcoming versions that have a newer Guava library.
- Support bundle failed for controllers with multiple containers (BEE-9709)
If you attempted to create a support bundle using the option Managed Controllers on Kubernetes logs for a controller that has multiple containers, the support component failed to properly retrieve the logs.
The support component now looks for the "Jenkins" container log when the controller has multiple containers. This issue has been resolved.
- Removed dependency to the obsolete nginx-ingress chart (BEE-10710)
The current Helm chart replaced the nginx-ingress chart dependency with ingress-nginx in October 2020.
This fix removes the dependency to the obsolete nginx-ingress chart.
- Fixed hibernation monitor support for multi-namespace environments (BEE-9780)
The hibernation monitor was not properly waking up controllers when the controllers and the operations center were deployed in different namespaces.
This issue has been resolved. Hibernation now works as expected in multi-namespace environments.
- Terminology updates (BEE-11930, BEE-12123)
CloudBees is updating terminology to remove offensive text. During this ongoing initiative, “controller” replaces “master,” “agent” replaces “slave,” “allowlist” replaces “whitelist,” and “denylist” replaces “blacklist.”
- Updated deprecated calls to Acegi Security (BEE-9530)
Acegi Security was replaced with Spring Security in a previous release of CloudBees CI. Deprecated calls to Acegi Security were potentially causing an impact on performance.
This issue has been resolved; the calls have been updated for Spring Security.
async-http-clientfrom the Operations center Client Plugin (BEE-12043)
async-http-clientlibrary is not compatible with Java 11.
It was removed from the Operations center Client Plugin in preparation for Java 11 support.
- Freestyle builds that use the AWS CLI plugin as a build wrapper failed with a runtime exception (BEE-10118)
Freestyle builds that used version 1.5.15 or earlier of the AWS CLI plugin as a build wrapper were failing with a runtime exception. The Freestyle job had to be saved to manually resolve the issue.
This issue has been resolved. Freestyle jobs that use the AWS CLI plugin as a build wrapper are now properly migrated wihtout any manual intervention.
- Update to the operations center Monitoring plugin (BEE-14284)
A security update that was made to the Metrics plugin changed how access keys persisted. The update required a change to the operations center Monitoring plugin to prevent unnecessary remote context synchronization.
- Rebuilding an aborted build could result in warnings and inconsistent behavior (BEE-10009)
Rebuilding an aborted build from the administrative monitor page could copy unwanted content from the original build, producing warnings and possibly causing inconsistent behavior.
This issue has been resolved. A standard implementation based on the rebuild action for Pipeline jobs is now used.
- A link to the Pipeline Template Catalog was missing from the Pipeline page (BEE-6906)
A standalone Pipeline that was created from a Pipeline Template Catalog was not showing a link to the Template in the left pane.
This issue has been resolved. The link to the Template now appears in the left pane.
- The Item Restriction list in Folder configuration displays non-applicable Item types (BEE-8036)
The Item Restriction list in Folder configuration displays only applicable Item types now.
- A shared library using Folder-scoped credentials fails to authenticate when using tags (BEE-8326)
Shared library tags using Folder-scoped credentials could not be checked out with Modern Git SCM.
Shared library tags can be fetched using Modern Git SCM with context-accessible credentials.
- Duplicate Pipeline Template Catalogs in the Configuration as Code (CasC) for Controllers jenkins.yaml file on each instance restart (BEE-12722)
If a Pipeline Template Catalog is configured in the CasC
jenkins.yamlfile and the
idproperty is not defined, the catalog is duplicated on each instance restart and in the exported CasC configuration.
- Migrating to Ingress NGINX 1.x
If you are managing the Ingress NGINX controller deployment with the CloudBees CI chart release - using the value
ingress-nginx.Enabled=true- this release now uses Ingress NGINX version 1.x that only supports Kubernetes version 1.19+.
Further, the upgrade might cause the managed controller to not be accessible until a Stop / Start has been performed from the upgraded operations center. That is because the controller ingresses still use the
kubernetes.io/ingress.classannotations while the Ingress Controller now only handles Ingresses based on the
.spec.ingressClassName. The Stop / Start is necessary for the controller’s Ingress objects to be updated accordingly. As a workaround to keep the controller accessible during the upgrade, you may use the following value to preserve support for the annotation:
ingress-nginx: Enabled: true controller: extraArgs: ingress-class: <name of the ingress class>
That would guarantee that controllers are always accessible.
- AWS Load Balancer Controller requires an IngressClass
If you are using EKS 1.19+ with the AWS Load Balancer controller, make sure that an
IngressClassis created. The attribute
.spec.ingressClassNameis now added to Ingresses objects when
networking/v1is supported. The AWS Load Balancer Controller requires that an
IngressClassbe created, but its deployment does not automatically provide one. Use AWS Load Balancer Controller version 2.3.0 or later with the helm value
createIngressClassResource: trueto make sure an
IngressClassis automatically created.
- Migrating the Role-Based Access Control (RBAC) plugin
Previously, users were not distinguished from groups in the RBAC configuration, leading to some potential misconfigurations when a user has the same name as a group. This issue has been resolved, users and groups are now properly distinguished and validated when added.
In the unlikely event that you have users and groups with the same names, you must manually select whether those items are users or groups when you upgrade. For more information, refer to Migrating the RBAC plugin from versions prior to 5.65.
- Additional steps required for Active Directory plugin users
If you are using the Active Directory plugin to authenticate users then additional steps will be required for upgrading this instance.
The Active Directory plugin versions 2.23.1, 2.24.1, and 2.25.1 adds an option to only connect to Active Directory via TLS/SSL to both modes (ADSI and LDAP).
This option is enabled by default for new installations and is now the recommended way to enforce TLS/SSL for connections to Active Directory.
Unlike the existing StartTLS option for the LDAP-based mode, it will not proceed using an insecure connection if establishing a TLS/SSL connection fails.
Administrators upgrading from previous versions of the plugin will be shown a warning on the Jenkins UI requesting they update the plugin configuration unless the (now otherwise obsolete) flag
hudson.plugins.active_directory.ActiveDirectorySecurityRealm.forceLdapswas set to
After upgrading, you should review your Active Directory setup and if required enable the
require TLSoption in the security configuration of Jenkins to require all communication with the LDAP server to be encrypted.
Additionally if previously using the
hudson.plugins.active_directory.ActiveDirectorySecurityRealm.forceLdapsflag you should save the Jenkins security configuration and then remove the system property.
The plugin exposes configuration of the ADSI flags implementing the TLS/SSL requirement via the system properties
hudson.plugins.active_directory.ActiveDirectoryAuthenticationProvider.ADSI_PASSWORDLESS_FLAGS_OVERRIDE. See the plugin documentation for further details.
|Care needs to be taken when reconfiguring the security realm to not accidentally lock yourself out. See the documentation for advice how to resolve this problem if it occurs.|
- Jenkins upgrade notes