Skip to content

2026

1.3.0 - Release Highlights

Changes affecting tests running locally or on the Galasa Service

  • z/OS Batch Manager: Added a new submitJobWithSuppliedJobcard(String jcl) method to the IZosBatch interface that submits JCL which already contains its own JOB statement, such as a member of a JCL library. Previously the manager always generated a JOB statement and put it in front of the supplied JCL, so JCL that contained its own JOB statement was rejected by JES with a JCL error. Tests no longer need to strip the JOB statement and its continuation records from the JCL, or re-express its attributes using a ZosBatchJobcard. This is supported by both the z/OS MF and RSE API implementations of the z/OS Batch Manager. See the z/OS Manager documentation for examples.
  • The job name is taken from the JOB statement in the supplied JCL and is used to track the job, so waitForJob(), getRetcode() and the retrieval of spool files work in the same way as for other jobs. A Galasa provisioned job name is not used.
  • The JOB statement can be continued over several records. The first record that is not blank or a comment (//*) must be the JOB statement. If a valid JOB statement is not found, a ZosBatchException is thrown and the JCL is not submitted.
  • A ZosBatchJobcard cannot be used to override values in the JOB statement, and the default input class, message class and message level CPS properties are not applied. Everything required must be specified in the JOB statement.
  • If the zosbatch.batchjob.[imageid].use.sysaff CPS property is true, the manager still adds a /*JOBPARM SYSAFF=[imageid] record, immediately after the last record of the JOB statement. It does not add the record if the supplied JCL already contains a /*JOBPARM record that specifies SYSAFF=.

  • The existing submitJob methods are unchanged. The JCL passed to them must still not include a JOB statement.

  • z/OS Batch Manager: Added a new ZosBatchJobnames class in the dev.galasa.zosbatch package so that a test can choose the job name that JES sees, for example to run a library member under its documented name. Previously a test could only use a name generated by Galasa, either through the @ZosBatchJobname annotation or by passing null to submitJob. This is supported by both the z/OS MF and RSE API implementations of the z/OS Batch Manager. See the z/OS Manager documentation for examples.

  • ZosBatchJobnames.exact(String name) returns an IZosBatchJobname with exactly the supplied name, in upper case, that can be passed to submitJob. Galasa does not make this name unique, so tests that run at the same time on the same z/OS system and use the same name can collide.
  • ZosBatchJobnames.randomWithPrefix(String prefix) returns an IZosBatchJobname that starts with the supplied prefix, followed by random characters to make the name 8 characters long. The name is random but not guaranteed to be unique, and a longer prefix leaves fewer random characters.
  • A name that is empty, longer than 8 characters or contains characters that are not valid in a job name is rejected with a ZosBatchException. A prefix for randomWithPrefix can be up to 7 characters.
  • Added a submitJob(String jcl) method to the IZosBatch interface that submits the JCL with a job name provisioned by the Manager. It is the same as passing null as the job name to submitJob, which is unchanged.
  • The existing @ZosBatchJobname annotation is unchanged and still provides a unique generated name.

1.2.0 - Release Highlights

  • Galasa now supports Java 21 and Java 25. Galasa tests can be run with a Java 17, Java 21, or Java 25 JDK.

1.1.1 - Release Highlights

  • Fixed issues with user roles, secret deletion, and built-in namespace validation.
  • Uplifted various third-party dependencies, including jackson-databind and jsch, to resolve security vulnerabilities.

1.1.0 - Release Highlights

Deprecation notices

HTTP manager

The deprecated getFile(String path) and getFile(String path, ContentType... acceptTypes) methods on IHttpClient have been removed as the HTTP manager has been upgraded to use the Apache httpclient 5 library.

Action required: If you haven't done so already, replace any calls to getFile(String path) and getFile(String path, ContentType... acceptTypes) with getFileStream(String path) and getFileStream(String path, ContentType... acceptTypes) in your test code.

1.0.1 - Release Highlights

Deprecation notices

IFirefoxOptions.getBinaryOrNull() deprecated

The getBinaryOrNull() method on IFirefoxOptions has been deprecated and marked for removal as FirefoxBinary has been removed from Selenium 4.

Action required: Remove any calls to getBinaryOrNull() from your test code. If you were using the returned FirefoxBinary to configure the Firefox executable path, use IFirefoxOptions.setBinary(Path) or IFirefoxOptions.setBinary(String) instead.

Changes affecting the Galasa Service

  • A new POST /runs/portfolios REST API endpoint resolves a portfolio of test classes server-side. Clients supply a selections array, where each entry names a stream and optional filters (bundle, package, test name, class, tag, with optional regex mode), and the server returns all matching classes from the stream's test catalog. If no filters are provided for a stream, all classes in that stream's catalog are returned. The response is stateless; no portfolio resource is persisted. See the Runs API reference for more details.

1.0.0 - Release Highlights

⚠️ Breaking change: Docker image registry change

From v1.0.0, Galasa Docker images are published to icr.io/galasa instead of icr.io/galasadev.

To give users time to migrate, images will continue to be published to icr.io/galasadev for a number of releases after v1.0.0. However, you are encouraged to update any references to icr.io/galasadev as soon as possible, as publishing to that registry will stop in a future release.

If you have any automation that pulls Galasa images directly — for example, custom Helm values.yaml overrides, CI/CD pipelines, scripts, or docker pull commands referencing icr.io/galasadev — you should update those references to use icr.io/galasa.

For example, if you currently reference: 

icr.io/galasadev/galasa-boot-embedded-amd64:0.48.1
update this to: 
icr.io/galasa/galasa-boot-embedded-amd64:1.0.0

See Upgrading to v1.0.0 for more details.

Changes affecting the Galasa Service

  • A new Opaque credential type is now supported in the Galasa Credentials Store. Opaque secrets store arbitrary opaque data (for example, licence JAR files such as my_license.jar) that tests can retrieve at runtime via the Credentials Store. The galasactl secrets set command gains two new flags: --secret-file (reads a file from disk and base64-encodes its contents) and --base64-secret (accepts an already-encoded string). Opaque secrets are mutually exclusive with all other credential fields. The REST API PUT /secrets/{name} and GET /secrets/{name} endpoints support the new Opaque type alongside the existing types.
  • galasactl secrets set now accepts an empty string ("") as the --password when creating or updating a KeyStore secret, to indicate a keystore with no integrity-check password. When updating an existing KeyStore secret, the keystore and keystorePassword fields must now be provided together to validate the KeyStore and its password.

Changes affecting tests running locally

  • Windows Credential Manager support added to the OS Credentials Store extension. Galasa can now securely read test credentials from Windows Credential Manager, providing a more secure alternative to storing credentials in plain text configuration files. See Windows Credential Manager Store for more details.

  • JMeter Manager now supports LOCAL execution mode using pre-installed external JMeter binaries, eliminating Docker dependency for performance testing.

  • Fixed an issue where multiple Galasa test classes could not be run in one galasactl runs submit local command. You can now supply multiple --class flags to run multiple test classes sequentially.

  • Added --offline flag to galasactl runs submit local. When set, the test JVM does not contact any remote Maven repositories — all required bundles must already be present in the local Maven cache. The flag is mutually exclusive with --remoteMaven.
  • Added new galasactl runs prepare local command. This pre-fetches all OBR bundle dependencies to the local Maven repository without running tests, enabling fully offline test execution on a subsequent galasactl runs submit local --offline invocation.

0.48.1 - Release Highlights

Changes affecting tests running locally or on the Galasa Service

  • Username/password credentials used to authenticate with Maven repositories can be supplied to download test artifacts and OBRs from password-protected Maven repositories.
  • For local test runs: Credentials can be supplied in the ${GALASA_HOME}/bootstrap.properties file using the maven.repository.username and maven.repository.password properties. Alternatively, credentials can be supplied as environment variables by setting GALASA_MAVEN_USERNAME and GALASA_MAVEN_PASSWORD. Values in environment variables take precedence over values in the bootstrap.properties file.
  • For test runs on the Galasa Service: Test streams can be configured with an optional secretName field that contains the name of an existing Galasa secret containing the credentials to use when authenticating with Maven repositories. The secret name can be set using the galasactl streams set --name <stream-name> --maven-secret-name <secret-name> command or via YAML files with the galasactl resources apply command (see Test Streams as GalasaStream resources for more details).

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.

  • Kubernetes Manager improvements: The Kubernetes Manager is now functional after several bug fixes. Credentials are now optional when using kubectl proxy (localhost:8001) for simplified local testing with Minikube. The manager also includes comprehensive documentation for both local and remote cluster setup, including SSL certificate troubleshooting.

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.