diff --git a/README.md b/README.md index a6568036..6ee313ec 100644 --- a/README.md +++ b/README.md @@ -37,6 +37,11 @@ You can then serve that production build using: npm run serve ``` +Note: If you are using a dev container within vscode, use this instead: +```sh +npm run serve -- --host 0.0.0.0 +``` + ## Contributing Take a look at the [contribution guidelines](https://github.com/galasa-dev/projectmanagement/blob/main/contributing.md). diff --git a/src/data/nav.yaml b/src/data/nav.yaml index d36086b5..82b3e75e 100644 --- a/src/data/nav.yaml +++ b/src/data/nav.yaml @@ -92,6 +92,8 @@ items: - title: Ecosystem architecture path: /docs/ecosystem/architecture + - title: Role based access control + path: /docs/ecosystem/role-based-access - title: Installing an Ecosystem using Helm path: /docs/ecosystem/ecosystem-installing-k8s - title: Configuring authentication @@ -128,6 +130,8 @@ items: - title: CICS TS Managers path: /docs/manager-groups/cics-ts-manager-group + - title: IMS TM Managers + path: /docs/manager-groups/ims-tm-manager-group - title: Cloud Managers path: /docs/manager-groups/cloud-manager-group - title: Communications Managers diff --git a/src/markdown-pages/docs/cli-command-reference/installing-cli-tool.md b/src/markdown-pages/docs/cli-command-reference/installing-cli-tool.md index 112984ed..3455bddc 100644 --- a/src/markdown-pages/docs/cli-command-reference/installing-cli-tool.md +++ b/src/markdown-pages/docs/cli-command-reference/installing-cli-tool.md @@ -32,8 +32,8 @@ On Mac: 3. Then you have a choice. Either install the latest version fo the `galasactl` tool, or install a specific version. 1. To install the latest version of `galasactl`: `brew install --no-quarantine galasactl` - 2. To install a specific version of `galasactl` (version 0.39.0 for example): - `brew install --no-quarantine galasactl@0.39.0` + 2. To install a specific version of `galasactl` (version 0.40.0 for example): + `brew install --no-quarantine galasactl@0.40.0` Note: You can check to see what versions are available using this: `brew tap-info galasa-dev/tap --json` and look in the `"cask_tokens"` part of the json file. diff --git a/src/markdown-pages/docs/ecosystem/ecosystem-architecture.md b/src/markdown-pages/docs/ecosystem/ecosystem-architecture.md index 92af3c26..efd22473 100644 --- a/src/markdown-pages/docs/ecosystem/ecosystem-architecture.md +++ b/src/markdown-pages/docs/ecosystem/ecosystem-architecture.md @@ -67,3 +67,14 @@ The following diagram highlights some of the key components that make up the Gal | **Kabana** | A dashboard for visualizing Elasticsearch metrics. Data can be explored through queries and drilldown. | + +### Key concepts: + +These concepts are relevant when running tests locally, or when submitting tests to a remote Galasa service: +- A **test case** - A piece of test logic which can be compiled or translated into something which is runnable by the Galasa framework. This may be a piece of Java code for example, or a Gherkin test feature. +- A **test run** - Also known as a 'run' - An execution of the testcase which was started at a certain point in time, executed logic steps, and is still running, or has finished with a test status and result. For example: Passed or Failed. + +Some concepts are only relevant on a Galasa service: +- A **user** - The authorised person manipulating the Galasa system in some way. +- **Role based access control (RBAC)** - The mechanism where the Galasa service will allow some users to perform any available task, but limit what other users can do. This is to help isolate some system capabilities for safety or for security. Read more about the RBAC in the [role-based access](./ecosystem-role-based-access.md) section. + diff --git a/src/markdown-pages/docs/ecosystem/ecosystem-installing-k8s.md b/src/markdown-pages/docs/ecosystem/ecosystem-installing-k8s.md index 09ca33c5..9ccec473 100644 --- a/src/markdown-pages/docs/ecosystem/ecosystem-installing-k8s.md +++ b/src/markdown-pages/docs/ecosystem/ecosystem-installing-k8s.md @@ -23,7 +23,7 @@ _Note:_ The Galasa Ecosystem Helm chart currently supports only x86-64 systems. -## Role-based access control +## Kubernetes role-based access control If role-based access control (RBAC) is active on your Kubernetes cluster, a user with the `galasa-admin` role (or a role with equivalent permissions) is needed to run Helm commands on the cluster. The `galasa-admin` role allows assigned users to run the Helm install, upgrade, and delete commands to interact with the Helm chart. @@ -152,10 +152,33 @@ Complete the following steps to configure Dex to authenticate through GitHub: - my-team ``` -By default, the Galasa Ecosystem Helm chart creates a Kubernetes Secret containing configuration details for Dex. If you want to apply your own Dex configuration as a Secret, your Dex configuration must be provided in a `config.yaml` key within the Secret, and the value of the `config.yaml` key must be a valid Dex configuration. +By default, the Galasa Ecosystem Helm chart creates a Kubernetes Secret containing configuration details for Dex. +If you want to apply your own Dex configuration as a Secret, your Dex configuration must be provided in a `config.yaml` key within the Secret, +and the value of the `config.yaml` key must be a valid Dex configuration. For more information on configuring Dex, see the Dex documentation. +## Configure the default user role, and 'owner' of the Galasa service + +When the Galasa service is first installed, users logging in will be assigned a role as dictated by the `galasaDefaultUserRole` Helm chart property. For example 'tester'. +This means nobody initially logging into the Galasa service will have administrator privileges. +We would discourage ever setting this property to `admin` as doing so would provide a less secure Galasa service, with any action in the system available to anyone on the system. + +To obtain administration rights to the Galasa service, the kubernetes install must nominate one or more users as 'owners' of the service. +When a service owner next logs into the Galasa service, they will be granted a role of `owner`. +From this point on, that user can assign the 'admin' role to anyone else who needs it using the `galasactl` command line or by using the web user interface via a browser. + +Once the Galasa service has one or more users with the 'admin' role, kubernetes can be updated so that the system doesn't have any "owner" if desired. +The `owner` role exists solely to fix situations where there are no administrators on the Galasa service, such as when the Galasa service is initially installed, or when none of the +members in the organisation have the `admin` role. +If a user was a nominated "owner", performs some administration tasks, and is then removed from the list of "owners", their role on the Galasa service will revert to what it was initially. + +To configure a list of owners, use the `galasaOwnersLoginIds` property of the `values.yaml` file and use Helm to deploy it. +You can set multiple owners by adding a comma-separated list of login-ids. + +Each login-id must match the login-id allocated to the user by the authentication service to which Galasa connects. +If you are unsure what login-id to use, try setting up your system without an owner and logging into the Galasa service using a browser, then viewing the user profile page before returning to update the owner login-id in your `values.yaml` and deploying it to kubernetes using `helm upgrade`. + ## Installing the chart After configuring your `values.yaml` file, complete the following steps to install the Galasa Ecosystem Helm chart: @@ -214,14 +237,14 @@ Once you have successfully installed the Ecosystem, you can then deploy your Gal ## Upgrading the Galasa Ecosystem -Get the latest version of the Ecosystem chart and upgrade the Galasa Ecosystem to use the newer version of Galasa - for example version 0.39.0 - by running the following command: +Get the latest version of the Ecosystem chart and upgrade the Galasa Ecosystem to use the newer version of Galasa - for example version 0.40.0 - by running the following command: On Mac or Unix: ```console helm repo update \ helm upgrade galasa/ecosystem --reuse-values \ ---set galasaVersion=0.39.0 --wait +--set galasaVersion=0.40.0 --wait ``` On Windows (Powershell): @@ -229,7 +252,7 @@ On Windows (Powershell): ```console helm repo update ` helm upgrade galasa/ecosystem --reuse-values ` ---set galasaVersion=0.39.0 --wait +--set galasaVersion=0.40.0 --wait ``` where:
diff --git a/src/markdown-pages/docs/ecosystem/ecosystem-rbac-model.svg b/src/markdown-pages/docs/ecosystem/ecosystem-rbac-model.svg new file mode 100644 index 00000000..6d331052 --- /dev/null +++ b/src/markdown-pages/docs/ecosystem/ecosystem-rbac-model.svg @@ -0,0 +1,63 @@ + + + + + + + + +User + + + + + + +Role + + + + + + + + +Token + + + + + + + +Action + + + +has a +0..* +0..* +0..* +0..* +1 +1 +represented by +allows + + + + + + + + + + + + + + + + + + \ No newline at end of file diff --git a/src/markdown-pages/docs/ecosystem/ecosystem-role-based-access.md b/src/markdown-pages/docs/ecosystem/ecosystem-role-based-access.md new file mode 100644 index 00000000..6fcb9a4b --- /dev/null +++ b/src/markdown-pages/docs/ecosystem/ecosystem-role-based-access.md @@ -0,0 +1,207 @@ +--- +path: "/docs/ecosystem/role-based-access" +title: "Role Based Access" +--- + +- [Role Based Access Control in Galasa](#role-based-access-control-in-galasa) + - [Why do we need Role Based Access Control ?](#why-do-we-need-role-based-access-control-) + - [Understanding the Galasa RBAC model](#understanding-the-galasa-rbac-model) + - [Available Actions](#available-actions) + - [Available Roles](#available-roles) + - [Constraints](#constraints) + - [Upgrading to a version of Galasa which supports RBAC](#upgrading-to-a-version-of-galasa-which-supports-rbac) + - [Setting up RBAC when you install Galasa into Kubernetes](#setting-up-rbac-when-you-install-galasa-into-kubernetes) + - [How to nominate a user as the Galasa service `owner`](#how-to-nominate-a-user-as-the-galasa-service-owner) + - [How to set the default user role](#how-to-set-the-default-user-role) + - [Using the `galasactl` command-line tool to view roles](#using-the-galasactl-command-line-tool-to-view-roles) + - [Using the `galasactl` command-line tool assigning a "role" to a user](#using-the-galasactl-command-line-tool-assigning-a-role-to-a-user) + - [Using the Galasa web user interface to view your own user role](#using-the-galasa-web-user-interface-to-view-your-own-user-role) + +# Role Based Access Control in Galasa +Role Based Access Control (RBAC) is a widely adopted mechanism of assigning roles to users of a system which grants such users permissions to perform some capability dictated by the role(s) they have been assigned. Here we discuss the Galasa implementation of RBAC. + +## Why do we need Role Based Access Control ? +Some actions that can be performed on the Galasa Service are powerful and dangerous, such as deleting CPS properties, secrets, users or other resources. Giving every user of the Galasa service the ability to perform those actions is inviting disaster from inexperienced or incautious users who are not aware of the consequences of their actions. +Deleted resources could mean data being lost forever, which bears a cost to work out what was removed, and how to re-create it again. It would be far better to prevent those events occurring in the first place. + +To limit the risk of such events occurring, the Galasa Service provides some Role Based Access (RBAC) mechanisms to ensure users responsible for administering the service can perform these powerful actions, while other users are denied access to them. + +## Understanding the Galasa RBAC model +![Diagram showing the RBAC model used by Galasa](./ecosystem-rbac-model.svg) + +The Galasa Service offers a list of "actions". Each one relates to something which can be performed on the Galasa Service. + +Galasa has a concept of a "role", such that each role has a name and description, but also has a list of actions which someone can perform when that user has been assigned this role. + +Each user has one such role, thereby indirectly associating each user with a list of actions that user can perform. + +When a personal access token is used, that token is associated with the user identity the token was created for, and so also has an indirect association with a list of actions which +can be performed by a client program using that access token. + +If the user has an action in the role they are assigned, then that user can perform that action. + +For example, an "admin" role exists with an action CPS_PROPERTY_SET which allows a user with the "admin" role to set a CPS property. A "tester" role does not list that action, so a user with the "tester" role cannot set a CPS property. + +Currently, the list of "actions" and "roles" are fixed within the system. + +## Available Actions +This table shows the list of built-in actions: + +| Action | What it allows you to do | +|--------|--------------------------| +| CPS_PROPERTIES_DELETE | Allows the deletion of CPS properties | +| CPS_PROPERTIES_SET | Set a CPS property value | +| GENERAL_API_ACCESS | Be able to perform basic actions on the system via the REST api | +| RUNS_DELETE_OTHER_USERS | Allows the user to delete runs that other users submitted | +| SECRETS_DELETE | Allows the deletion of secrets | +| SECRETS_GET_UNREDACTED_VALUES | Allows you to get secrets which contain the real secret value, rather than a redacted value | +| SECRETS_SET | Allows setting of secrets | +| USER_EDIT_OTHER | Allows the editing of a different user on the system. This includes changing their role, deleting personal access tokens, or deleting the user completely | + + +## Available Roles +This table shows the list of built-in roles: +| Role name | Description | Actions someone with this role can perform | +|-----------|-------------|--------------------------------------------| +| deactivated | A user who has no permissions at all, and is able to do nothing on the Galasa service | none | +| tester | A user who writes and runs tests, looks at the test results and diagnoses errors in the system under test | GENERAL_API_ACCESS | +| admin | A Galasa service administrator. Able to do any operation supported by the Galasa service | all | +| owner | The owner of the Galasa service. Such users have all the rights of an administrator, but nobody can delete their id or change their role without changing the kubernetes configuration | all | + + + +## Constraints +The system also has some constraints on how these resources can be set up and used: +- Nobody can change their own "role", assigning a different role to yourself is not permitted +- New users on the system are assigned a default role when they first login to the Galasa service. This role is configurable. More details on how to configure this default role is described in section [how to set the default user role](#how-to-set-the-default-user-role). +- One or more users can be assigned the `owner` role. Such users are privileged because an administrator role cannot directly update their role away from `owner` using the standard mechanisms. Similarly, such "owners" of the Galasa service cannot be removed, even by another "owner" without changing kubernetes configuration. +- An administrator cannot delete their own user record. This constraint attempts to make sure that there is at least one owner or administrator on the system. If nobody active in your organisation has `admin` or `owner` rights, then a new owner of the service can be nominated using the Galasa service install/update instructions. See [How to nominate a user as the Galasa service `owner`](#how-to-nominate-a-user-as-the-galasa-service-owner) +- An administrator cannot change their own role. +- Not even administrators can change the role of a user nominated as an `owner`. +- The `owner` role can only be assigned using the Helm property, not via the command-line or REST interface. + +## Upgrading to a version of Galasa which supports RBAC +When upgrading your Galasa service to a version 0.40.0 or later, any existing users will be assigned the role of `admin` without any extra action being required. + +Under such circumstances you may wish to assign the role of `tester` to anyone who now should not have administration rights. + +Upgrading the existing Galasa service will therefore not require any `owner` to be set up, because your system will already have multiple administrator users with the `admin` role. + + +## Setting up RBAC when you install Galasa into Kubernetes + +### How to nominate a user as the Galasa service `owner` +An "owner" of the Galasa service is a user who has been nominated as the owner of the service, and who has the `owner` RBAC role. + +This nomination is made at the time the Galasa service is first installed into the Kubernetes namespace, or +when it is subsequently updated using the Galasa Helm chart. + +To nominate a user as an `owner` you need to set the property in the Helm values file when the Galasa service is installed or updated. + +For example, in the `.values.yaml` file used by Helm: +``` +# +# The list of login ids of the Galasa service owner(s), comma-separated. +# If a user login id appears in this list, the user will appear to have the 'owner' role, rather than +# their normal role. +# +# Roles of owner user records cannot be changed. Without changing the configuration at the Kubernetes level. +# +# The users nominated here will always have a role of 'owner'. +# +# If the Galasa service owners leave the organisation, or are otherwise unable to administer the system any longer, +# someone with access to kubernetes can change this value and the user specified will then appear to have the role +# of owner. +# +# Multiple owners can be specified. eg: "user1, user2". All users mentioned will have the 'owner' role until they are +# removed from the list +# +# If your Galasa service already has a user with the 'admin' role, the `owner` role may not be required. +galasaOwnersLoginIds: "" +``` + +To install the Galasa service, it may be necessary to nominate an `owner` using this mechanism initially, so +that when such a user logs in, they are able to promote other trusted users to the position of `admin`. + +After that point, the Kubernetes configuration can be changed to remove the `owner` or not. + + +### How to set the default user role +When a new user initially logs into the Galasa web user interface, a user record is created, and that user is assigned a default user role. + +The default user role is configurable by the system installer, who can set a property in the Helm values file when the Galasa service is installed or updated. + +For example, in the `.values` file used by helm: +``` +# +# +# New users logging into the system get a user record created and that user is assigned a role +# by default. It should be the name of one of the roles on the system. +# Suggested values are: +# "deactivated" - After initial logon, an administrator will need to set their most apropriate role +# before this new user can access any function within the Galasa service. +# "tester" - After initial logon, the user is classified as a tester, so can launch tests and +# see test results, but cannot administer the system. +# "admin" - A user with access to all the functionality provided by Galasa. +# We recommend only using this setting if you want every user to be an administrator +# (unlikely). +galasaDefaultUserRole: "tester" +``` + +The default will be set to "tester" unless the Galasa systems administrator wishes to change it. + +## Using the `galasactl` command-line tool to view roles + +To list roles on the service: +``` +> galasactl roles get +name description +admin Administrator access +deactivated User has no access +tester Test developer and runner + +Total:3 +``` + +A role can also be queried in yaml format, where it is possible to see the list of actions that role entitles the user to perform: + +``` +> galasactl roles get --format yaml --name admin +apiVersion: galasa-dev/v1alpha1 +kind: GalasaRole +metadata: + id: "2" + name: admin + description: Administrator access + url: http://my-server:8080/rbac/roles/2 +data: + actions: + - CPS_PROPERTIES_SET + - GENERAL_API_ACCESS + - SECRETS_GET_UNREDACTED_VALUES + - USER_ROLE_UPDATE_ANY + ...etc +``` + +## Using the `galasactl` command-line tool assigning a "role" to a user +The user role can be listed by getting the user data. For example: +``` +> galasactl users get --name userName1 +login-id role web-last-login(UTC) rest-api-last-login(UTC) +userName1 tester 2025-01-22 14:09 2025-01-22 23:15 + +Total:1 +``` + +If someone has the `USER_ROLE_UPDATE_ANY` action, then they are able to do the following to change the role of a different user. +``` +> galasactl users set --name userName1 --role deactivated +``` + +## Using the Galasa web user interface to view your own user role +The Web user interface for Galasa can be used to view your own user role. +Navigate to the "My Settings" page. + + + + diff --git a/src/markdown-pages/docs/manager-groups/ims-tm-manager-group.md b/src/markdown-pages/docs/manager-groups/ims-tm-manager-group.md new file mode 100644 index 00000000..a3d0e045 --- /dev/null +++ b/src/markdown-pages/docs/manager-groups/ims-tm-manager-group.md @@ -0,0 +1,9 @@ +--- +path: "/docs/manager-groups/ims-tm-manager-group" +title: "IMS TM Managers" +--- + + + Name | Description | +| :-------------------------------------------------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| **[IMS TM Manager](/docs/managers/ims-tm-manager)**
![alpha](../../../images/alpha.svg) | Provides configuration information for pre-existing IMS TM systems. Drives provisioning services from other managers, e.g. z/OS 3270 Manager. | diff --git a/src/markdown-pages/docs/managers/cics-ts-manager.md b/src/markdown-pages/docs/managers/cics-ts-manager.md index ebafcac5..2b1b31cc 100644 --- a/src/markdown-pages/docs/managers/cics-ts-manager.md +++ b/src/markdown-pages/docs/managers/cics-ts-manager.md @@ -16,7 +16,7 @@ This Manager is at Alpha level. You can view the Javadoc documentation for the Manager here.
+ + +[Overview](#overview)
+[Configuring](#configuring)
+[Provided annotation](#annotations)
+ + +# Overview + +This Manager provides IMS TM functions to Galasa tests. + +## Testing in IMS Systems on z/OS + +To connect your Galasa test to a developer supplied environment with a provisioned IMS system as a minimum you need to configure the following property for the IMS TM Manager: + +``` +imstm.dse.tag.[TAG].applid=[APPLID] +``` + +You also need to configure the following properties for the [z/OS Manager](zos-manager) as a minimum to connect to an IMS system, even if you do not reference a `@ZosImage` in your Galasa test. This is because IMS systems sit on a z/OS LPAR, and so to provision and connect to an IMS system in a test, you also need access to the z/OS image that it sits within to make requests on the IMS system. You might need to configure additional z/OS-related CPS properties, depending on your test. + +``` +zos.dse.tag.[tag].imageid=[IMAGEID] + OR zos.tag.[tag].imageid=[IMAGEID] + OR zos.cluster.[CLUSTERID].images=[IMAGEID] (AND zos.dse.tag.[tag].clusterid=[CLUSTERID] if [CLUSTERID] is not DEFAULT) +zos.image.[IMAGEID].ipv4.hostname=[IP ADDRESS] +zos.image.[IMAGEID].credentials=[CREDENTIALID] +``` + + +## Configuration Properties + +The following are properties that are used to configure the IMS TM Manager in the CPS. + + +
+Developer Supplied Environment - IMS TM System - Type + +| Property: | Developer Supplied Environment - IMS TM System - Type | +| --------------------------------------- | :------------------------------------- | +| Name: | imstm.provision.type | +| Description: | Provisioners will use this property to determine if they should participate in provisioning. The DSE provisioner responds to `dse` and `mixed` (case insensitive). | +| Required: | No | +| Default value: | dse | +| Valid values: | Any | +| Examples: | imstm.provision.type=dse
| + +
+ +
+Developer Supplied Environment - IMS TM System - Applid + +| Property: | Developer Supplied Environment - IMS TM System - Applid | +| --------------------------------------- | :------------------------------------- | +| Name: | imstm.dse.tag.[TAG].applid | +| Description: | Provides the applid of the IMS TM system for the DSE provisioner. The applid setting is mandatory for a DSE system. This property is ignored if you set the imstm.provision.type property to specify any value other than `dse` or `mixed`. | +| Required: | Yes if you want a DSE system, otherwise not required. | +| Default value: | None | +| Valid values: | A valid VTAM applid | +| Examples: | imstm.dse.tag.PRIMARY.applid=IM1A
| + +
+ +
+Developer Supplied Environment - IMS TM System - Version + +| Property: | Developer Supplied Environment - IMS TM System - Version | +| --------------------------------------- | :------------------------------------- | +| Name: | imstm.dse.tag.version
imstm.dse.tag.[TAG].version | +| Description: | Provides the version of the IMS TM system to user tests. | +| Required: | Only requires setting if a test requests it. | +| Default value: | None | +| Valid values: | A valid V.R.M version format, e.g. 15.5.0 | +| Examples: | imstm.dse.tag.PRIMARY.version=15.5.0
| + +
+ +# Provided annotation + +The following annotations are available with the IMS TM Manager + +
+IMS System + +| Annotation: | IMS System | +| --------------------------------------- | :------------------------------------- | +| Name: | @ImsSystem | +| Description: | The @ImsSystem annotation requests the IMS TM Manager to provide an IMS TM System associated with a z/OS image. The test can request multiple IMS Systems. | +| Attribute: `imsTag` | The imsTag is used to identify the IMS System. Optional. The default value is PRIMARY. | +| Attribute: `imageTag` | The imageTag is used to identify the associated z/OS image. Optional. The default value is PRIMARY | +| Syntax: | @ImsSystem(imsTag="A", imageTag="MVSA")
public IImsSystem imsSystemA; | +| Notes: | The IImsSystem interface defines getTag(), getApplid(), getVersion(), and getZosImage() methods for accessing the IMS System's attributes. The behaviour of the remaining methods are dependent on the provisioner that supplies the IImsSystem object. For the DSE provisioner, isProvisionStart() always returns true, while startup() and shutdown() always throw an exception. | + +
+ +
+IMS Terminal + +| Annotation: | IMS Terminal | +| --------------------------------------- | :------------------------------------- | +| Name: | @ImsTerminal | +| Description: | The @ImsTerminal annotation requests the IMS TM Manager to provide a 3270 terminal associated with an IMS System. The test can request multiple IMS Terminals for each IMS System. Each @ImsTerminal annotation requires a corresponding @ImsSystem annotation in the same test class. | +| Attribute: `imsTag` | The imsTag is used to identify the IMS System. Optional. The default value is PRIMARY. | +| Attribute: `connectAtStartup` | If connectAtStartup=true the terminal will be connected and signed on to the associated IMS System when control is passed to the test. Optional. The default value is true | +| Attribute: `loginCredentialsTag` | The loginCredentialsTag is used to identify the credentials that will be used to sign on to the IMS System. Required. +| Syntax: | @ImsTerminal(imsTag="A", connectAtStartup=true, loginCredentialsTag="USER01")
public IImsTerminal terminalA; | +| Notes: | The IImsTerminal interface defines getImsSystem(), connectToImsSystem(), resetAndClear(), and getLoginCredentialsTag() methods in addition to all methods defined for the ITerminal interface. | + +
diff --git a/src/markdown-pages/docs/managers/zos-manager.md b/src/markdown-pages/docs/managers/zos-manager.md index bd04d158..a7b5e4e4 100644 --- a/src/markdown-pages/docs/managers/zos-manager.md +++ b/src/markdown-pages/docs/managers/zos-manager.md @@ -57,13 +57,15 @@ compileOnly 'dev.galasa:dev.galasa.zos.manager' } ``` -## Testing CICS Regions on z/OS +## Testing in CICS Regions or IMS TM Systems on z/OS -To connect your Galasa test to a developer supplied environment with a provisioned CICS region as a minimum you need to configure the following properties, even if you do not reference a `@ZosImage` in your Galasa test. This is because CICS regions sit on a z/OS LPAR, and so to provision and connect to a CICS region in a test, you also need access to the z/OS image that it sits within to make requests on the CICS region. You might need to configure additional z/OS-related CPS properties, depending on your test. +To connect your Galasa test to a developer supplied environment with a provisioned CICS region or IMS TM system as a minimum you need to configure the following properties, even if you do not reference a `@ZosImage` in your Galasa test. This is because CICS regions and IMS TM systems sit on a z/OS LPAR, and so to provision and connect to a CICS region or IMS TM system in a test, you also need access to the z/OS image that it sits within to make requests on the CICS region or IMS TM system. You might need to configure additional z/OS-related CPS properties, depending on your test. ``` -zos.dse.tag.[tag].imageid=[IMAGEID] OR zos.cluster.[clusterId].images=[IMAGEID] +zos.dse.tag.[tag].imageid=[IMAGEID] + OR zos.tag.[tag].imageid=[IMAGEID] + OR zos.cluster.[CLUSTERID].images=[IMAGEID] (AND zos.dse.tag.[tag].clusterid=[CLUSTERID] if [CLUSTERID] is not DEFAULT) zos.image.[IMAGEID].ipv4.hostname=[IP ADDRESS] zos.image.[IMAGEID].credentials=[CREDENTIALID] ``` @@ -75,6 +77,12 @@ cicsts.provision.type=dse cicsts.dse.tag.[TAG].applid=[APPLID] ``` +or the following property for the [IMS TM Manager](ims-tm-manager): + +``` +imstm.dse.tag.[TAG].applid=[APPLID] +``` + # Configuring @@ -86,12 +94,12 @@ The following properties are used to configure the z/OS Manager. | Property: | Hostname of a z/OS system | | --------------------------------------- | :------------------------------------- | -| Name: | zos.image.[IMAGEID].ipv4.hostname | +| Name: | zos.image.[imageId].ipv4.hostname | | Description: | A physical TCP/IP hostname value for a z/OS system | | Required: | Yes, if connecting to a z/OS image | | Default value: | None | | Valid values: | A valid TCP/IP hostname | -| Examples: | zos.image.IMAGEA.ipv4.hostname=dev.galasa.system1
zos.image.SIMBANK.ipv4.hostname=127.0.0.1
zos.image.IMAGEA.ipv4.hostname=winmvs2a.example.com
| +| Examples: | zos.image.SYSA.ipv4.hostname=dev.galasa.system1
zos.image.SIMBANK.ipv4.hostname=127.0.0.1
| @@ -100,12 +108,12 @@ The following properties are used to configure the z/OS Manager. | Property: | Credentials tag for logging onto a z/OS system | | --------------------------------------- | :------------------------------------- | -| Name: | zos.image.[IMAGEID].credentials | +| Name: | zos.image.[imageId].credentials | | Description: | Tag of the credentials that are stored in the CREDS and used to log onto a z/OS system | | Required: | Yes, if connecting to a z/OS image | | Default value: | None| | Valid values: | Valid characters are A-Z, a - z, 0-9 | -| Examples: | zos.image.IMAGEA.credentials=KEY_TO_CREDS_STORE
zos.image.SIMBANK.credentials=SIMBANK
zos.image.IMAGEA.credentials=WINMVS2A
| +| Examples: | zos.image.SYSA.credentials=KEY_TO_CREDS_STORE
zos.image.SIMBANK.credentials=SIMBANK
| @@ -134,7 +142,7 @@ The following properties are used to configure the z/OS Manager. | Required: | No | | Default value: | None | | Valid values: | Valid value is a character string with a maximum length of 32 | -| Examples: | zos.tag.[tag].clusterid=plex1
| +| Examples: | zos.tag.PLX1.clusterid=PLEXA
| @@ -148,7 +156,7 @@ The following properties are used to configure the z/OS Manager. | Required: | No | | Default value: | None | | Valid values: | Valid value is a character string with a maximum length of 32 | -| Examples: | zos.cluster.[clusterId].images=SYSA,SYSB,SYSC
| +| Examples: | zos.cluster.PLEX1.images=SYSA,SYSB,SYSC
| @@ -176,7 +184,7 @@ The following properties are used to configure the z/OS Manager. | Required: | No | | Default value: | None | | Valid values: | A 1 - 8 length character name | -| Examples: | zos.dse.tag.[tag].clusterid=PLEXA
| +| Examples: | zos.dse.tag.PLX1.clusterid=PLEXA
| @@ -190,7 +198,7 @@ The following properties are used to configure the z/OS Manager. | Required: | No | | Default value: | None | | Valid values: | A valid image ID | -| Examples: | zos.dse.tag.[tag].imageid=SYSA
| +| Examples: | zos.dse.tag.MVS1.imageid=SYSA
| @@ -213,12 +221,12 @@ The following properties are used to configure the z/OS Manager. | Property: | IP Host ID of the zOS Image | | --------------------------------------- | :------------------------------------- | -| Name: | zos.image.[tag].iphostid | -| Description: | The IP Host ID of the z/OS Image for the supplied tag.
If CPS property zos.image.[tag].iphostid exists, then that is returned, otherwise the z/OS Image ID is returned | +| Name: | zos.image.[imageId].iphostid | +| Description: | The IP Host ID of the z/OS Image for the supplied tag.
If CPS property zos.image.[imageId].iphostid exists, then that is returned, otherwise the z/OS Image ID is returned | | Required: | No | | Default value: | None | | Valid values: | A valid IP Host ID | -| Examples: | zos.image.[tag].iphostid=sysa.example.com
| +| Examples: | zos.image.SYSA.iphostid=sysa.example.com
| @@ -227,12 +235,12 @@ The following properties are used to configure the z/OS Manager. | Property: | The zOS Image | | --------------------------------------- | :------------------------------------- | -| Name: | zos.dse.tag.[tag].imageid | +| Name: | zos.tag.[tag].imageid | | Description: | The image ID for the specified tag | | Required: | No | | Default value: | None | | Valid values: | A valid z/OS image ID | -| Examples: | zos.dse.tag.[tag].imageid=SYSA
| +| Examples: | zos.tag.MVS1.imageid=SYSA
| @@ -241,12 +249,12 @@ The following properties are used to configure the z/OS Manager. | Property: | Maximum slots for zOS Image | | --------------------------------------- | :------------------------------------- | -| Name: | zos.image.[tag].max.slots | +| Name: | zos.image.[imageId].max.slots | | Description: | The maximum slots available on a z/OS Image for the specified tag | | Required: | No | | Default value: | 2 | | Valid values: | 1 to 255 | -| Examples: | zos.image.[tag].max.slots=2
| +| Examples: | zos.image.SYSA.max.slots=2
| @@ -255,12 +263,12 @@ The following properties are used to configure the z/OS Manager. | Property: | Code page for zOS Image | | --------------------------------------- | :------------------------------------- | -| Name: | zos.image.[tag].codepage | +| Name: | zos.image.[imageId].codepage | | Description: | The EBCDIC code page used on a z/OS image for the specified tag. EBCDIC features a variety of code pages, and a subset of characters, including square brackets and currency symbols, are encoded differently between code pages. Setting the correct code page for a z/OS image can resolve issues with displaying these characters. | | Required: | No | | Default value: | 037 | | Valid values: | A valid java.nio.charset EBCDIC character encoding | -| Examples: | zos.image.[tag].codepage=1047
| +| Examples: | zos.image.SYSA.codepage=1047
| @@ -269,12 +277,40 @@ The following properties are used to configure the z/OS Manager. | Property: | The SYSNAME for zOS Image | | --------------------------------------- | :------------------------------------- | -| Name: | zos.image.[imageid].sysname | +| Name: | zos.image.[imageId].sysname | | Description: | The SYSNAME for the z/OS image | | Required: | No | | Default value: | The image ID of the image | | Valid values: | The name must be 1-8 characters long; the valid characters are A-Z, 0-9, $, @, and #. | -| Examples: | zos.image.IMAGEA.sysname=SYSA
| +| Examples: | zos.image.SYSA.sysname=SYSA
| + + + +
+The VTAM logon command template for the z/OS Image + +| Property: | The VTAM logon command template for the zOS Image | +| --------------------------------------- | :------------------------------------- | +| Name: | zos.image.vtam.logon
zos.image.[imageId].vtam.logon | +| Description: | A template for the command to log on to an application running on the zOS Image. The {0} argument in the template will be replaced with the VTAM application identifier for the requested application. | +| Required: | No | +| Default value: | LOGON APPLID({0}) | +| Valid values: | A valid java.text.MessageFormat pattern with precisely one FormatElement | +| Examples: | zos.image.vtam.logon=LOGON APPLID {0}
zos.image.SYSA.vtam.logon={0} | + +
+ +
+The logon initial text for the z/OS Image + +| Property: | The logon initial text for the z/OS Image | +| --------------------------------------- | :------------------------------------- | +| Name: | zos.image.logon.initial.text
zos.image.[imageId].logon.initial.text | +| Description: | A text string that is expected to be present on a 3270 terminal that has been connected to the z/OS image but before logon to any application system has been attempted. | +| Required: | No | +| Default value: | None | +| Valid values: | Any text string | +| Examples: | zos.image.logon.initial.text=VAMP
zos.image.SYSA.logon.initial.text=SYSA MAIN MENU |
@@ -283,12 +319,12 @@ The following properties are used to configure the z/OS Manager. | Property: | The run data set HLQ for the zOS Image | | --------------------------------------- | :------------------------------------- | -| Name: | zos.run.[image].dataset.hlq | -| Description: | The data set HLQ(s) for temporary data sets created on z/OS Image.
If CPS property zos.run.[image].dataset.hlq exists, then that is returned | +| Name: | zos.run.[imageId].dataset.hlq | +| Description: | The data set HLQ(s) for temporary data sets created on z/OS Image.
If CPS property zos.run.[imageId].dataset.hlq exists, then that is returned | | Required: | No | | Default value: | runuser.GALASA | | Valid values: | A data set name can be one name segment, or a series of joined name segments. Segments are limited to eight characters, the first of which must be alphabetic (A to Z) or special (# @ $). The remaining seven characters are either alphabetic, numeric (0 - 9), special, a hyphen (-). Name segments are separated by a period (.). | -| Examples: | zos.run.[image].dataset.hlq=USERID.GALASA
| +| Examples: | zos.run.SYSA.dataset.hlq=USERID.GALASA
| @@ -297,12 +333,12 @@ The following properties are used to configure the z/OS Manager. | Property: | The run data UNIX path prefix for the zOS Image | | --------------------------------------- | :------------------------------------- | -| Name: | zos.run.[image].unix.path.prefix | +| Name: | zos.run.[imageId].unix.path.prefix | | Description: | The UNIX path prefix for temporary data sets created on z/OS Image.
If CPS property zos.run.[image].unix.path.prefix exists, then that is returned | | Required: | No | | Default value: | /u/runuser/Galasa | | Valid values: | A valid path | -| Examples: | zos.run.[image].unix.path.prefix=/u/userid/Galasa
| +| Examples: | zos.run.SYSA.unix.path.prefix=/u/userid/Galasa
| @@ -339,12 +375,12 @@ The following properties are used to configure the z/OS Manager. | Property: | zOS Batch restrict processing to the server on the specified image | | --------------------------------------- | :------------------------------------- | -| Name: | zosbatch.batchjob.[imageid].restrict.to.image | +| Name: | zosbatch.batchjob.[imageId].restrict.to.image | | Description: | Use only the server (e.g. zOSMF, RSE API, etc) running on the image associated with the z/OS Batch job | | Required: | No | | Default value: | false | | Valid values: | true or false | -| Examples: | zosbatch.batchjob.MVSA.restrict.to.image=true
zosbatch.batchjob.default.restrict.to.image=false | +| Examples: | zosbatch.batchjob.SYSA.restrict.to.image=true
zosbatch.batchjob.default.restrict.to.image=false | @@ -353,12 +389,12 @@ The following properties are used to configure the z/OS Manager. | Property: | zOS Batch default input class | | --------------------------------------- | :------------------------------------- | -| Name: | zosbatch.default.[imageid].input.class | +| Name: | zosbatch.default.input.class
zosbatch.default.[imageId].input.class | | Description: | The default input class to set on the job card for submitted jobs | | Required: | No | | Default value: | A | | Valid values: | a valid JES input class literal | -| Examples: | zosbatch.default.MVSA.input.class=S
zosbatch.default.input.class=A | +| Examples: | zosbatch.default.SYSA.input.class=S
zosbatch.default.input.class=A | @@ -367,12 +403,12 @@ The following properties are used to configure the z/OS Manager. | Property: | zOS Batch job execution wait timeout | | --------------------------------------- | :------------------------------------- | -| Name: | zosbatch.batchjob.[imageid].timeout | +| Name: | zosbatch.batchjob.[imageId].timeout | | Description: | The value in seconds to wait for the z/OS Batch job execution to complete when submitted via zOSMF | | Required: | No | | Default value: | 350 | | Valid values: | 0 to {@link Integer#MAX_VALUE} | -| Examples: | zosbatch.batchjob.MVSA.timeout=350
zosbatch.batchjob.default.timeout=60 | +| Examples: | zosbatch.batchjob.SYSA.timeout=350
zosbatch.batchjob.default.timeout=60 | @@ -381,12 +417,12 @@ The following properties are used to configure the z/OS Manager. | Property: | zOS Batch jobname prefix | | --------------------------------------- | :------------------------------------- | -| Name: | zosbatch.jobname.[imageid].prefix | +| Name: | zosbatch.jobname.[imageId].prefix | | Description: | The z/OS Batch jobname prefix when submitted via zOSMF | | Required: | No | | Default value: | GAL | | Valid values: | 1-7 characters | -| Examples: | zosbatch.jobname.MVSA.prefix=JOB
zosbatch.jobname.default.prefix=XXX | +| Examples: | zosbatch.jobname.SYSA.prefix=JOB
zosbatch.jobname.default.prefix=XXX | @@ -395,12 +431,12 @@ The following properties are used to configure the z/OS Manager. | Property: | zOS Batch default MSGCLASS | | --------------------------------------- | :------------------------------------- | -| Name: | zosbatch.default.[imageid].message.class | +| Name: | zosbatch.default.class
zosbatch.default.[imageId].message.class | | Description: | The default message class to set on the job card for submitted jobs | | Required: | No | | Default value: | A | | Valid values: | a valid JES message class literal | -| Examples: | zosbatch.default.MVSA.message.class=S
zosbatch.default.message.class=A | +| Examples: | zosbatch.default.SYSA.message.class=S
zosbatch.default.message.class=A | @@ -409,12 +445,12 @@ The following properties are used to configure the z/OS Manager. | Property: | zOS Batch default message level | | --------------------------------------- | :------------------------------------- | -| Name: | zosbatch.default.[imageid].message.level | +| Name: | zosbatch.default.message.level
zosbatch.default.[imageId].message.level | | Description: | The default message level to set on the job card for submitted jobs | | Required: | No | | Default value: | (1,1) | | Valid values: | a valid JES message level | -| Examples: | zosbatch.default.MVSA.message.level=(1,1)
zosbatch.default.message.level=(2,0) | +| Examples: | zosbatch.default.SYSA.message.level=(1,1)
zosbatch.default.message.level=(2,0) | @@ -423,12 +459,12 @@ The following properties are used to configure the z/OS Manager. | Property: | zOS Batch job truncate JCL | | --------------------------------------- | :------------------------------------- | -| Name: | zosbatch.batchjob.[imageid].truncate.jcl.records | +| Name: | zosbatch.batchjob.[imageId].truncate.jcl.records | | Description: | The z/OSMF submit job will fail if supplied with JCL records greater than 80 characters. Setting this property to true will truncate any records to 80 characters and issue a warning message. | | Required: | No | | Default value: | true | | Valid values: | true or false | -| Examples: | zosbatch.batchjobe.MVSA.truncate.jcl.records=true
zosbatch.batchjob.default.truncate.jcl.records=false | +| Examples: | zosbatch.batchjob.SYSA.truncate.jcl.records=true
zosbatch.batchjob.default.truncate.jcl.records=false | @@ -437,12 +473,12 @@ The following properties are used to configure the z/OS Manager. | Property: | zOS Batch job use SYSAFF | | --------------------------------------- | :------------------------------------- | -| Name: | zosbatch.batchjob.[imageid].use.sysaff | +| Name: | zosbatch.batchjob.[imageId].use.sysaff | | Description: | Use the run the z/OS Batch job on the specified image by specifying {@code /*JOBPARM SYSAFF=[imageid]} | | Required: | No | | Default value: | true | | Valid values: | true or false | -| Examples: | zosbatch.batchjobe.MVSA.use.sysaff=true
zosbatch.batchjob.default.use.sysaff=false | +| Examples: | zosbatch.batchjob.SYSA.use.sysaff=true
zosbatch.batchjob.default.use.sysaff=false | @@ -451,7 +487,7 @@ The following properties are used to configure the z/OS Manager. | Property: | Restrict zOS console processing to the zOSMF server on the specified image | | --------------------------------------- | :------------------------------------- | -| Name: | zosconsole.console.[imageid].restrict.to.image | +| Name: | zosconsole.console.restrict.to.image
zosconsole.console.[imageId].restrict.to.image | | Description: | Use only the zOSMF server running on the image associated with the z/OS Console | | Required: | No | | Default value: | false | @@ -465,12 +501,12 @@ The following properties are used to configure the z/OS Manager. | Property: | zOS File the maximum number of items from a UNIX directory list | | --------------------------------------- | :------------------------------------- | -| Name: | zosfile.unix.[imageid].directory.list.max.items | +| Name: | zosfile.unix.[imageId].directory.list.max.items | | Description: | The maximum number of items the server (e.g. zOSMF, RSE API, etc) returns when listing the content of a UNIX directory | | Required: | No | | Default value: | 1000 | | Valid values: | 0 to 65535 | -| Examples: | zosfile.unix.[imageid].directory.list.max.items=1000
| +| Examples: | zosfile.unix.SYSA.directory.list.max.items=1000
| @@ -479,7 +515,7 @@ The following properties are used to configure the z/OS Manager. | Property: | zOS File restrict processing to the server on the specified image | | --------------------------------------- | :------------------------------------- | -| Name: | zosfile.file.[imageid].restrict.to.image | +| Name: | zosfile.file.restrict.to.image
zosfile.file.[imageId].restrict.to.image | | Description: | Use only the server (e.g. zOSMF, RSE API, etc) running on the image associated with the z/OS data set or file | | Required: | No | | Default value: | false | @@ -493,7 +529,7 @@ The following properties are used to configure the z/OS Manager. | Property: | zOS File UNIX permission bits to be used in creating the file or directory | | --------------------------------------- | :------------------------------------- | -| Name: | zosfile.[imageid].unix.file.permission | +| Name: | zosfile.[imageId].unix.file.permission
zosfile.[imageId].unix.file.permission | | Description: | The UNIX file or directory permission bits to be used in creating the file or directory | | Required: | No | | Default value: | None | diff --git a/src/markdown-pages/docs/running-simbank-tests/running-simbank-tests-cli-offline.md b/src/markdown-pages/docs/running-simbank-tests/running-simbank-tests-cli-offline.md index eb01c4ad..3c9c5390 100644 --- a/src/markdown-pages/docs/running-simbank-tests/running-simbank-tests-cli-offline.md +++ b/src/markdown-pages/docs/running-simbank-tests/running-simbank-tests-cli-offline.md @@ -48,7 +48,7 @@ In order to run the Galasa SimBanks tests you need to add some configuration inf ## Running the SimBank IVT test class by using the CLI -The SimBank tests are located in the `maven` directory of the `isolated.zip` downloadable file. Complete the following steps to run the SimBankIVT test that is provided with Galasa. The following example uses SimBank OBR version `0.39.0`. +The SimBank tests are located in the `maven` directory of the `isolated.zip` downloadable file. Complete the following steps to run the SimBankIVT test that is provided with Galasa. The following example uses SimBank OBR version `0.40.0`. Remember to initialise your local environment by running the `galasactl local init` command and to start the SimPlatform server by running the `run-simplatform.sh` script, as described in the [Running Galasa SimBank using the CLI offline](simbank-cli-offline) documentation. @@ -59,14 +59,14 @@ You are now ready to run a local Galasa test offline with just the contents of t On Mac or Unix: ``` galasactl runs submit local --log - \ ---obr mvn:dev.galasa/dev.galasa.simbank.obr/0.39.0/obr \ +--obr mvn:dev.galasa/dev.galasa.simbank.obr/0.40.0/obr \ --class dev.galasa.simbank.tests/dev.galasa.simbank.tests.SimBankIVT \ --localMaven file:////Users/youruserid/Downloads/isolated/maven ``` On Windows (Powershell): ``` galasactl runs submit local --log - ` ---obr mvn:dev.galasa/dev.galasa.simbank.obr/0.39.0/obr ` +--obr mvn:dev.galasa/dev.galasa.simbank.obr/0.40.0/obr ` --class dev.galasa.simbank.tests/dev.galasa.simbank.tests.SimBankIVT ` --localMaven file:////Users/youruserid/Downloads/isolated/maven ``` @@ -80,7 +80,7 @@ On Mac or Unix: ``` galasactl runs submit local --log - \ ---obr mvn:dev.galasa/dev.galasa.simbank.obr/0.39.0/obr \ +--obr mvn:dev.galasa/dev.galasa.simbank.obr/0.40.0/obr \ --class dev.galasa.simbank.tests/dev.galasa.simbank.tests.BasicAccountCreditTest \ --localMaven file:////Users/youruserid/Downloads/isolated/maven ``` @@ -89,7 +89,7 @@ On Windows (Powershell): ``` galasactl runs submit local --log - ` ---obr mvn:dev.galasa/dev.galasa.simbank.obr/0.39.0/obr ` +--obr mvn:dev.galasa/dev.galasa.simbank.obr/0.40.0/obr ` --class dev.galasa.simbank.tests/dev.galasa.simbank.tests.BasicAccountCreditTest ` --localMaven file:////Users/youruserid/Downloads/isolated/maven ``` diff --git a/src/markdown-pages/docs/running-simbank-tests/running-simbank-tests-cli.md b/src/markdown-pages/docs/running-simbank-tests/running-simbank-tests-cli.md index 2bb2a4d8..e9441990 100644 --- a/src/markdown-pages/docs/running-simbank-tests/running-simbank-tests-cli.md +++ b/src/markdown-pages/docs/running-simbank-tests/running-simbank-tests-cli.md @@ -50,7 +50,7 @@ In order to run the Galasa SimBanks tests you need to add some configuration inf The SimBank tests are held in the Galasa simplatform repository in GitHub. To start running the tests you need to clone the repository, if you have not already done so. To find out how to clone the cli repository, follow the instruction in the [Running Galasa SimBank online](../running-simbank-tests/simbank-cli) documentation. -After cloning the repository, complete the following steps to run the SimBankIVT test that is provided with Galasa. The following example uses SimBank OBR version `0.39.0` and Galasa uber OBR version `0.39.0`. +After cloning the repository, complete the following steps to run the SimBankIVT test that is provided with Galasa. The following example uses SimBank OBR version `0.40.0` and Galasa uber OBR version `0.40.0`. You can find the version of the `dev.galasa.simbank.obr` that you are using by looking in the `pom.xml` file in the `dev.galasa.simbank.obr` folder. The `dev.galasa.uber.obr` is the OBR that contains all the bundles that are needed for Galasa to work including Managers, any required dependencies, the framework, etc. The version of the `dev.galasa.uber.obr` depends on which version of Galasa you have installed. @@ -84,13 +84,13 @@ If you are a Mac or Linux user, the messages will be almost identical. On Mac or Unix: ``` galasactl runs submit local --log - \ ---obr mvn:dev.galasa/dev.galasa.simbank.obr/0.39.0/obr \ +--obr mvn:dev.galasa/dev.galasa.simbank.obr/0.40.0/obr \ --class dev.galasa.simbank.tests/dev.galasa.simbank.tests.SimBankIVT ``` On Windows (Powershell): ``` galasactl runs submit local --log - ` ---obr mvn:dev.galasa/dev.galasa.simbank.obr/0.39.0/obr ` +--obr mvn:dev.galasa/dev.galasa.simbank.obr/0.40.0/obr ` --class dev.galasa.simbank.tests/dev.galasa.simbank.tests.SimBankIVT ``` where: @@ -107,7 +107,7 @@ On Mac or Unix: ``` galasactl runs submit local --log - \ ---obr mvn:dev.galasa/dev.galasa.simbank.obr/0.39.0/obr \ +--obr mvn:dev.galasa/dev.galasa.simbank.obr/0.40.0/obr \ --class dev.galasa.simbank.tests/dev.galasa.simbank.tests.BasicAccountCreditTest ``` @@ -115,7 +115,7 @@ On Windows (Powershell): ``` galasactl runs submit local --log - ` ---obr mvn:dev.galasa/dev.galasa.simbank.obr/0.39.0/obr ` +--obr mvn:dev.galasa/dev.galasa.simbank.obr/0.40.0/obr ` --class dev.galasa.simbank.tests/dev.galasa.simbank.tests.BasicAccountCreditTest ``` diff --git a/src/markdown-pages/highlights.md b/src/markdown-pages/highlights.md index e0d67dce..2bb25a2a 100644 --- a/src/markdown-pages/highlights.md +++ b/src/markdown-pages/highlights.md @@ -17,7 +17,51 @@ We have the following available Slack channels: Access the Galasa source code in [GitHub](https://github.com/galasa-dev) and open issues in the [project management repository](https://github.com/galasa-dev/projectmanagement). -## 0.39.0 - Release Highlights +## 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)](./docs/ecosystem/role-based-access) 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. + +
+0.39.0 - Release Highlights - Forks and fork builds are now supported making it easier to contribute to Galasa! @@ -31,6 +75,7 @@ Access the Galasa source code in [GitHub](https://github.com/galasa-dev) and ope - This release also includes instability fixes, and dependency updates. +
0.38.0 - Release Highlights diff --git a/src/pages/index.js b/src/pages/index.js index 8a1b1158..b032fa9f 100644 --- a/src/pages/index.js +++ b/src/pages/index.js @@ -126,7 +126,7 @@ const IndexPage = () => ( Learn more