Skip to main content
Version: Release 24.1

Digital.ai Release 24.1.x Release Notes

Support Policy​

See Digital.ai Support Policy.

Upgrade Instructions​

The Digital.ai Release upgrade process you use depends on the version from which you are upgrading, and the version to which you want to go.

For upgrade instructions, see:

For more information about the operator installation changes, see What's new in Installation on Kubernetes.

Bug Fixes and Field Incidents in 24.1.x​

Here is the list of bug fixes and field incidents for Release 24.1.x: Bug Fixes and Field Incidents.

Digital.ai Release 24.1.2 includes the following new features:

Note: 24.1.2 is the released GA version.

Breaking Changes for 24.1​

The following are some of the breaking changes for Release 24.1.

  • To ensure optimal performance and compatibility, it is necessary to upgrade to JDK 17 before running Release 24.1. For more information, see the JDK Migration and Technical Updates sections.
  • Starting from version 24.1, Persistent Spring sessions are disabled by default, meaning the value is set to false. For more information, see Disabled Persistent Spring sessions.
  • Starting from version 24.1, Release will not capture the permission snapshot changes by default. For more information, see Permission Snapshot Report Settings.
  • Significant updates have been made to the JMS clients in version 24.1, which includes a breaking change affecting ActiveMQ users. As part of this update, support for AMQP with ActiveMQ is discontinued. Instead, support the OpenWire protocol is now provided. Update your configurations to utilize the OpenWire protocol instead of AMQP. This involves adjusting the connection URLs accordingly.
  • Release 24.1 does not offer support for Atlassian Crowd integration. Atlassian has not yet released Crowd Integration support for JDK 17. Consequently, we have removed the relevant libraries and classes. For more information, see Preparing for Crowd 6.0.
  • Starting from version 24.1, the Task Drawer is enabled by default for all tasks. You can disable it anytime in System Settings. For more information, see Enable or Disable Task Drawer for Tasks.

Cloud Transformation​

Learn about the latest enhancements with the newly added container plugins.

Python-based Integrations​

Go-based Integrations​

Added Support for Storing Folders with Sub-folders in Git​

In a setup with multiple files, when you create a version of a folder that contains sub folders, all styles now generate a Releasefile.yaml along with other YAML files for entities (following either the file-per-type or file-per-entity styles) in every folder and sub folder. Additionally, YAML files at each folder level only include entities specific to that level.

For example, in the following folder structure:

  • Parent
    • Child
      • Grandchild

On each folder level, a Releasefile.yaml file will be generated. These Releasefile.yaml files will be interconnected using an import definition kind.

Platform Engineering​

Learn about our new enhancements with regards to platform engineering.

Added New workflows​

New workflows are introduced with 24.1 Release

Azure Workflows

Helm Workflows

Release Runner Workflows

Run Workflow as Current User​

With Release 24.1, you can now run workflows as the current user by default. This is beneficial because you achieve the same result as when you run a release yourself.

Limit Workflow Templates​

  • Essentials Version: Supports up to 50 workflow templates in the Workflow catalog.
  • Pro and Premium Versions: Supports unlimited workflow templates capacity in the Workflow catalog.

Introduced Runners Screen​

Introduced the new Runners screen that is accessible via Settings > Runners for a detailed overview of the Runners and their statuses. For more information, see Configure and Register Release Runners.

Options to Install Runners​

You can now install Runners using Operator based installation or Runner workflows. For more information, see Install Release Runners.

Improvements in Runners and Container-based Tasks​

  • The Connections page with the help of the Test button, allows users to verify connections of the container-based tasks to their respective servers directly from the interface.
  • To improve clarity in task management, container-based tasks are now visually distinguished from classic tasks by an additional icon in the UI. For instance, tasks like Argocd: Create Application and Argocd: Create Application (Container) share the same UI, but the latter includes an extra icon, clearly indicating its a container-based task. This visual change helps users quickly identify and differentiate between different types of tasks.
  • You can now change a classic task type to a container task type. When you do this, the server connection also gets migrated if the name of the server is the same for both the tasks.
  • Note that, container-based tasks will have the same task drawer as the other tasks. However, this will additionally have the Capabilities field in the Overview tab. For more information, see Build Custom Container Plugin using Python SDK.
  • Improved TLS support for Runners.

Performance Improvements​

The UI performance of the Releases, Templates, Roles, and Tasks pages has been significantly improved. Additionally, pagination is added for Tasks page.

Releases Page​

The following table displays data to showcase the performance improvements with Releases page in 24.1:

UsersBytes in 23.3Response Time (ms) in 23.3Bytes in 24.1Response Time (ms) in 24.1Difference in %
142606019826819874226.8
542606014206819841168.8
1042606017036819696244.7

Templates Page​

The following table displays data to showcase the performance improvements with Templates page in 24.1:

UsersBytes in 23.3Response Time (ms) in 23.3Bytes in 24.1Response Time (ms) in 24.1Difference in %
1814668704804446746.3
5814668524804450940.3
108146610184804447253.6

Roles Page​

The following table displays data to showcase the performance improvements with Roles page in 24.1:

ConcurrencyUsersUsers/RolesResponse Time (ms) in 23.3Response Time (ms) in 24.1Difference in %
10500010136298138.8
105000501714120642.1
1050001002287153748.8
105000200236422465.3
105000500230022432.5
1027000500211683246652.1
1050000500370035041734.0

Tasks Page​

The following table displays data to showcase the performance improvements with Tasks page in 24.1:

UsersResponse Time (ms) in 23.3Response Time (ms) in 24.1Difference in %
11811606298.8
52135576370.7
103257589553.0

APIs​

The Release APIs have been updated in version 24.1 as follows:

Release API​

  • Introduced a new performant search endpoint that provides basic release details such as title, dates, and status.
  • Deprecated endpoints with an unused depth parameter, replacing them with more convenient methods that do not require this parameter.

Template API​

Deprecated endpoints with an unused depth parameter, replacing them with more convenient methods that do not require this parameter.

Folder API​

  • Introduced new endpoints for retrieving and updating the folder teams and their permissions in detail.

Roles API​

Added a new search endpoint that allows for searching roles by name or by the assigned principal.

For more information about these new and modified endpoints, see the REST API reference or Jython API reference documentation.

Upcoming End-of-Life Notifications​

Here are some of the deprecation notifications for the Fuji 24.3 Release.

Retiring Task Modal Feature​

To achieve the ongoing commitment to improving the user experience working with tasks within Release, we're announcing a change to how interactions with tasks in Release will be handled.

The Fuji release (planned date Q4 of 2024) will be the last version to support the Task Modal in Release user interface. In Release, from 2025 onwards, only the Task Drawer will be available for creating and managing tasks within Release. Maintaining a single version (Task Drawer) allows us to quickly iterate on improvements and introduce new functionalities. Additionally, recent features added to the Task Drawer are incompatible with the older Task Modal. To ensure consistency and reliability, the Task Drawer has undergone a comprehensive review and adjustment process.

To learn how to use the Task Drawer and explore its recent features, please refer to the following resources:

If you have any questions or concerns regarding this change, please contact your Customer Success Manager or Digital.ai Support.

Announcement Regarding Template Versioning Feature​

Release currently offers two methods for template versioning:

  • Traditional template versioning
  • GitOps-enabled versioning using YAML files

In our ongoing efforts to enhance Release, we have decided to prioritize the expansion of GitOps-enabled versioning using YAML files and will no longer enhance traditional template versioning functionality.

The planned changes for Template versioning are as follows:

  • Starting with the 24.3 (Fuji) release, template versioning and associated settings will be disabled for Release instances that do not currently utilize it.
  • Existing customers with template versions stored in the database will not experience any changes.

The current template versioning has limitations due to its inability to read from Git repositories, which limits its usage to local server instances. This limitation blocks seamless collaboration and cross-instance sharing, thus hindering further expansion of this functionality. Therefore, we highly recommend you to consider upgrading to GitOps YAML-based versioning. This transition aligns with our commitment to security and interoperability, providing a more comprehensive and widely accepted solution for versioning and managing templates.

If you have any concerns or require further assistance, complete this survey or reach out to your Customer Success Manager or Digital.ai Support. Your feedback enables us to improve the product together.

Analytics​

In the upcoming release 24.3 (Fuji), Premium subscriptions will include the DORA (DevOps Research and Assessment) and persona-based dashboards. For a preview, you can explore the Analytics section in the 24.1 release and review the reports.

The following dashboards are introduced:

  • Late Tasks and its Impact: It provides a detailed view of late release tasks and the impact of these delayed tasks within the release and across all dependent releases.
  • Release Executive Overview: It provides a high-level overview of all releases across the organization along with the key metrics and parameters that influence decision making.
  • Release Task Open Work Analysis: It provides a detailed view of open release tasks and the trend of upcoming release tasks.
  • Release Dependency: The Release Dependency dashboard enables you to identify, analyze and mitigate Release, Phase or Task dependencies and dependents on a gate task that is associated with a Release contributing to unplanned delays that can affect scheduled releases.
  • On Boarding Plan and Progress: The On Boarding Plan and Progress Dashboard provide a snapshot view of the on-boarding progress of the internal customers as they roll out the Digital.ai Release and Deploy to their new teams or applications.
  • DORA Dashboards: It provides a holistic view of DevOps performance to make strategic decisions and allocate resources effectively.
  • Workflow Analytics Dashboards: Workflow Adoption and Usage Patterns: It assists in understanding how your team is using services and automation through workflows. It also helps pinpoint the most effective methods and allows you to oversee your developer platform like a product.

These dashboards are tailored for different roles in Release such as:

  • Release Manager
  • DevOps COE
  • Platform Engineer
  • Platform Product Manager
  • Engineering Manager

Known Issues in Analytics​

Here are the known issues:

  • D-34367: Show Data values not matching actual data
    • Issue: In a dashboard, the preview data does not match the actual data. The values displayed by the Show Data option do not align with the actual attribute and metric values.
    • Workaround: None
  • D-33904: Row Count mismatch and duplicate values present in dora_common_filter_details dataset
    • Issue: Row Count mismatch and duplicate values are present in dora_common_filter_details dataset due to the data union implemented for Release, Deploy, and ServiceNow Source.
    • Workaround: None

Permissions​

  • View Reports and Digital.ai Analytics: Allows to view the pre-built reports and access the Analytics dashboards.
  • Audit data: Allows you to view the Audit reports and have read-only access to audit data. By default, this permission is assigned to the Digital.ai Analytics Service User role.
  • Create Custom dashboards: Allows you to create, edit, or delete custom dashboards.

Reorganized Custom Dashboards​

The Custom dashboards, Audit reports, and Value stream reports are reorganized under the Reports section in the global level. The navigation in the Custom dashboards screen is enhanced in the global level and folder level for better user experience.

Custom dashboards

On the folder level, the newly created custom dashboards were displayed in the left pane. However, they are now displayed as list items in the content area. You can customize these dashboards based on your needs. Additionally, you can duplicate or delete these custom dashboards.

New Digital.ai Analytics Service User Role Added​

The Digital.ai Analytics Service User role by default has the Audit data permission attached to it, which was previously called as Audit Reports. This new role, with Audit data permissions, will be utilized to access read-only audit data necessary for Analytics dashboards.

Analytics

Additionally, View Reports permissions is now renamed to View Reports and Digital.ai Analytics, and Create dashboards is now renamed to Create Custom dashboards.

Analytics

Analytics Tile on Home Page​

For all the editions of Release, a new Analytics tile (Global) tile is included on the home page. This tile highlights that Analytics dashboards customized for various Release personas are available with the Premium edition of Release.

New Home Page Analytics Tiles

For more information about the Analytics dashboards, see Overview of Analytics Dashboards.

Disabled Persistent Spring Sessions in Release​

Before version 24.1, Release automatically had Persistent Spring sessions enabled for their Active/Active cluster setups. This means that you wouldn't need to log in again after cluster node restarts.

Note: Setting up sticky sessions by configuring load balancers is crucial if you don't already have it set up in an Active/Active cluster configuration, as it helps you to maintain connections to the same node, rather than enabling persistent sessions.

Starting from version 24.1, Persistent Spring sessions are disabled by default, meaning the value is set to false. Note that, this change is significant as it represents a breaking change.

If you want to activate sessions, adjust the xl-release.conf file by setting xl.server.session.storage.enabled to true. However, enabling sessions may cause performance issues, with increased response times.

Task Drawer Enhancements​

The Task Drawer UI has been enhanced to improve the user experience.

  • The Configuration and Overview tabs have been merged to ensure consistent configuration across various task types, and all the configurations are now accessible under the Overview tab. The Input properties/Output properties toggle is located below the description. For certain task types like Manual, Notification, and Gate tasks, where no Output parameters are available, the Input properties/Output properties toggle is hidden to save space.
  • The top header now features the release title and phase title on the left side, with action buttons on the right. Longer titles are truncated, and the full title is displayed in a tooltip when hovered over.
  • Below the top header in the main header area, the task icon, task name, and the full task type are displayed. The task status is visible on the right, with the status line appearing below when applicable.
  • Additional action buttons, such as lock/unlock tasks, set flag message, and add watchers, are now present in the sub-header. Note that when a task is locked, the main header appears grayed out.

Task Drawer

  • Task tags functionality has been integrated into the Attributes tab.

Task Drawer

  • Container-based tasks now use the same Task Drawer as other tasks, with the Capabilities field added to the Overview tab. For more information, see Build Custom Container Plugin using Python SDK.
  • An icon indicating container-based tasks is displayed in the main header alongside the task icon.
  • When mandatory fields are left empty, a red badge indicating the number of empty or erroneous fields that must be filled now appears.

Task Drawer

  • Refresh functionality has been added to ensure user is editing the latest version of the task.
  • Information on the last modification of the task can be found in the Activity tab.
  • Concurrent edit checking support has been added. Turn it on, in the System settings > Experimental > Task editing settings section.

Task Drawer

  • Errors for Jython and Groovy script tasks are now displayed in the Overview tab, with the latest error linking to all errors in the Activity tab.
  • Save and Revert buttons are now accessible in the Script editor window.

Task Drawer

  • The description in the Overview tab can be expanded or collapsed to allow more space for Input properties/Output properties configuration. By default, the description is visible but collapsible if needed.
  • The @mentions feature has been updated to enhance notifications.

For more information, see Task Drawer.

Experimental

When you select the Enable task search when adding a new task checkbox in System settings > Tasks > Task drawer (Recommended) section, you can now search and filter task types directly by entering relevant text in the task name search field within the Release flow editor when adding a new task. This feature is currently in an experimental stage, and will be further enhanced in the 24.3 release.

For more information, see Task Drawer.

Miscellaneous Updates​

Learn about some of the miscellaneous updates in Release.

Permission Updates​

The following are the permission updates in Release.

Added Permissions in Applications Pipelines​

New permissions added for Application pipelines:

  • View App pipelines
  • Edit App pipelines

Admin users have the option to edit or delete the applications in Applications management page.

App management

New Permissions to Restart Phase​

Initially, the Restart Phase permission allowed you to restart a phase, and now you can resume a release after restarting the phase with the Restart Phase permission.

Configure maximum size of the HTTP request header​

With the maximum size of the HTTP request header set to 8KB (8192 bytes) it becomes difficult to pass the authentication tokens and scopes in headers. Hence with Release 24.1, you can use the server.max-http-request-header-size parameter to configure the maximum size of the HTTP request header that the Release server can accept. Setting an appropriate value for this parameter depends on the specifics of your application and environment. For more information, see Configure maximum size of the HTTP request header.

Support for HTTP Bearer Authentication Token​

For more security and flexibility, Webhook tasks now have a new Token field to support HTTP bearer authentication token. It is added for both JSON and XML Webhook tasks.

Webhook

For more information, see Webhook Task.

The menu items in the left navigation pane of Release application have been enhanced to function as clickable links. Right-click functionality is added for the left navigation page, folder page items, and breadcrumbs to open it in a new web page for efficient navigation experience.

Menu Item Links

Updated System Settings for Release Administrators​

System settings have been reorganized into multiple tabs categorized by themes, including General, Releases and Triggers, Tasks, Reports, Experimental, and a newly introduced Advanced section. Additionally, new settings such as Personal Access Token, Custom script task, Concurrent task editing, and Reference variable have been added.

New system setting

For more information on each section, refer to the links below:

Preserve Output Variable on Failure for Custom Script Tasks​

If a custom script task fails, there is an option to preserve any output variables that are created before the failure.

There are two ways to configure:

  • Select the Preserve output variable value for Custom script task checkbox.
  • Configure this setting in the xl-release.conf file. The default value is false.

Custom script task

When this checkbox is selected, and if the Custom Script task fails without exception, output variable values set before failure will be preserved.

Note: This setting is global and applies to all the Custom Script tasks.

Introduced Concurrent Task Editing Settings​

Note: When you enable the Enable concurrent Task edit checking in User Interface checkbox, it does not allow you to save the changes to a task that has been updated recently by another user. If you try to save changes on an outdated version of a task, the update will fail, and a notification message will appear in the UI. Enabling this checkbox prevents two users who are simultaneously updating the same task from overriding each other's changes.

To modify this setting, go to System settings > Experimental > Task editing settings section. By default, the Enable concurrent Task edit checking in User Interface and Enable concurrent Task edit checking in API checkboxes are cleared. For more information about this setting, see Experimental settings.

Note that the settings for Enable concurrent Task edit checking in API will only take effect when the Enable concurrent Task edit checking in User Interface checkbox is selected.

When the Enable concurrent Task edit checking in User Interface checkbox is selected, and if one user is editing a task and another user makes changes and tries to save them, the update will fail, and an error message will appear.

When the Enable concurrent Task edit checking in API checkbox is selected, and if you try to update a task that has been modified recently using Jython or REST API, it will fail with an error code of 409 - Conflict.

Concurrent Task Editing

Note: The settings on this screen can be updated or removed without prior notice.

Introduced Permission Snapshot Report Settings​

Now, you have configurations to capture the snapshot data on permission changes that are created for the Audit reports.

Note: After upgrading to version 24.1, Release will not capture the permission snapshot changes by default. These changes are used to fill the Permissions tab in the release audit report. If you need information about this setup in your environment, select the System settings > Reports > Audit report > Record historical changes in folder and global permissions checkbox to capture permission changes. Enabling the functionality will negatively impact the the performance of audit report generation and can lead to significant increase in database size.

To modify this setting, go to System settings > Reports > Permission snapshot report settings section. By default, the Enable capturing snapshot data on permission changes (for Audit report) checkbox is cleared. For more information, see Report settings.

Permission snapshot

Reference Variable Connection​

A new section called Advanced is introduced for System settings. This section will contain more complex or advanced settings.

By default, Reference variable supports Http server connections as a reference in multiple tasks of the same release. However, now you can add more custom connection types using the Reference variables section. In the Connection type drop-down list, select the connection type that you want to use with the reference variable. This variable type is only available at the Release level and not at the Folder level.

When you create a reference type variable, in the Create variable dialog, you can select this custom connection from the Reference type drop-down list. This variable can be used when you run a release.

Reference Variable Connection

Additional Settings​

Some new settings are added for Script Engine Options and New Scheduling Strategy.

Enhanced Users and Roles Pages for Release Administrators​

  • The User list is no longer restricted; all available Release users will now be displayed. Also, the information about the license utilization is added to the Users page.
  • Pagination and various other usability enhancements have been implemented for the Users and Roles pages.

For more information, see Users and Roles.

Personal Access Tokens (PAT) Enhancements​

Learn about the enhancements made to PAT.

PAT for SSO Users​

This feature allows the Personal Access Token (PAT) type of authentication to be enabled for SSO users for various authentication protocols like SAML, OAuth, OIDC, and so on. To learn more about this feature, see Personal Access Token for Authentication.

PAT

  • By default, the Enable Personal Access Tokens for SSO Users checkbox is selected. This enables the PAT type of authentication for SSO users.
  • If you don't want this feature enabled, clear the checkbox.

Note

  • Using the PAT you can make API calls and also run releases after authenticating.
  • The PAT remains active even after the OIDC user is deleted from the system.

Admin-Controlled Token Expiry for PAT​

Users currently have the flexibility to set any expiration date for Personal Access Tokens (PAT) or even choose the No expiration option. However, there is a security risk as tokens may remain forever unnoticed in the system. To address this concern, administrators now have the capability to oversee and limit the expiration duration set by users for PATs. This allows admins to prevent the creation of prolonged or non-expiring PATs, ensuring better security practices. To learn more about this feature, see Personal Access Token for Authentication.

Navigate to System settings > General > Personal access tokens section to set the value using the Maximum token expiration duration drop-down list.

PAT

By default, the value is set to No expiration. The available values are as follows:

  • 7 days
  • 30 days
  • 60 days
  • 1 year
  • No expiration

PAT

For example, if the value is set to 30 days. The available options in the Expiration field of the Personal access tokens page will be 7 days and 30 days. You cannot set an expiration beyond 30 days.

Notify Token Expiration Timelines​

In the Personal access tokens page, a new column titled Expires in is added to provide visibility into the token expiration timelines.

PAT timeline

The following list provides information about how the token expiration is notified:

  • Never pill indicates the token does not have an expiration date.
  • If the expiration date is greater than 5 days, the number of days before the expiration is displayed.
  • If the expiration date is less than 5 days, a warning pill is displayed with the number of days remaining for expiration.
  • If the expiration date is less than 24 hours, a warning pill is displayed with the message stating Less than 24 hours.
  • If the expiry date is passed, a caution pill is displayed with the message stating Expired.

For more information, see Personal Access Token for Authentication.

Global Permission Scope in PAT​

Personal access token can now be created for specific global permissions. For more information, see Personal Access Token for Authentication.

Installation on Kubernetes​

Learn about the latest Operator-based enhancements.

Upgrade Release Operator from 23.1.x to 24.1.x​

Learn how to upgrade the Release Operator from 23.1.x to 24.1.x.

Starting from version 24.1, the following folders have been removed as persistence folders:

  • conf
  • ext
  • hotfix
  • hotfix/lib

In case of the configuration directories, any files in the folders will be overridden by the templates. For other folders, the persisted files will be lost. In case there is a need to mount some directories back, to preserve files between restarts, use separate configurations:

  • persistance.paths
  • or extraVolumeMounts and extraVolumes

Added Helm hooks for license generation

  • New image is added to support the getLicense hook.
bitnami/kubectl
  • In case of generating the license, a new Helm hook is added to generate the license and share it between pods. Configure it under the section:
hooks.getLicense

For more detailed instructions about the upgrade, see Upgrade Options Reference for Digital.ai Release.

Enable File Logging​

For operator-based installation of Release, file logging is enabled. For more information, see Enable File Logging.

Manage Conf Directory​

As of Release 24.1, the Conf directory is now managed through the operator itself and eliminates the need for a mounted volume.

Manage TrustStore​

As of Release 24.1, the TrustStore management is facilitated through the secret provider, streamlining security configurations. For more information, see Set up TrustStore for Release.

Added HTTP2 Support​

You now have the option to select the type of HTTP protocol when you install Release using operator. It can be any one of the following:

  • HTTP
  • HTTPS
  • HTTP2

For more information, see Installation Options Reference for Digital.ai Release with Runner.

Install Release as non-root User in Operator Based Installation​

In the operator-based installation, the Release application typically operates under the xebialabs user by default. However, it is noted that while the parent server directory is owned by the 'root' user, essential components such as configurations, logs, and plugins for the application are owned by the xebialabs user.

You can install Release as a non-root user in operator based installation by running the Release pods with user and group id as xebialabs:xebialabs.

Support for Custom Registries​

In Release 24.1, support for custom registries has been extended, allowing users more flexibility and control over their configurations. For more information, see Setup Custom Image Registry.

Support for PKCS#12 Key Stores​

In Release 24.1, support for PKCS#12 key stores has been introduced, providing enhanced security options. For more information, see Set up TrustStore for Release.

Support Exec Command​

Exec command is added for the Kubernetes container plugin allowing you to directly execute within the containerized environments.

Docker Update​

Important: In line with the Docker-recommended best practices, the latest version tag is no longer supported for Deploy and Release docker images. This means that the docker pull command and image descriptors (used in as-code files)—without a valid version tag—will not succeed—after 01 Nov, 2024.

Correct

docker pull docker.io/xebialabs/xl-release:24.1

version: "2"
services:
 xl-release:
  image: xebialabs/xl-release:24.1
  container_name: xl-release

Incorrect

docker pull docker.io/xebialabs/xl-release

version: "2"
services:
 xl-release:
  image: xebialabs/xl-release
  container_name: xl-release

JDK Migration: Java 17 Support​

Find out what's new in our recent JDK upgrades.

To ensure access to the latest Java functionalities and up-to-date security fixes, the upcoming version of Digital.ai Release 24.1 mandates an upgrade to Java 17 for Release execution.

Configure Java 17​

Before upgrading to Digital.ai Release 24.1 (in this case 24.1 version), install Java 17 on all the Release servers. The supported JDKs are as follows:

  • Oracle JDK
  • Open JDK

Note: Set the JAVA_HOME environment variable correctly for the user or service to run the Release service.

Release JVM Options​

The 24.1 Release contains the following configuration wrapper files updated with the required additional JVM options for JDK 17:

  • conf/xlr-wrapper-linux.conf
  • conf/xlr-wrapper-windows.conf

When upgrading to 24.1 Release, manual configuration of the following JVM options is necessary if the deployment includes customized configuration wrapper files.

The following JVM options must be specified:

  • --add-opens=java.base/java.security=ALL-UNNAMED
  • --add-opens=java.base/java.lang=ALL-UNNAMED
  • --add-opens=java.base/java.util=ALL-UNNAMED
  • --add-opens=java.base/java.util.concurrent.locks=ALL-UNNAMED
  • --add-opens=java.base/java.util.regex=ALL-UNNAMED
  • --add-opens=java.base/java.lang.invoke=ALL-UNNAMED
  • --add-opens=java.base/java.io=ALL-UNNAMED

The following JVM options are deprecated and must be removed if they are specified:

  • -XX:MaxPermSize
  • -XX:PermSize
  • -XX:+TraceClassLoading
  • -XX:+TraceClassLoadingPreorder
  • -XX:+TraceClassResolution
  • -XX:+TraceLoaderConstraints
  • -XX:+UseMembar

Important Notes for Plugin Developers​

This section covers information about the packages changed.

Important

  • With the rebranding of Java EE to Jakarta EE, many libraries have undergone changes in package names and are no longer compatible with the previous versions. However, Release, Deploy, and the official plugins are updated for compatibility. See Known Issues section below for additional information.
  • Plugins that are bundled with Release have been updated as needed to operate with Java 17. But, if you have developed custom plugins, there will be some compatibility issues. Hence, all locally developed (custom) plugins should be validated for full Java 17 compatibility before being deployed on a 24.1 Release instance.
  • If you're using one or more of the below mentioned Pre-jakarta packages in your custom plugin code, you must update your plugin with Post-jakarta packages mentioned in the table below, in order to run it with Release 24.1.
Pre-jakartaPost-jakarta
javax.activationjakarta.activation
javax.batchjakarta.batch
javax.ejbjakarta.ejb
javax.eljakarta.el
javax.enterprisejakarta.enterprise
javax.facesjakarta.faces
javax.jmsjakarta.jms
javax.jsonjakarta.json
javax.jwsjakarta.jws
javax.mailjakarta.mail
javax.persistencejakarta.persistence
javax.resourcejakarta.resource
javax.servletjakarta.servlet
javax.validationjakarta.validation
javax.websocketjakarta.websocket
javax.ws.rsjakarta.ws.rs
javax.xml.bindjakarta.xml.bind

Plugin Changes for Java 17​

  • Java 17 is a milestone release of Java that deprecates or renames several packages in Java. Updating applications to run on Java 17 requires code changes when these deprecated or renamed packages are used.
  • Custom plugins that are developed locally require code changes to run with Java 17. These plugins with outdated packages may result in service initialization failure or trigger an exception when executing code that contains the deprecated packages. Utilities have been developed and packaged with Release to assist with this transition.
  • When a system is upgraded to the 24.1 version, installed plugins will be scanned for Java 17 compatibility. If an incompatible plugin is found, the service will not start, and a log message is displayed about the incompatible plugin.
  • To ensure a successful upgrade, the Plugin Manager CLI has been enhanced to scan plugins, which allows early detection of plugins that require code changes.

Note: Any incompatible plugins should be updated, and a new plugin must be prepared with a new version before you upgrade. The plugins xlr-delivery-insights-integration and xlr-auth-spnego-plugin are not bundled with the kit as they are incompatible, and requires an updated version for Java 17 compatibility. For upgrade steps, see the Verify for Upgrade section in Update Custom Plugins for JDK 17 Upgrade.

Technical Updates​

Learn about the latest technical updates in Digital.ai Release 24.1.

Akka to Pekko Migration​

Tip: If your Release cluster setup doesn't have any Akka-related configurations, no need to make any changes in the configurations.

As of Release 24.1, Digital.ai Release has adopted Apache Pekko and migrated all the required code and configurations from Akka to Pekko.

Note: When you try to set up Release in cluster mode, and if you encounter any occurrences of the term akka within the configuration files located in the conf folder, the setup will fail. To fix this issue, replace those instances with the corresponding configuration settings associated with Pekko. This involves modifying any relevant packages, class names, jar names, URLs, and so on to align with the configuration specifications specific to the Pekko framework.

For more detailed instructions about the configuration changes, see Akka to Pekko Migration for Release.

Spring 6 Migration​

As of Release 24.1, Digital.ai Release now incorporates Spring 6, with all the necessary code and configurations migrated.

Known Issues​

In General Availability (GA) release, all the officially supported plugins will be updated. However, not all of them have been updated, and JDK 17 validation is going to fail for the following plugin: Base plugin: This is not going to block the upgrade process, as the checks are optimised to not run on bundled plugins. The Base plugin will work normally despite being considered incompatible.

In General Availability (GA) release, all the officially supported plugins will be updated. However, if you encounter a situation where the plugins, block the upgrade process, perform the following steps:

  • Turn off the plugin validation during upgrade, by setting the configuration entry xl.features.plugins.check-jdk17-compatibility.on-product-upgrade to false in the xl-config.conf file.
  • Now, restart the service to complete the upgrade.
  • To turn on the plugin validation during upgrade, set the configuration entry xl.features.plugins.check-jdk17-compatibility.on-product-upgrade to true in the xl-config.conf file.
  • Now, restart the service.

Plugins and Integrations​

Here's what's new and changed with container and legacy plugins.

Argo CD Container Plugin​

  • Supports upsert and validate functionalities.
  • Added support for Kustomize and Helm chart to manage Kubernetes deployments.
  • Introduced Rollback functionality to revert to previous versions.

For more information, see Argo CD Container Plugin.

Argo Workflows Container Plugin​

Argo Workflows Container plugin is newly introduced.

For more information, see Argo Workflows Plugin.

Azure Container Plugin​

Azure container plugin is newly introduced with the following task:

  • Run Command (Container)

For more information, see Azure Container Plugin.

Conjur Container Plugin​

Conjur container plugin is newly introduced with the following task:

  • Get Secret (Container)

For more information, see Conjur Container Plugin.

Deploy Container Plugin​

  • Implemented SSL-based connections support.
  • Enabled uploading of zip files to Release.

For more information, see Deploy Container Plugin.

GitLab Container Plugin​

GitLab container plugins is newly introduced with 24.1.

For more information, see GitLab Container Plugin.

Helm Container Plugin​

Helm container plugin is newly introduced with the following tasks:

  • Command (Container)
  • Install/Upgrade (Container)
  • Rollback (Container)
  • Uninstall (Container)

For more information, see Helm Container Plugin.

Kubernetes Container Plugin​

  • Added lookup option to Kubernetes plugin fields.
  • Introduced support for executing commands in the Kubernetes plugin.
  • Enabled creation of PV and PVC.
  • Added support for the wait command.

For more information, see Kubernetes Container Plugin.

Terraform Container Plugin​

Fixed the ‘terraform-clone’: Permission denied error in the Terraform container plugin.

Deploy Plugin​

  • Deploy plugin now supports OAuth 2.0 authentication method.

GitHub Plugin​

Fixed an issue in the Username field of GitHub tasks. It is changed from password-type to text-type field. Hence, this field will not be masked in Tasks or Connections pages.

ServiceNow Plugin​

ServiceNow plugin is now certified for UTAH.

Phase Restart Enhancements​

Note: This feature is supported from Release 24.1.12 and later.

When you restart a phase in release, you can choose to have obsolete phases deleted automatically using the phase delete API. This improves the overall performance by preventing unnecessary data buildup.

Here's the xl-release.conf configuration to auto-delete obsolete phases:

features {
  phases {
    defunct-delete {
      allowed = true
    }
  }
}

The allowed parameter is set to false by default. You must set it to true to have obsolete phases deleted automatically on phase restarts.

Bug Fixes and Field Incidents​

Bug Fixes and Field Incidents—24.1.12​

  • D-37405 - Fixed an issue where creating a Jython task from a Groovy script or Release file added extra indentations, causing the task to fail.
  • D-36999 - Fixed a Jira plugin task issue that prevented proper ordering of JQL query results in Output Properties.
  • D-37018 - Fixed an issue in the Helm charts for Release where multiline base64-encoded values for license keys, truststores, and repository keystores caused installation failures.

Bug Fixes and Field Incidents—24.1.11​

This version was skipped, and 24.1.12 was released in its place.

Bug Fixes and Field Incidents—24.1.10​

  • D-33777: Fixed an issue where variable mapping would disappear when using xl-cli to create and apply YAML files, disrupting GitOps workflows.
  • D-35612: Fixed an issue that prevented saving a connection with a map_string_string property when the Properties field was left blank.
  • D-35746: Fixed an issue where the Save to folder field was auto-filled during release creation from a template at the root level, causing a permission error for roles without access to the folder.
  • D-37182: Fixed an issue that prevented high CPU usage for numeric-only usernames, improving performance.

Bug Fixes and Field Incidents—24.1.9​

This version was skipped, and 24.1.10 was released in its place.

Bug Fixes and Field Incidents—24.1.8​

  • D-34492 - Fixed an issue that prevented Release templates from using variables created earlier as part of other templates.
  • D-35566: Fixed an issue with the ThreadLocalWriterDecorator method that blocked Jython script tasks (with print statements) from being executed.

Bug Fixes and Field Incidents—24.1.7​

This version was skipped, and 24.1.8 was released in its place.

Bug Fixes and Field Incidents—24.1.6​

  • D-34847 - Fixed an issue where a Release user with only folder#view permissions on a folder could manage the permissions for that folder via XL CLI and grant themselves higher-level access
  • D-34972 - Fixed an issue where the max-life-time parameter for DB ClusterPool was not accepting new values and only used the default value of 30 minutes (1800000ms) in Release.
  • D-35126 - Fixed an issue where exporting a release template as a Release file (Groovy) and then attempting to import the same template would result in an error.
  • D-35188 - Fixed an issue that prevented scheduled environment reservation tasks from starting at the specified time.

Bug Fixes and Field Incidents—24.1.5​

This version was skipped, and 24.1.6 was released in its place.

Bug Fixes and Field Incidents—24.1.4​

  • D-34658 - Fixed an issue with the User Input task that was not getting completing despite all the required fields being filled.
  • D-34715 - Fixed an issue causing application slowness during release execution and while populating drop-down values. This problem occurred only after upgrading to version 24.1.2.
  • D-35090 - Fixed an issue with the OpenShift operator and XL CLI-based installations that was preventing the PostgreSQL pod from being generated.

Bug Fixes and Field Incidents—24.1.3​

  • D-33514 - Fixed an issue that prevented folder from expanding.
  • D-33888 - Fixed an issue where the updates made to the variables in the User Input task using the old Task modal view were not being logged in the xl-release.log file or in the corresponding Release's Activity logs.
  • D-34138 - Fixed an issue where, when the password autofill feature in Chrome is enabled, it removes the variables used in the Create Release screen.

Bug Fixes and Field Incidents—24.1.2​

  • D-25879 - Fixed an issue that was displaying the ORA-01795: Maximum number of expressions in a list is 1000 error message when accessing certain folders.
  • D-31824 - Setting up Release without ingress is not asking for the host and hence server.url is not setup in the xl-server-release.conf file. Fixed this issue by setting ingress.hosts and ingress.tls.hosts manually in the existing CR.
  • D-31853 - Fixed an issue where real-time updates in the Remote script task were not occurring until clicking the View Logs button once again.
  • D-31886 - Fixed an issue where updating a release variable in a User Input task using the new Task Drawer view was resulting in an incorrect permission error.
  • D-32551 - Fixed a permission issue where the Wait for the start date option was not getting enabled with the All task permissions unless you set the Edit dates permission explicitly for the user. This is fixed as the All task permissions includes the Edit dates permission as well.
  • D-32929 - Fixed an issue that prevented calling the Release REST API with an OAuth2 token when the OIDC plugin is in use, especially when the service is only accessible via a proxy.
  • D-33321 - Fixed the installation issue with the Release operator that occurs when HTTP2 is enabled and numeric values are provided for ReleaseKeystorePassword and ReleaseKeystoreKeyPassword during the prompt.