Skip to content

Galasa Releases

0.48.0 - Release Highlights

Changes affecting the Galasa Service

  • 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.

0.45.0 - Release Highlights

Deprecated features

  • In a future release, Galasa's IP network manager will no longer support SSH connections using the RSA/SHA1 signature algorithm. If you are using RSA/SHA1 to connect to a server via SSH, you must upgrade your server to use a more secure algorithm to avoid connection failures.

Changes affecting tests running locally or on the Galasa Service

  • When a local test run shares a Dynamic Status Store (DSS) with a Galasa service and the run exits while in the 'queued' state, the test run will be interrupted and the DSS record for that run will be cleaned up after a period of time has passed. See #2395.
  • By default, local 'queued' runs are set to time out after 15 minutes but this can be changed by setting the new framework.resource.management.local.queued.timeout CPS property to the desired amount of time in seconds.

Changes affecting tests running locally

  • If a local test run uses a manager that allocates resources and the test run's JVM exits before cleaning the allocated resources up, you can run the new galasactl runs cleanup local command which runs resource management providers (Java classes implementing Galasa's IResourceManagementProvider interface) to clean up resources. See the new command syntax.

0.44.0 - Release Highlights

Changes affecting the Galasa Service

  • The Kubernetes client-java library that the Galasa service uses has been upgraded from 22.0.0 to 24.0.0.

  • If your Kubernetes cluster is at version 1.34, we recommend upgrading to Galasa 0.44.0 to avoid issues with scheduling test pods onto the cluster.

  • The Galasa service Helm chart's eventStreamsSecretName value is now optional and a value is no longer provided by default.

    • If no secret name is given, the Galasa service's Kafka extension will not be loaded.
    • If a secret name is given, the Helm chart will attempt to load the Kubernetes secret with the given name and pass it through to be used by the Galasa service's Kafka extension.
    • If a secret name is given but no such secret exists in the Kubernetes namespace, then the Galasa service will fail to be installed or upgraded.

  • The image used by Galasa in init containers, which contains the kubectl tool has been replaced.

  • Previously, the bitnami/kubectl image was used by default to make some pods wait for others to start, to avoid an error storm which would happen if all the pods started up at the same time. This enforces an ordering of pods starting up which matches their dependencies.
  • The bitnami images were withdrawn, so the default value in the helm values.yaml file was switched to use a different image containing the same tool: kubectlImage: "rancher/kubectl:v1.33.5"

  • Previous releases are also effected, so administrators of older installs of the Galasa service will also need to make this change and update their helm install.

  • Added log4j2Properties and log4jJsonTemplatesConfigMapName configuration settings in the Galasa service Helm chart to allow users to configure Log4j in their Galasa service. See the Installing an Ecosystem using Helm documentation for detailed instructions on how to do this.

  • Added a configuration setting couchdb.documentRevisionLimit in the Galasa Helm chart to control the maximum number of document revisions that should be stored in the CouchDB service. See #2439.

  • Deprecated the callback_url query parameter in the Galasa REST API's GET /auth endpoint in favour of a new base64_callback_url query parameter, which takes a Base64URL-encoded URL that the API will redirect back to after authenticating. See #2416.

  • Added a configuration setting certificatesConfigMapName in the Galasa service Helm chart to allow users to supply public certificates for Galasa service pods to use. See the Installing an Ecosystem using Helm documentation for detailed instructions on how to do this.

Changes affecting tests running locally or on the Galasa Service

  • Galasa no longer supports Java 11. Galasa tests must be run with a Java version 17 JDK.

  • The 3270 manager's ITerminal interface has a new toJsonString() method that allows tests to convert the current 3270 terminal screen into JSON format.

  • The VTP manager has been removed from the available Galasa managers as the IBM Z Virtual Test Platform offering has been discontinued. See #2460.

0.43.0 - Release Highlights

Changes affecting the Galasa Service

  • The Galasa service now creates a test run record in the Result Archive Store when each run is submitted, rather than when the test is scheduled to execute, so more test runs will appear in the 'queued' state awaiting execution now. This also allows observability of submitted runs which were cancelled prior to being scheduled, which was not previously possible.

  • The Galasa service has been made more efficient by reducing the amount of data being exchanged between internal components and avoiding the exchange of large messages travelling over the gRPC protocol. See #2312.

  • Upgrades are handled better: The Galasa Helm chart creates the _users database in CouchDB if it doesn't already exist. This is a required database for CouchDB that should be created as default to prevent errors when the Result Archive Store is started. This is needed because latest version of CouchDB needs this database, and it may not have existed before.

  • The Galasa service is more robust when failures occur: A deployed Galasa service will now only attempt to launch tests in a new Kubernetes pod if the ETCD and RAS services are working. Were either of the ETCD or RAS services to fail, the errors would not be compounded by launching more tests which would all fail anyway.

  • Cancelling test runs which have not already finished is handled better: Running tests are given an opportunity to notice they have been cancelled, and to exit cleanly after releasing any resources they hold. Queued test runs are marked as cancelled immediately.#2317.

Changes affecting tests running locally or on the Galasa Service

  • Java API enhancement: Updates have been made to the @TestResultProvider annotation. The @TestResultProvider can now provide a list of ITestMethodResults to the test which each include the method name, if the method passed, if the method failed, and the exception thrown to cause the failure, if available. This can be used by tests themselves to determine actions to take based on each method's result. See issue #2343.

  • The start and end line number in the run log pertaining to a particular method are now available in the test structure. This can be used to navigate the run log and identify which sections of the run log are about which methods. See issue #2214.

  • z/OS telnet 3270 server certificates can now be verified if the CPS property zos.image.[TAG].telnet.tls.verify is set to true. See issue #2296.

Other changes

  • Galasa users without internet access can continue to read the Galasa documentation offline. The Galasa zipped distribution, isolated.zip, now contains a docs.tar file that when untarred becomes a Docker image. This Docker image can then be run to access the Galasa documentation site from a local web server.

  • log4j-core dependency upgraded from 2.24.1 to 2.25.1 to remediate a Critical vulnerability.

  • The Galasa documentation site now complies with EEC regulations, providing a privacy statement and standard cookie consent banner.

Galasa Web UI changes

  • More experimental features have been added to the Galasa web user interface which are not visible by default. If you would like to test out these experimental features, you can opt-in to the features you wish to try by going to the "My Settings" page and ticking the checkboxes in the "Experimental Features" section. You can opt-out at any time by unchecking the ticked feature checkboxes.

0.42.0 - Release Highlights

Changes affecting the Galasa Service

  • Cancel a run group using the Group ID. See the new command syntax

  • For developers of Galasa: Easier development of the Web user interface

    • A Personal Access Token can now be used to run a local instance of the web user interface, targetting an existing Galasa Service.

  • Added a configuration setting kubeLaunchIntervalMillisecs in the Galasa Helm chart to control the time between launching of successive test runs, to space out launches more evenly so that Kubernetes is not as stressed.

  • Various defects, fixes, version uplifts

Changes affecting tests running locally or on the Galasa Service

  • IMS-TM Manager - Improvements to how the manager handles active conversations (See issue #2250)

Other changes

  • Make contributing code easier:

    • Code for the Galasa documentation has moved git repositories, to the galasa repository. This simplifies the build process for the Galasa documentation and makes changes on a git fork easier to build and verify. It also facilitates closer integration between the javadoc, REST interface, CLI syntax and the rest of the material.

  • New look for the Galasa web site:

    • The look and feel of the Galasa website and documentation has been improved. The site now includes page-indexes on the right to navigate each page of the documentation. The site also supports light and dark mode for easy-reading. Command-line tool syntax is now more integrated with the documentation, and is searchable.

0.41.0 - Release Highlights

Changes affecting the Galasa Service

  • Streams Service:

    • Streams can now be created, updated and deleted using a new set of REST API endpoints.
    • Command-line tool list or delete report streams, or create and apply changes to stream resources using the galasactl apply -f command.

  • Resource Management:

    • Custom managers can have their cleanup code executed in a new "Resource Cleanup Monitor" construct, allowing for more cleanup of remote resources after test failures.
    • Cleanup monitors load resource management code from a given test stream.
    • New REST API commands allow manipulation and query of stream definitions.
    • Improved command-line can enable or disable monitors dynamically.

  • Tagging of test run results:

    • Test runs can be submitted with extra tags, which are combined with the annotation tags inside the test source code such that the test results are also tagged with the combined set of tags.
    • Extra tagging in test run details can help categorise failures and can contribute to better charting of results over time.

  • Kubernetes CPU and Memory resources:

    • For each pod, including pods that runs tests, can optionally specify resources constraints. Telling Kubernetes how much CPU and memory each pod needs helps Kubernetes spread workload among nodes in the cluster. The default install now specifies such limits.

  • Miscellaneous:

    • Tests which are re-queued or cancelled get marked as finished, rather than appearing to be active forever.
    • Querying runs with the --active flag no longer returns cancelled runs. Cancelled runs are marked as finished now.
    • Web user interface footer shows the version of the Galasa service, and a health indicator.
    • Test runner handles exceptions from rogue manager code better, so test cleanup can be performed.

Changes affecting local tests

  • Managers vetoing method execution changes:

    • Managers implementing anyReasonTestMethodShouldBeIgnored are no longer asked whether the test method should be ignored before running the @Before and @After methods. If the test method is ignored, then the @Before and @After methods are also ignored.

  • Tests can find out if the test has failed yet:

    • Test code can ask for a TestStatus provider to be injected into their object. This can be used to find out if the test has failed yet or not, and can be useful when doing complex cleanup of resources allocated during the test.

  • 3270 Manager can now process SSCP-LU-DATA:

    • Unformatted data screens are processed and the contents made available to test applications.

  • @ContinueOnTestFailure annotations:

    • These annotations are now respected by the Galasa framework.

Other changes

  • Make contributing code easier:

    • Code for the galasactl command-line tool has moved git repositories, to the galasa repository. This simplifies the build process and makes changes on a fork easier to build and verify.

0.40.0 - Release Highlights

  • Nameculture:

    • The term "Galasa Ecosystem" is being replaced with "Galasa Service" because it more clearly describes Galasa components that are deployed onto a Kubernetes cluster, providing testing as a service.

  • Galasa Service Changes:

    • A submission ID is generated for each test run submitted. A new field has been added to the test structures passed over the REST interface. Client programs can use the submission ID to query test runs from the Results Archive Store (RAS).

    • Each user now has a role, which dictates what that user can do. See the documentation on Role Based Access Control (RBAC) for more details.

    • The Helm chart can configure specific users to be owners of the system, such that these users are immutable administrators of the system. Configuring owners is used to set up a system with some initial administrators, and to recover a system that no longer has any functioning administrators.

    • Completed test pods now count when calculating the maximum number of pods that Galasa creates. Use the Helm chart parameter max_engines to configure the maximum number of pods.

    • When tests complete, the pod for the test disappears quicker than in previous releases, to free up resources on the cluster. Instead of up to 5 minutes, completed pods are cleaned up within 2-4 seconds.

    • It is now possible to configure the Galasa service to use an etcd server that is external to the Galasa namespace, for Dynamic Status Store traffic. This option is not recommended but may be useful for allowing testcase developers to use the same resource pools as the rest of the Galasa service.

  • Framework and Manager changes:

    • The addition of an IMS manager for contacting, controlling, and asserting against an IMS system.

  • The Web User interface changes:

    • Everyone logged-in to the Galasa service can see the list of users on the system, and their roles.

    • Administrators on the Galasa service can delete the tokens of other users, change their role, or delete their entire user record.

  • Command-line tool (galasactl) changes:

    • Users launching tests can use multiple override files with the --overridefile option. These files are combined into a single collection of properties, with warning messages generated in the logs if any property keys clash.

  • Development process, infrastructure, and contributing:

    • Improvements to the build process and instructions you use to fork the code, and build your own Galasa binaries in your own GitHub organisation.

    • Added experimental instructions describing how to install the Galasa Service into Minikube. Minikube can be used when developing contributions to Galasa, but is not suitable as a useable run time platform.

  • Various other component version upgrades and bug fixes.