Skip to content

2026

0.48.0 - Release Highlights

Changes affecting the Galasa Service

  • Personal Access Token Expiry: Personal access tokens now have expiry times associated with them. When a token expires, it can no longer be used to authenticate with the Galasa service.
  • All existing tokens will migrate to expire in 90 days from the date of the update, however, they might expire sooner depending on your Galasa service's configured Dex 'expiry' values in the Galasa service's Helm chart.
  • The Galasa webui will now present you with the option to set an expiry date for your token, and display if tokens are expired or nearing expiry.
  • Tokens are automatically disabled when they reach their expiry date. Note: JWTs may continue to be valid for a period of time determined by your Galasa service administrator, so you might find your token will still work for a short while after it expires.
  • The Galasa CLI will automatically delete your token if you attempt to use it after it has expired.
  • The CLI displays a warning when using a token that is approaching its expiry date.
  • System administrators can configure when the "approaching expiry" warning is displayed using the CPS property service.tokens.lifespan.nearly.expired.warning.days (min: 1 day, max: 30 days).
  • The galasactl auth tokens get command displays token expiry dates.

  • For more information, see Configuring authentication.

  • Added a background cleanup process for the Galasa service's result archive store which automatically deletes test runs that meet the configured criteria.

  • By default, test runs older than 30 days are deleted and the cleanup process runs once every 24 hours.

  • For information on how to configure the cleanup process, including how to adjust the age threshold, cleanup frequency, and exclude specific test runs from cleanup, see Configuring automatic cleanup of test runs.

  • Added support for integrating the Galasa service with the Istio service mesh.

  • When enabled, Galasa service pods start up with an Istio sidecar so that pod-to-pod traffic can be secured using mutual TLS (mTLS).

  • For configuration details, see Installing an Ecosystem using Helm.

  • User operations are now case-insensitive. All user-related operations in the Galasa ecosystem now treat user login IDs case-insensitively. This means that myuser, MyUser, and MYUSER are all treated as the same user. Users no longer need to remember the exact case a user was saved into the Auth Store with when passing the value manually or from an automation tool, which would previously cause user not found errors. This improvement applies to:

  • CLI commands: galasactl users get/set/delete --login-id, galasactl auth tokens get --user, and galasactl runs submit --user
  • REST API endpoints: /users and /auth/tokens query parameters

  • Test run submissions: The user field in test run requests

  • Added support for creating/updating Java keystore secrets (JKS and PKCS12 formats) in the Galasa Service's credentials store using galasactl secrets set. For more information, see the command reference.

Changes affecting tests running locally or on the Galasa Service

  • The artifacts.properties file containing information about a local test run's artifacts will no longer be created and stored in the local RAS. Instead, an artifacts.json file will be created to provide more flexibility in the amount of metadata that can be included for each artifact. artifacts.json was already provided for runs in a Galasa service so the artifacts.properties file will simply no longer be provided.

0.47.0 - Release Highlights

Changes affecting tests running locally

  • macOS Keychain Credentials Store: Added support for reading Galasa credentials from the macOS Keychain, allowing macOS users to securely manage test credentials using the native Keychain Access application. This provides a more secure alternative to storing credentials in plain text files. The store supports all Galasa credential types including username/password, tokens, and KeyStore credentials. See the macOS Keychain Credentials Store documentation for setup instructions and usage examples.

Changes affecting tests running locally or on the Galasa Service

  • Added a new CPS property framework.test.run.timeout.minutes that can be used to configure the maximum amount of time that a test can run for before being interrupted and assigned the 'Hung' result. See #2551.

  • Added support for storing Java KeyStore credentials in the Galasa Credentials Store, enabling secure storage of SSL/TLS certificates and private keys. KeyStore credentials can be managed via the Secrets REST API using the new KeyStore secret type, which accepts PKCS12 or JKS format keystores encoded in base64. This feature allows managers like the Docker Manager to authenticate to services that require client certificates, such as Docker engines with TLS-protected daemon sockets. The KeyStore data, password, and type are validated during credential creation to ensure immediate feedback on invalid configurations. See #2509.

  • HTTP Client Manager: Upgraded the underlying HTTP client library from Apache HttpClient 4 to Apache HttpClient 5.

  • The existing getFile() methods that return CloseableHttpResponse are now deprecated but remain functional for backward compatibility. Users are encouraged to migrate to the new getFileStream() methods. See the HTTP Client Manager documentation for examples.

  • The galasactl runs submit local command now allows additional --obr flags to be supplied alongside a --gherkin flag. See #2562.

Changes affecting the Galasa Service

  • Added new REST API endpoints POST /streams and PUT /streams/<streamName> to allow users to create and update test streams. See the REST API reference for more details. See also #2447.

  • Added a new galasactl streams set command that can be used to create or update test streams within a Galasa service. See the command reference.

  • Added support for Gateway API for accessing the Galasa service. See Installing an Ecosystem using Helm for details on how to configure Gateway API. Ingress is still used for accessing the Galasa service by default but can be replaced with Gateway API by setting the ingress.enabled value to false and the gatewayApi.enabled value to true in the values.yaml file used when installing the Helm chart.

Other changes

  • Added an initial Galasa agent skill to the Galasa repository that provides AI agents with context necessary to use Galasa more effectively. Download the galasa-user skill from the Galasa repository and configure your AI-powered development environment to use it.

0.46.1 - Release Highlights

  • The dependency on assertj-core has been upgraded from 3.25.3 to 3.27.7 to remove a security vulnerability.
  • The dependency on byte-buddy has subsequently been upgraded from 1.15.10 to 1.18.3.

0.46.0 - Release Highlights

Deprecated features

  • The includeCursor query parameter has been marked as deprecated in the Galasa Service's GET /ras/runs REST API endpoint as cursor-based pagination is now enabled by default. This query parameter should be removed from requests to this endpoint.

Changes affecting tests running locally or on the Galasa Service

  • The SSH client library that Galasa uses has been updated to support stronger key algorithms, including rsa-sha2-256 and rsa-sha2-512. See #2461.
  • Galasa managers that use the IP network manager, like the zOS TSO Command SSH and zOS UNIX Command SSH managers, no longer support the RSA/SHA1 signature algorithm when connecting to a server via SSH. If you are using RSA/SHA1, you should upgrade your servers to use a stronger algorithm.
  • The z/OS Program Manager now validates that program names specified in the @ZosProgram annotation are uppercase and no longer than 8 characters. If a name is not uppercase or exceeds eight characters, the z/OS Program Manager rejects it and raises a ZosProgramManagerException with an actionable error message.

Changes affecting the Galasa Service

  • Users now have a priority modifier associated with them that can affect the order in which tests submitted by users are scheduled. Tests submitted by users with higher priority modifiers can be scheduled before tests that were submitted by users with lower priority modifiers. See #2176.

  • User priorities can be updated using the new --priority flag in the galasactl users set command. See the command reference.

  • Administrators can now set a user to associate with a batch of test runs when they are submitted, which may or may not be the same as the requestor. This allows admins who run batches of tests in an automation tool or workflow where the requestor is a functional ID/bot account, to also associate a user with the test runs, so these runs can be queried by the user later.

  • This can be set with the --user flag on the galasactl runs submit command. See the command reference.
  • The user can also be set when submitting tests with the Runs API. See the REST API reference.

  • Runs can now be queried by user in the galasactl runs get command with the --user flag. This will return any runs where the user or requestor matches the value passed in with the --user flag. See the command reference.

  • Added galasactl tags commands to the Galasa CLI tool that can be used to create, read, update, and delete test tags as resources on the Galasa service. See the command reference for more details.

  • Tags can be assigned a priority modifier that can affect the order in which tests submitted to a Galasa service are scheduled. Test submitted with tags that have higher priority modifiers will be scheduled before tests that have no tags or tags with lower priority modifiers.

  • Tags can also be assigned a description which can be used to provide more information about the tag.

  • galasactl runs submit local commands can now be supplied with one or more --methods flags to run a selection of test methods locally from a Galasa test class that is provided with the --class flag. See the command reference for more details.