diff --git a/.vscode/tasks.json b/.vscode/tasks.json index 3576303ca..aee8e8097 100644 --- a/.vscode/tasks.json +++ b/.vscode/tasks.json @@ -6,7 +6,7 @@ { "label": "Serve (Development)", "type": "shell", - "command": "npm run develop", + "command": "npm run develop -- --host 0.0.0.0", "group": { "kind": "build" }, @@ -16,7 +16,7 @@ { "label": "Serve", "type": "shell", - "command": "npm run build && npm run serve", + "command": "npm run build && npm run serve -- --host 0.0.0.0", "group": { "kind": "build" }, diff --git a/src/data/nav.yaml b/src/data/nav.yaml index 1a68300c9..d36086b52 100644 --- a/src/data/nav.yaml +++ b/src/data/nav.yaml @@ -97,11 +97,13 @@ - title: Configuring authentication path: /docs/ecosystem/ecosystem-authentication - title: Configuring an Ecosystem using resource files - path: /docs/ecosystem/cps-yaml - - title: Updating credentials in an Ecosystem - path: /docs/ecosystem/ecosystem-update-creds + path: /docs/ecosystem/resources-yaml + - title: Managing credentials in an Ecosystem + path: /docs/ecosystem/ecosystem-manage-creds - title: Managing configuration properties - path: /docs/ecosystem/ecosystem-manage-cps + path: /docs/ecosystem/ecosystem-manage-cps + - title: Managing Ecosystem encryption keys + path: /docs/ecosystem/ecosystem-managing-encryption-keys - title: Managing tests in a Galasa Ecosystem path: /docs/manage-ecosystem items: 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 d0d683e86..e3178915b 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 @@ -25,6 +25,18 @@ The following versions of the Galasa CLI are available to download for different Complete the following steps to install Galasa for using the command line: +On Mac: + +1. On a Mac, the `homebrew` tool can be used to install the `galasactl` tool. Or you can follow the Unix instructions +2. Connect `homebrew` to the 'tap' it can use: `brew tap galasa-dev/tap` +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.38.0 for example): + `brew install --no-quarantine galasactl@0.38.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. + On Mac or Unix: 1. Find out the architecture of your machine by typing the command `uname -m` into your terminal. diff --git a/src/markdown-pages/docs/cli-command-reference/installing-offline.md b/src/markdown-pages/docs/cli-command-reference/installing-offline.md index 484408d2b..6a2e47eb8 100644 --- a/src/markdown-pages/docs/cli-command-reference/installing-offline.md +++ b/src/markdown-pages/docs/cli-command-reference/installing-offline.md @@ -31,11 +31,11 @@ Note: The example uses port `8080` but you can use a different port. docker load -i isolated.tar ``` -The following confirmation message is received: _Loaded image: icr.io/galasadev/galasa-distribution:main_. +The following confirmation message is received: _Loaded image: ghcr.io/galasa-dev/galasa-isolated:main_. 2. Run the container by using the following command: ``` -docker run -d -p 8080:80 --name galasa icr.io/galasadev/galasa-distribution:main +docker run -d -p 8080:80 --name galasa ghcr.io/galasa-dev/galasa-isolated:main ``` 3. Go to `http:\\localhost:8080` to view the running container. diff --git a/src/markdown-pages/docs/ecosystem/ecosystem-authentication.md b/src/markdown-pages/docs/ecosystem/ecosystem-authentication.md index dc527631e..9e4938353 100644 --- a/src/markdown-pages/docs/ecosystem/ecosystem-authentication.md +++ b/src/markdown-pages/docs/ecosystem/ecosystem-authentication.md @@ -3,13 +3,14 @@ path: "/docs/ecosystem/ecosystem-authentication" title: "Configuring authentication" --- -Before interacting with a Galasa Ecosystem using the Galasa command line tool (galasactl), you must be authenticated with it. Galasa uses personal access tokens to authenticate users who want to interact with a Galasa Ecosystem provided by the `GALASA_BOOTSTRAP` environment variable or through the `--bootstrap` flag. +Before interacting with a Galasa Ecosystem using the Galasa command line tool (`galasactl`), you must be authenticated with it. Any `galasactl` command which connects to a remote Galasa service needs to know the address of that service. A URL can be configured in the `GALASA_BOOTSTRAP` environment variable or it can be set on a per-command basis using the `--bootstrap` flag. +Once the `galasactl` tool knows which Galasa service to contact, it needs to be configured to be able to authenticate to that service. +To do that, the Galasa Web UI must be used to allocate a personal access token, which can be passed to the `galasactl` to be used. -Personal access tokens are stored in the `GALASA_TOKEN` property in the `galasactl.properties` file in your Galasa home folder. The `galasactl.properties` file is created when you run the `galasa local init` command. Setting the `GALASA_TOKEN` property in this file with a valid token value allows the galasactl tool to access and communicate with an Ecosystem on behalf of the user. +A personal access tokens is stored in the `GALASA_TOKEN` property in the `galasactl.properties` file in your Galasa home folder, or in the `GALASA_TOKEN` environment variable. The `galasactl.properties` file is created when you run the `galasa local init` command. Setting the `GALASA_TOKEN` property in this file with a valid token value allows the galasactl tool to access and communicate with an Ecosystem on behalf of the user. - -If you have [installed your Galasa Ecosystem](../ecosystem/ecosystem-installing-k8s) by using the Galasa Ecosystem Helm chart that is provided with Galasa, you will have access to the Galasa Web UI. To get a value for the `GALASA_TOKEN` property, log into the Galasa Web UI and request a personal access token which can be copied into the `GALASA_TOKEN` property. The instructions on how to do this are displayed in a dialog box in the Galasa Web UI. You can choose to set the token as an environmental variable but the value would not persist across terminals, so is only valid for that session. +If you have [installed your Galasa Ecosystem](../ecosystem/ecosystem-installing-k8s) by using the Galasa Ecosystem Helm chart that is provided with Galasa, you will have access to the Galasa Web UI. To get a value for the `GALASA_TOKEN` property, log into the Galasa Web UI and request a personal access token (using the 'My Settings' page) which can be copied into the `GALASA_TOKEN` property. The instructions on how to do this are displayed in a dialog box in the Galasa Web UI. You can choose to set the token as an environmental variable but the value would not persist across terminals, so is only valid for that session. ## Authentication architecture @@ -18,10 +19,13 @@ The following diagram shows the architecture for the authentication process: ![Galasa ecosystem architecture:](ecosystem-cluster-auth.svg) -When a user logs into the Galasa Web UI via their browser, the Web UI contacts the Galasa API server which in turn talks to a Dex server, providing it with the user ID. The Dex server talks to an identity provider, for example GitHub or LDAP, to authenticate that user. If the user is successfully authenticated, the provider returns an access token to the Dex server which sends that token to Galasa API server. The token is then sent to the Galasa Web UI where it is visible to the user. The user can then configure that token into the galasactl command line tool by updating the `GALASA_TOKEN` property in the `galasactl.properties` file. The user can then be authenticated each time the galasactl tool is used to log into a Galasa Ecosystem. +When a user logs into the Galasa Web UI via their browser, the Web UI contacts the Galasa API server which in turn talks to a Dex server, providing it with the user ID. The Dex server talks to an identity provider, for example GitHub or LDAP, to authenticate that user. If the user is successfully authenticated, Dex returns a bearer token to the Galasa API server, which in turn passes the token to the Galasa Web UI. The bearer token is then stored in a cookie by the web browser, to be used in further interactions with the Galasa Web UI until the user logs out of the web application, or the token expires. + +Once logged-in to the Web UI, the user can then create a new access token token (using the 'My Settings' page). This provides a secret access token which must be copied from the Web UI panel and made available to the `galasactl` command line tool. The access token can be placed in the `GALASA_TOKEN` property in the `galasactl.properties` file, or the `GALASA_TOKEN` environment variable. -On a successful login, a `bearer-token.json` file is created in the Galasa home directory. This file contains a bearer token that galasactl uses to authenticate requests when communicating with a Galasa Ecosystem. If the bearer token expires, galasactl automatically attempts to re-authenticate with the Galasa Ecosystem using the properties in the `galasactl.properties` file within the Galasa home directory. +The `galasactl` tool will login implicitly when it needs to contact the remote Galasa service. Or the login state can be explicitly controlled using the `galasactl auth login` and `galasactl auth logout` commands. +On a successful login using the `galasactl` tool, the `GALASA_TOKEN` will be used to create a new temporary bearer token, which is stored in the `bearer-tokens` folder in the Galasa home directory. This file contains a bearer token that galasactl uses to authenticate requests when communicating with a Galasa Ecosystem. If the bearer token expires, galasactl automatically attempts to re-authenticate with the Galasa Ecosystem using the configured `GALASA_TOKEN`. ### Logging in to a Galasa Ecosystem using the auth login command @@ -31,7 +35,7 @@ You can log in to a Galasa Ecosystem explicitly by using the `galasactl auth log ### Logging out of a Galasa Ecosystem using the auth logout command -To log out of a Galasa Ecosystem using galasactl, you can use the `galasactl auth logout` command. If you run a galasactl command that interacts with an Ecosystem while logged out, galasactl will attempt to automatically log in using the properties in your `galasactl.properties` file within your Galasa home directory. +To log out of a Galasa Ecosystem using galasactl, you can use the `galasactl auth logout` command. If you run a galasactl command that interacts with an Ecosystem while logged out, galasactl will attempt to automatically log again in using the configured `GALASA_TOKEN`. ### Listing personal access tokens @@ -51,6 +55,21 @@ Total:2 The returned token list is sorted in creation date order, with the earliest creation date first. The description information matches the description that is provided by the user when creating a new access token from the Galasa Web UI. +You can also get tokens for a specific user + +``` +> galasactl auth tokens get --user m.smith@gmail.com +tokenid created(YYYY/MM/DD) user description +09823128318238 2024-02-03 m.smith@gmail.com Ecosystem1 access + +Total:1 +``` + +If you are unsure which user id you are currently using, you can find out with this command: +``` +> galasactl users get --id me +id: m.smith@gmail.com +``` ### Revoking personal access tokens @@ -59,10 +78,20 @@ If a user moves to a new role, or loses a laptop with their personal access toke You can retrieve a list of available personal access tokens that have been created, along with their token IDs, by running the `galasactl auth tokens get` command, as described in the previous section. -Run the following command to revoke a personal access token with the token ID `myId`: +Run the following command to revoke a personal access token with the token ID `myId` substituted for the numeric value visible from the `galasactl auth tokens get` command. + +``` +galasactl auth tokens delete --tokenid {myId} +``` +For example: ``` -galasactl auth tokens delete --tokenid myId +> galasactl auth tokens get --user m.smith@gmail.com +tokenid created(YYYY/MM/DD) user description +09823128318238 2024-02-03 m.smith@gmail.com Ecosystem1 access + +Total: 1 +> galasactl auth tokens delete --tokenid 09823128318238 ``` *Note:* The `galasactl auth tokens delete` command revokes personal access tokens that a user creates through the Galasa Web UI. When a user runs a CLI command that talks to the Ecosystem, the CLI uses the personal access token to get a JSON Web Token (JWT). A JWT is a separate, temporary token that identifies a user and is used in galasactl commands to talk to the API server. JWTs cannot be revoked, but they do expire, so a user can continue to run CLI commands after revoking their personal access token until their JWT expires. You can remove the JWT that is stored on a user's machine instead of having to wait for the JWT to expire, by running the `galasactl auth logout` command on that machine. diff --git a/src/markdown-pages/docs/ecosystem/ecosystem-installing-k8s.md b/src/markdown-pages/docs/ecosystem/ecosystem-installing-k8s.md index 8b728c791..ff0c3fe29 100644 --- a/src/markdown-pages/docs/ecosystem/ecosystem-installing-k8s.md +++ b/src/markdown-pages/docs/ecosystem/ecosystem-installing-k8s.md @@ -53,30 +53,28 @@ Complete the following steps to install a Galasa Ecosystem by using Helm: helm repo add galasa https://galasa-dev.github.io/helm ``` - If the repository exists, run the ```helm repo update``` command to get the latest versions of the packages and then run ```helm search repo galasa``` to see the available charts.
- _Note:_ The Galasa Ecosystem Helm chart deploys three persistent volumes (PVs). If you need to provide a Kubernetes storage class for these PVs, download the values.yaml file and update the `storageClass` value in the file with the name of a valid storage class on your cluster. If you are deploying to minikube, you can optionally use the standard storage class that is created for you by minikube, but this is not required. -1. Download the values.yaml file if you have not done so already, and edit the values of the following properties: + _Note:_ The Galasa Ecosystem Helm chart deploys three persistent volumes (PVs). If you need to provide a Kubernetes storage class for these PVs, download the `values.yaml` file for your chosen Galasa Ecosystem version from the Galasa Helm repository's releases page and update the `storageClass` value in the file with the name of a valid storage class on your cluster. If you are deploying to minikube, you can optionally use the standard storage class that is created for you by minikube, but this is not required. +2. Download the values.yaml file for your chosen Galasa Ecosystem version from the Galasa Helm repository's releases page if you have not done so already, and edit the values of the following properties: - Set `galasaVersion` to the version of Galasa that you want to run. (See the [Releases](/releases) documentation for released versions). To ensure that each pod in the Ecosystem is running at the same level, do not use `latest` as the Galasa version. - - Set `externalHostname` to the DNS hostname or IP address of the Kubernetes node that is used to access the Galasa Ecosystem services. If you are deploying to minikube, the cluster's IP address can be retrieved by running `minikube ip`. + - Set `externalHostname` to the DNS hostname that you wish to use to access the Galasa Ecosystem services. After updating the `galasaVersion` and `externalHostname` values, complete the following instructions to set up Ingress for your Ecosystem. ### Configuring Ingress -By default, the Galasa Ecosystem Helm chart enables Ingress to reach services that are running within a Kubernetes cluster. To learn more about Ingress, see the Kubernetes Documentation. +The Galasa Ecosystem Helm chart uses Ingress to reach services that are running within a Kubernetes cluster. To learn more about Ingress, see the Kubernetes Documentation. -*Note:* If you are deploying to minikube and are using Ingress to expose services, ensure the NGINX Ingress controller is enabled by running the `minikube addons enable ingress` command. +*Note:* If you are deploying to minikube, ensure the NGINX Ingress controller is enabled by running the `minikube addons enable ingress` command. Assuming that your Ingress controller is set up on your Kubernetes cluster, configure the use of Ingress in your Ecosystem by completing the following updates to the values that are listed under the `ingress` section within your `values.yaml` file: 1. Replace the `ingressClassName` value with the name of the IngressClass that is configured in your cluster. By default, `nginx` is used. -1. If you are using HTTPS, add a `tls` configuration within the `ingress` section, specifying the `hosts` list and a `secretName` value corresponding to the name of the Kubernetes Secret that contains your TLS private key and certificate. See the Kubernetes Documentation for information on how to set up TLS. +2. If you are using HTTPS, add a `tls` configuration within the `ingress` section, specifying the `hosts` list and a `secretName` value corresponding to the name of the Kubernetes Secret that contains your TLS private key and certificate. See the Kubernetes Documentation for information on how to set up TLS. After updating the values under the `ingress` section of your `values.yaml` file, complete the following instructions to configure Dex in your Ecosystem. ### Configuring Dex -*Note:* The Ecosystem chart's use of Dex is still under development and is subject to change. - For Galasa version 0.32.0 and later, Dex is used to authenticate users interacting with a Galasa Ecosystem. To configure Dex in your Ecosystem, complete the following steps to update your `values.yaml` file: @@ -191,20 +189,18 @@ helm test where: - is the name that you gave the Ecosystem during installation +`` is the name that you gave the Ecosystem during installation When the `helm test` command ends and displays a success message, the Ecosystem is set up correctly and is ready to be used. ## Accessing services -### Using Ingress - -When using Ingress, the URL of the Ecosystem bootstrap will be your external hostname, followed by `/api/bootstrap`. +The URL of the Ecosystem bootstrap will be your external hostname, followed by `/api/bootstrap`. For example, if the external hostname that you provided was `example.com` and you provided values for using TLS, the bootstrap URL would be `https://example.com/api/bootstrap`. This is the URL that you would enter into a galasactl command's `--bootstrap` option to interact with your Ecosystem. -If you have enabled Ingress and are deploying to minikube, add an entry to your `/etc/hosts` file, ensuring the IP address matches the output of `minikube ip`. For example: +If you are deploying to minikube, add an entry to your `/etc/hosts` file, ensuring the IP address matches the output of `minikube ip`. For example: ```console 192.168.49.2 example.com @@ -213,26 +209,19 @@ If you have enabled Ingress and are deploying to minikube, add an entry to your ## Running Galasa tests -To reconfigure Galasa to point to the Galasa Ecosystem that you created, you need to edit the bootstrap. The bootstrap contains the information that Galasa needs to bring up a framework to connect to an Ecosystem. To find the URL of the Ecosystem bootstrap, run the following command: -``` -kubectl get svc -``` - -Combine the information with the external hostname that you provided to form the bootstrap URL so that the bootstrap is the external host name followed by `/api/bootstrap`. For example, if the external hostname is `example.com`, the bootstrap URL will be `http://example.com/api/boostrap`. - -You can then deploy your Galasa tests to a Maven repository and set up a test stream. For more information on writing tests, see the Writing your own independent Galasa tests documentation. +Once you have successfully installed the Ecosystem, you can then deploy your Galasa tests to a Maven repository and set up a test stream. For more information on managing tests, see the Managing tests in a Galasa Ecosystem documentation. ## 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.37.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.38.0 - by running the following command: On Mac or Unix: ```console helm repo update \ helm upgrade galasa/ecosystem --reuse-values \ ---set galasaVersion=0.37.0 --wait +--set galasaVersion=0.38.0 --wait ``` On Windows (Powershell): @@ -240,14 +229,13 @@ On Windows (Powershell): ```console helm repo update ` helm upgrade galasa/ecosystem --reuse-values ` ---set galasaVersion=0.37.0 --wait +--set galasaVersion=0.38.0 --wait ``` where:
- `galasaVersion` is set to the version that you want to use and
- `` is the name that you gave to the Ecosystem during installation - ### Troubleshooting - Check the logs by running the ```kubectl logs``` command. diff --git a/src/markdown-pages/docs/ecosystem/ecosystem-manage-cps-yaml.md b/src/markdown-pages/docs/ecosystem/ecosystem-manage-cps-yaml.md deleted file mode 100644 index cdafee9d4..000000000 --- a/src/markdown-pages/docs/ecosystem/ecosystem-manage-cps-yaml.md +++ /dev/null @@ -1,115 +0,0 @@ ---- -path: "/docs/ecosystem/cps-yaml" -title: "Configuring an Ecosystem using resource files" ---- - -You might want to create or update a number of different Galasa properties and associated values at the same time, for example to configure a different Galasa Ecosystem. A good way to do this is by using a yaml file containing property resources and associated values to set the configuration of your Ecosystem. - -The topic [Managing integrated test runs](../ecosystem/ecosystem-manage-cps) describes how to use the `galasactl properties get` command with the `--format yaml` flag specified to extract a yaml file which describes Galasa properties and property values. - -If more than one property is returned, each property is separated in the file by three dashes, `---`, as shown in the following example: - -``` -apiVersion: galasa-dev/v1alpha1 -kind: GalasaProperty -metadata: - name: engine.LOCAL.hostname - namespace: docker -data: - value: 127.0.0.1 ---- -apiVersion: galasa-dev/v1alpha1 -kind: GalasaProperty -metadata: - name: engine.REMOTE.hostname - namespace: docker -data: - value: 103.67.89.6 -``` - -You can update the values in this yaml file and then create, update, or apply those updates by using the galasactl command line tool, as described in the following section. - - -Alternatively, if you want to create a new yaml file, you can do so but you must use the following example format: - - -``` -apiVersion: galasa-dev/v1alpha1 -kind: GalasaProperty -metadata: - name: my.property1 - namespace: myNamespace1 -data: - value: myValue1 ---- -apiVersion: galasa-dev/v1alpha1 -kind: GalasaProperty -metadata: - name: my.property2 - namespace: myNamespace2 -data: - value: myValue2 -``` - -where: -- `apiVersion` is the version of the API that you are using -- `kind` is the type of resource you want to create or update. The current available value is `GalasaProperty` -- `name` is the name of the property that you want to create or update -- `namespace` is the namespace in which the property is contained in the configuration properties store (cps.properties). -- `value` is the value that you want to assign to the specified property in the specified namespace - - -You can define multiple properties and values in the same yaml file by separating them using three dashes, `---`, as shown in the example. - -You can save the file with a `.yaml` or `.yml` file extension. - - - -### Creating and updating properties using a yaml resource file - -You can use the galasactl command line tool to sumbit a yaml file to create new properties, or to update existing ones. - -Use the following command to create a new property or properties in a specified namespace by using a yaml file called `myFile.yaml`: - -``` -galasactl resources create -f myFile.yaml -``` - -Use the following command to update an existing property or properties by using a yaml file called `myFile.yaml`: - -``` -galasactl resources update -f myFile.yaml -``` - -Use the following command to create a new property if the property does not exist and update an existing property if the property does exist by using a yaml file called `myFile.yaml`: - -``` -galasactl resources apply -f myFile.yaml -``` - -An error message is returned if the action is not able to complete successfully. For example, if a property could not be created in a particular namespace because the property already exists in that namespace. - - -### Deleting properties using a yaml resource file - -When maintaining an Ecosystem, you might have a yaml file containing Galasa property resource definitions and want to delete a corresponding set of properties stored on the server in an Ecosystem. You can do this by using the following command: - -``` -galasactl resources delete -f {filename} -``` - -where: - -`{filename}` is the name of the yaml file that contains the list of properties that you want to delete. - -For example, you might have a list of resources that you want to delete in a file called `resources_to_delete.yaml`. You can delete those resources by running the following command: - -``` -galasactl resources delete -f resources_to_delete.yaml -``` - - -For a complete list of supported parameters see the galasactl resources documentation in the Galasa cli repository. - - - diff --git a/src/markdown-pages/docs/ecosystem/ecosystem-manage-cps.md b/src/markdown-pages/docs/ecosystem/ecosystem-manage-cps.md index cafb43551..7cf164aff 100644 --- a/src/markdown-pages/docs/ecosystem/ecosystem-manage-cps.md +++ b/src/markdown-pages/docs/ecosystem/ecosystem-manage-cps.md @@ -23,6 +23,10 @@ When running tests in the Galasa Ecosystem, where tests are run on a Kubernetes You can set, retrieve and delete properties that are held in the CPS by using the `galasasctl properties` commands. The ability to manage these properties directly makes it easier for testers to set parameters and credentials on the Ecosystem for tests to read and use at runtime. System administrators can use the CLI to set Ecosystem-wide configuration properties after Ecosystem installation. +By default, properties are are always retrieved from the REST service individually during test class runs. +If the amount of network requests to retrieve properties from the CPS causes any problems, you can enable a cache by setting the `framework.cps.rest.cache.is.enabled` property to `true`. +When the cache is enabled, all CPS properties are loaded at the start of a test class run. + ## About the Configuration Properties Store diff --git a/src/markdown-pages/docs/ecosystem/ecosystem-manage-creds.md b/src/markdown-pages/docs/ecosystem/ecosystem-manage-creds.md new file mode 100644 index 000000000..d48f75049 --- /dev/null +++ b/src/markdown-pages/docs/ecosystem/ecosystem-manage-creds.md @@ -0,0 +1,156 @@ +--- +path: "/docs/ecosystem/ecosystem-manage-creds" +title: "Managing credentials in an Ecosystem" +--- + +[Setting secrets](#setting-secrets)
+[Getting secrets](#getting-secrets)
+[Deleting secrets](#deleting-secrets)
+ +It is likely that a test will need to pass credentials to the application being tested. For example, as HTTP credentials or as username and password values entered onto a 3270 screen. In a Galasa Ecosystem the credentials store, which is hosted in the etcd server, securely provides the credentials (for example, password, username, and personal access token) that are required for a test to run in automation. + +You can set a Username, UsernamePassword, Token, or UsernameToken secret in the credentials store by using the Galasa CLI tool's `secrets` commands. The ability to set these properties means that you can supply test cases with the credentials and tokens that they need to run. + +The following examples show how you can update the credentials store, and will refer to credentials as secrets. The example commands that are provided in the following sections assume that the `GALASA_BOOTSTRAP` environment variable is set, so the `--bootstrap` flag is not required in the command. + +## Creating and updating secrets + +The `galasactl secrets set` command can be used to create or update secrets in the credentials store. The command's `--username`, `--password`, and `--token` flags can be used in different combinations to create different types of secret. + +Optionally, a description can be provided when setting secrets using the `--description` flag to provide useful information as to what the secrets are used for. + +For example, a UsernamePassword secret can be created by supplying `--username` and `--password`: + +``` +galasactl secrets set --name SYSTEM1 --username "my-username" --password "my-password" --description "an example secret" +``` + +A UsernameToken secret can be created by supplying `--username` and `--token`: + +``` +galasactl secrets set --name SYSTEM1 --username "my-username" --token "my-token" +``` + +A Token secret can be created by supplying `--token` on its own: +``` +galasactl secrets set --name SYSTEM1 --token "my-token" +``` + +A Username secret can be created by supplying `--username` on its own: + +``` +galasactl secrets set --name SYSTEM1 --username "my-username" +``` + +Base64-encoded values can be supplied using the `--base64-username`, `--base64-password`, and `--base64-token` flags. These base64 flags can be used with the non-encoded flags described above to supply values in different encoding schemes. However, you cannot provide the same value in multiple encoding schemes (e.g. using `--base64-username` and `--username` in the same command). + +For example, to create a UsernamePassword secret where both the username and password are base64-encoded: + +``` +galasactl secrets set --name SYSTEM1 --base64-username "my-base64-username" --base64-password "my-base64-password" +``` + +To create a UsernameToken secret where only the token is base64-encoded: + +``` +galasactl secrets set --name SYSTEM1 --username "my-base64-username" --base64-token "my-base64-token" +``` + +Once a secret has been created, you can change the type of the secret by supplying your desired secret type using the `--type` flag. When supplying the `--type` flag, all values for the new secret type must be provided. To find out what secret types are supported, run `galasactl secrets set --help`. + +For example, to create a UsernamePassword secret and then change it to a Token secret: + +``` +galasactl secrets set --name SYSTEM1 --username "my-username" --password "my-password" +galasactl secrets set --name SYSTEM1 --token "my-token" --type Token +``` + +Updated credentials are now available for a test to run in automation on a Galasa Ecosystem. + +For a complete list of supported parameters see the galasactl secrets set documentation in the CLI repository. + +## Getting secrets + +You can use the `galasactl secrets get` command to get secrets stored in the credentials store to verify that the secrets exist and are populated correctly. You can also filter results to retrieve a specific secret by providing its name in `galasactl secrets get` commands. + +The following table shows the available output formats that can be provided as part of the `galasactl secrets get` command: + +| Name | Description | +| :---- | :-------- | +| `--format summary` | The default format is _summary_. Summary format is useful if you need a quick, high-level overview. If you omit the `--format` flag in the command, results are returned in summary format. You can set the summary format explicitly by setting the `--format summary` flag in the `galasactl secrets get` command. | +| `--format yaml` | The results from `galasactl secrets get` are returned as GalasaSecret resources in YAML format. This YAML content can then be used in `galasactl resources` commands to create, update, and delete secrets using a YAML file. See [Configuring an Ecosystem using resource files](../ecosystem/resources-yaml) for more details.| + +For example, you can use the following command to retrieve all secrets in `yaml` format: + +``` +galasactl secrets get --format yaml +``` + +For a complete list of supported parameters see the galasactl secrets get documentation in the CLI repository. + +### Getting all secrets + +To retrieve all secrets stored in a Galasa Ecosystem, run the following command: +``` +galasactl secrets get +``` + +This will display the retrieved secrets in a summary format: + +``` +name type last-updated(UTC) last-updated-by description +SIMBANK UsernamePassword 2024-11-01 10:43:06 galasa-user credentials for simbank +SYSTEM2 Token 2024-11-01 10:43:41 galasa-user2 example access token +SYSTEM1 Username 2024-11-01 10:42:46 galasa-user3 example secret + +Total:3 +``` + +### Get a secret by name + +To retrieve a secret with a specific name, use the following example command: + +``` +galasactl secrets get --name {mysecret} +``` + +where `{mysecret}` is the name of the secret that you want to get. + +For example, to view a secret named `SYSTEM1`, run the following command: + +``` +galasactl secrets get --name SYSTEM1 +``` + +The following example shows the returned secret: + +``` +name type description last-updated(UTC) last-updated-by +SYSTEM1 UsernamePassword an example secret 2024-10-30 16:23:49 galasa-user + +Total:1 +``` + +## Deleting secrets + +When a secret is no longer used or required by tests, it can be deleted from the Galasa Ecosystem using the `galasactl secrets delete` command, supplying the name of the secret as part of the command. + +To delete a specific secret, use the following command: + +``` +galasactl secrets delete --name {mysecret} +``` + +where: +`{mysecret}` is the name of the secret that you want to delete. + + +For example, to delete a secret called `SIMBANK`, run the following command: + +``` +galasactl secrets delete --name SIMBANK +``` + +If the secret does not exist, an error will be displayed to indicate that the secret could not be found. + +For a complete list of supported parameters see the galasactl secrets delete documentation in the CLI repository. diff --git a/src/markdown-pages/docs/ecosystem/ecosystem-manage-resources.md b/src/markdown-pages/docs/ecosystem/ecosystem-manage-resources.md new file mode 100644 index 000000000..43cf2f2e3 --- /dev/null +++ b/src/markdown-pages/docs/ecosystem/ecosystem-manage-resources.md @@ -0,0 +1,206 @@ +--- +path: "/docs/ecosystem/resources-yaml" +title: "Configuring an Ecosystem using resource files" +--- + +You might want to create or update a number of different Galasa properties and associated values at the same time, for example to configure a different Galasa Ecosystem. A good way to do this is by using a YAML file containing Galasa resources and their associated values to set the configuration of your Ecosystem, as described in the [Creating and updating resources using a YAML resource file](#setting-resources) section. + +## Configuration Properties as GalasaProperty resources + +The topic [Managing integrated test runs](../ecosystem/ecosystem-manage-cps) describes how to use the `galasactl properties get` command with the `--format yaml` flag specified to extract a YAML file which describes Galasa properties and property values. + +If more than one property is returned, each property is separated in the file by three dashes, `---`, as shown in the following example: + +```yaml +apiVersion: galasa-dev/v1alpha1 +kind: GalasaProperty +metadata: + name: engine.LOCAL.hostname + namespace: docker +data: + value: 127.0.0.1 +--- +apiVersion: galasa-dev/v1alpha1 +kind: GalasaProperty +metadata: + name: engine.REMOTE.hostname + namespace: docker +data: + value: 103.67.89.6 +``` + + +Alternatively, if you want to create a new YAML file, you can do so but you must use the following example format: + + +```yaml +apiVersion: galasa-dev/v1alpha1 +kind: GalasaProperty +metadata: + name: my.property1 + namespace: myNamespace1 +data: + value: myValue1 +--- +apiVersion: galasa-dev/v1alpha1 +kind: GalasaProperty +metadata: + name: my.property2 + namespace: myNamespace2 +data: + value: myValue2 +``` + +where: +- `apiVersion` is the version of the API that you are using +- `name` is the name of the property that you want to create or update +- `namespace` is the namespace in which the property is contained in the configuration properties store (cps.properties). +- `value` is the value that you want to assign to the specified property in the specified namespace + + +You can define multiple properties and values in the same YAML file by separating them using three dashes, `---`, as shown in the example. + +You can save the file with a `.yaml` or `.yml` file extension. + + +## Credentials as GalasaSecret resources + +The topic [Managing credentials in an Ecosystem](../ecosystem/ecosystem-manage-creds) describes how to use the `galasactl secrets get` command with the `--format yaml` flag specified to extract a YAML file which describes Galasa secrets. + +If more than one secret is returned, each secret is separated in the file by three dashes, `---`, as shown in the following example: + +```yaml +apiVersion: galasa-dev/v1alpha1 +kind: GalasaSecret +metadata: + name: SYSTEM1 + type: UsernamePassword + encoding: base64 + description: an example username and password secret + lastUpdatedTime: + lastUpdatedBy: myuser +data: + username: + password: +--- +apiVersion: galasa-dev/v1alpha1 +kind: GalasaSecret +metadata: + name: SYSTEM2 + type: Token + encoding: base64 + description: an example token secret + lastUpdatedTime: + lastUpdatedBy: anotheruser +data: + token: +``` + +You can update the values in this YAML file and then create, update, or apply those updates by using the galasactl command line tool, as described in the following section. + + +Alternatively, if you want to create a new YAML file, you can do so using the following example format: + + +```yaml +apiVersion: galasa-dev/v1alpha1 +kind: GalasaSecret +metadata: + name: SYSTEM1 + type: UsernameToken + description: an example username and token secret +data: + username: + token: +--- +apiVersion: galasa-dev/v1alpha1 +kind: GalasaSecret +metadata: + name: SYSTEM2 + type: Username + encoding: base64 + description: an example username secret +data: + username: +``` + +where: +- `apiVersion` is the version of the API that you are using +- `name` is the name of the secret that you want to create or update +- `type` is the type of secret that you want to create or update. Supported values are: `Username`, `UsernamePassword`, `UsernameToken`, and `Token` +- `encoding` is an optional encoding scheme applied to all fields in the `data` section. The currently available value for this is `base64`. If this is not provided, then the fields in the `data` section are assumed to be provided without any encoding applied +- `description` is an optional field that allows you to supply a description associated with the secret being created or updated +- `username` is the username value to be set for a secret, and is provided when the `type` is `Username`, `UsernamePassword`, or `UsernameToken` +- `password` is the password value to be set for a secret, and is provided when the `type` is `UsernamePassword` +- `token` is the token value to be set for a secret, and is provided when the `type` is `Token` or `UsernameToken` + + +You can define multiple secrets in the same YAML file by separating them using three dashes, `---`, as shown in the example. + +You can save the file with a `.yaml` or `.yml` file extension. + + +## Creating and updating resources using a YAML file + +You can use the galasactl command line tool to submit a YAML file to create new Galasa resources, including properties and credentials, or to update existing ones. The YAML files can contain different types of Galasa resources, where each resource is separated by three dashes `---`. For example, a GalasaProperty resource and a GalasaSecret resource can both be created using the following format: + +```yaml +apiVersion: galasa-dev/v1alpha1 +kind: GalasaSecret +metadata: + name: SYSTEM1 + type: Token + description: an example token secret +data: + token: myToken +--- +apiVersion: galasa-dev/v1alpha1 +kind: GalasaProperty +metadata: + name: my.property1 + namespace: myNamespace1 +data: + value: myValue1 +``` + +Use the following command to create Galasa resources by using a YAML file called `myFile.yaml`: + +``` +galasactl resources create -f myFile.yaml +``` + +Use the following command to update Galasa resources by using a YAML file called `myFile.yaml`: + +``` +galasactl resources update -f myFile.yaml +``` + +Use the following command to create a new Galasa resource if the resource does not exist or update an existing resource by using a YAML file called `myFile.yaml`: + +``` +galasactl resources apply -f myFile.yaml +``` + +An error message is returned if the action is not able to complete successfully. For example, if a property could not be created in a particular namespace because the property already exists in that namespace. + + +## Deleting resources using a YAML file + +When maintaining an Ecosystem, you might have a YAML file containing Galasa property resource definitions and want to delete a corresponding set of Galasa resources stored on the server in an Ecosystem. You can do this by using the following command: + +``` +galasactl resources delete -f {filename} +``` + +where: + +`{filename}` is the name of the YAML file that contains the list of Galasa resources that you want to delete. + +For example, you might have a list of resources that you want to delete in a file called `resources_to_delete.yaml`. You can delete those resources by running the following command: + +``` +galasactl resources delete -f resources_to_delete.yaml +``` + + +For a complete list of supported parameters see the galasactl resources documentation in the Galasa CLI repository. diff --git a/src/markdown-pages/docs/ecosystem/ecosystem-managing-encryption-keys.md b/src/markdown-pages/docs/ecosystem/ecosystem-managing-encryption-keys.md new file mode 100644 index 000000000..ddda29bb2 --- /dev/null +++ b/src/markdown-pages/docs/ecosystem/ecosystem-managing-encryption-keys.md @@ -0,0 +1,127 @@ +--- +path: "/docs/ecosystem/ecosystem-managing-encryption-keys" +title: "Managing Ecosystem encryption keys" +--- + +To maintain the security of your Galasa Ecosystem, you may wish to replace the encryption key being used to encrypt credentials in the Galasa Ecosystem's credentials store with a new encryption key, and re-encrypt all your existing credentials using the new key. + +**Before proceeding to rotate encryption keys, it is highly recommended to make a backup of the existing credentials stored in your Galasa Ecosystem by running the following command using the Galasa CLI tool:** + +```console +galasactl secrets get --format yaml > /path/to/backup/file.yaml +``` + +**where `/path/to/backup/file.yaml` is either an absolute or relative path of your choice to a file where the backup will be stored.** + +## Prerequisites + +The following command-line utilities must be installed: + +- [kubectl](https://kubernetes.io/docs/tasks/tools) (v1.30.3 or later) +- [galasactl](../cli-command-reference/installing-cli-tool.md) (0.38.0 or later) +- openssl (3.3.2 or later) + +You must have the correct permissions to read and update Kubernetes Secrets in the Kubernetes namespace that you have installed your Galasa Ecosystem within. + +You must also have a valid personal access token for your Galasa Ecosystem set on your machine so that you can retrieve and update secrets with `galasactl`. + +## Automated steps + +For Linux and macOS, you can download the rotate-encryption-keys.sh script for your installed Galasa Ecosystem version from the Galasa Helm repository's releases page and run the script via the command-line to simplify the process of rotating encryption keys and re-encrypting credentials. + +The following flags can be supplied when running the script: +- `--release-name ` **Required**. The Helm release name provided when installing the Galasa Ecosystem Helm chart (see [Installing your Galasa Ecosystem](#installing-your-galasa-ecosystem)) +- `--namespace ` Optional. The Kubernetes namespace where your Galasa Ecosystem is installed +- `--bootstrap ` Optional. The bootstrap URL of the Galasa Ecosystem that is being serviced. Not required if the `GALASA_BOOTSTRAP` environment variable is set and is pointing to the correct bootstrap URL. Overrides the existing `GALASA_BOOTSTRAP` environment variable value if set + +For example: + +```console +./rotate-encryption-keys.sh --release-name example --namespace galasa-dev +``` + +The `rotate-encryption-keys.sh` script will automatically update the current encryption key with a new one, and then restart your Galasa Ecosystem's API and engine controller pods so that they can pick up the new encryption key. After rotating the encryption keys, the script will re-encrypt the existing secrets in your Galasa Ecosystem using the newly activated encryption key. + +Once the encryption keys have been rotated and the existing secrets have been re-encrypted, the script will clear the fallback decryption keys list and restart the API and engine controller pods for a final time to keep the Galasa services in sync with the contents of the encryption keys secret. + +## Manual steps + +If the `rotate-encryption-keys.sh` script fails or if you are on Windows and cannot run the script, you can manually rotate encryption keys by performing the following steps. + +This guide assumes `kubectl` is configured to manage resources in the namespace that your Galasa Ecosystem is installed within, so the `--namespace` flag is not required when running `kubectl` commands. + +This guide also assumes that the `GALASA_BOOTSTRAP` environment variable is set, so the `--bootstrap` flag is not required when running `galasactl` commands. + +1. Get all the existing secrets from your Galasa Ecosystem by running: + ``` + galasactl secrets get --format yaml + ``` + Store these secrets in a `.yaml` or `.yml` file so that you can re-encrypt them after rotating the encryption keys. + +2. Find the name of the Kubernetes Secret containing your Galasa Ecosystem's encryption keys by running: + ``` + kubectl get secrets + ``` + The secret's name should be of the form `{release-name}-encryption-secret`, where `{release-name}` is the Helm release name provided when installing the Galasa Ecosystem Helm chart. + +3. Get the existing encryption keys data for your Galasa Ecosystem by running: + ``` + kubectl get secret {encryption-secret-name} --output jsonpath='{ .data.encryption-keys\.yaml }' | openssl base64 -d -A + ``` + where `{encryption-secret-name}` is the name of the Kubernetes secret retrieved in step 2. The output should look like the following: + ```yaml + encryptionKey: + fallbackDecryptionKeys: [] + ``` + Place the output into a file. + +4. Generate a new encryption key by running: + ``` + openssl rand -base64 32 + ``` + +5. In the file created at the end of step 3, move the existing `encryptionKey` value into the `fallbackDecryptionKeys` list and place the newly generated encryption key into the `encryptionKey` field. The file should now look like this: + ```yaml + encryptionKey: + fallbackDecryptionKeys: + - + ``` + where `` is the new encryption key generated in step 5 and `` is the old encryption key retrieved in step 3. + +6. Base64-encode the file contents by running the following command: + ``` + openssl base64 -in + ``` + where `` is an absolute or relative path to the file created in step 3. + + Record the base64-encoded output, making sure there are no spaces or line breaks in the recorded output. + +7. Update the existing Kubernetes Secret with the rotated keys by running: + ``` + kubectl patch secret {encryption-secret-name} --type='json' -p="[{'op': 'replace', 'path': '/data/encryption-keys.yaml', 'value': ''}]" + ``` + where `{encryption-secret-name}` is the name of the Kubernetes secret retrieved in step 2, and `` is the output recorded in step 6. + +8. Restart the Galasa Ecosystem's API server deployment by running: + ``` + kubectl rollout restart deployment {release-name}-api + kubectl rollout status deployment {release-name}-api + ``` + where `{release-name}` is the name of the Helm release provided when installing the Galasa Ecosystem Helm chart. + +9. Restart the Galasa Ecosystem's engine controller deployment by running: + ``` + kubectl rollout restart deployment {release-name}-engine-controller + kubectl rollout status deployment {release-name}-engine-controller + ``` + where `{release-name}` is the name of the Helm release provided when installing the Galasa Ecosystem Helm chart. + +10. Once both the API server and engine controller have been restarted successfully, you can re-encrypt your existing secrets using the YAML file you created in step 1, by running: + ``` + galasactl resources apply -f + ``` + where `` is an absolute or relative path to the YAML file created at the end of step 1. + +Your Galasa Ecosystem will now use the newly generated encryption key to encrypt and decrypt secrets until the next time it is rotated. + +To verify that your secrets can still be read correctly, you can run `galasactl secrets get --format yaml` again and compare the YAML output with the content of YAML file that you applied in step 10. If the output is the same, then the secrets have been re-encrypted successfully. diff --git a/src/markdown-pages/docs/ecosystem/ecosystem-update-creds.md b/src/markdown-pages/docs/ecosystem/ecosystem-update-creds.md deleted file mode 100644 index a185ca4d0..000000000 --- a/src/markdown-pages/docs/ecosystem/ecosystem-update-creds.md +++ /dev/null @@ -1,151 +0,0 @@ ---- -path: "/docs/ecosystem/ecosystem-update-creds" -title: "Updating credentials in an Ecosystem" ---- - -It is likely that a test will need to pass credentials to the application being tested. For example, as HTTP credentials or as username and password values entered onto a 3270 screen. In a Galasa Ecosystem the credentials store (CREDS), which is hosted in the etcd server, securely provides the credentials (for example, password, username, and personal access token) that are required for a test to run in automation. - -You can set a username, password, or token in the CREDS by using a Visual Studio Code (VS Code) Kubernetes extension or by using the command line. The ability to set these properties means that you can supply test cases with the credentials and tokens that they need to run. To set these credentials you must have permission to access the CREDS pod on a Galasa Ecosystem. You can then use the etcdctl tool to manipulate the etcd server values in a [namespace](../ecosystem/ecosystem-manage-cps). - -The following examples show how you can update the CREDS. In these examples, the CREDS pod is called `creds` and the namespace is `galasa-ecosystem`. - - -## Logging into the CREDS pod by using the VSCode Kubernetes extension - -Complete the following steps to log into the CREDS pod using the VS Code Kubernetes extension. - -1. In the VSCode Kubernetes extension, confirm that the tool is pointing at the Kubernetes cluster that hosts your Galasa Ecosystem. If it is not, you can select the cluster by navigating to `Clusters`, right-clicking the cluster you need, and selecting `Set as Current Cluster`. -2. Set your namespace to `galasa-ecosystem` by navigating to `Namespaces`, right-clicking the namespace and selecting `Use Namespace`. -3. Go to your Pods by navigating to `Workloads`>`Pods`. -4. Exec on to the `creds` pod by right-clicking the pod and selecting `Terminal`, or by selecting the `Terminal` icon. A shell of the `creds` pod opens in VSCode. - - -## Logging into the CREDS pod by using the command line - -1. Open a terminal and on the command line, exec into your `creds` pod: -``` -kubectl exec -it creds -n galasa-ecosystem -- /bin/sh -``` - - -## Configuring credentials in the CREDS pod - -Once you are shelled into your `creds` pod you can configure credentials by using the `etcdctl` command line tool to interact with the etcd server. - -First, set the `etcd` version by running the following command: -``` -export ETCDCTL_API=3 -``` - -You can then use the following `etcdctl` commands in your CREDS pod to help you to configure your credentials. - - -### Retrieve all credentials - -To retrieve all credentials, run the following command: -``` -etcdctl get --prefix "" -``` - -### Retrieve all credentials with a specified prefix - -To retrieve all credentials with a specified prefix, use the following example command: -``` -etcdctl get --prefix "{myprefix}" -``` -where `{myprefix}` is the value that you want the returned credentials to start with. - -For example, to view all credentials that start with `secure.credentials.SIMBANK`, run the following command: -``` -etcdctl get --prefix "secure.credentials.SIMBANK" -``` -The following example shows the returned credentials: -``` -/ # etcdctl get --prefix "secure.credentials.SIMBANK" -secure.credentials.SIMBANK.password -SYS1 -secure.credentials.SIMBANK.username -IBMUSER -``` - -### Retrieve a specific credential - -To retrieve a specific credential, use the following example command: -``` -etcdctl get {key} -``` -where `{key}` is the name of the credential that you want returned - -For example, to retrieve the credential `secure.credentials.SIMBANK.username`, run the following command: - -``` -etcdctl get --prefix "secure.credentials.SIMBANK.username" -``` - -The following example shows the returned credential: - -``` -/ # etcdctl get secure.credentials.SIMBANK.username -secure.credentials.SIMBANK.username -IBMUSER -``` - -### Create or update a credential - -To retrieve a specific credential, use the following example command: - -``` -etcdctl put {key} {value} -``` - -where:
-`{key}` is the name of the credential that you want to update and
-`{value}` is the value that you want to give to that credential - -For example, to update the credential `secure.credentials.SIMBANK.username` with a value of `NEWUSER`, run the following command: - -``` -etcdctl put secure.credentials.SIMBANK.username NEWUSER -``` - -The following example shows a successful response: -``` -/ # etcdctl put secure.credentials.SIMBANK.username NEWUSER -OK -``` - - -### Delete a credential - -To delete a specific credential, use the following example command: - -``` -etcdctl del {key} -``` - -where: -`{key}` is the name of the credential that you want to delete - - -For example, to delete the credential `secure.credentials.SIMBANK.username`, run the following command: - -``` -etcdctl del secure.credentials.SIMBANK.username -``` - -The following example shows a successful response: -``` -/ # etcdctl del secure.credentials.SIMBANK.username -1 -``` - -If the credential does not exist, a value of `0` rather than `1` is returned in the response. - -### Exit the shell - -To exit the shell, simply run: -``` -exit -``` - -Updated credentials are now available for a test to run in automation on a Galasa Ecosystem. \ No newline at end of file diff --git a/src/markdown-pages/docs/first-steps/installing-offline.md b/src/markdown-pages/docs/first-steps/installing-offline.md index 4e9fa5e3c..9f8c914fa 100644 --- a/src/markdown-pages/docs/first-steps/installing-offline.md +++ b/src/markdown-pages/docs/first-steps/installing-offline.md @@ -31,11 +31,11 @@ Note: The example uses port `8080` but you can use a different port. docker load -i isolated.tar ``` -The following confirmation message is received: _Loaded image: icr.io/galasadev/galasa-distribution:main_. +The following confirmation message is received: _Loaded image: ghcr.io/galasa-dev/galasa-isolated:main_. 2. Run the container by using the following command: ``` -docker run -d -p 8080:80 --name galasa icr.io/galasadev/galasa-distribution:main +docker run -d -p 8080:80 --name galasa ghcr.io/galasa-dev/galasa-isolated:main ``` 3. Go to `http:\\localhost:8080` to view the running container. diff --git a/src/markdown-pages/docs/managers/galasa-ecosystem-manager.md b/src/markdown-pages/docs/managers/galasa-ecosystem-manager.md index 4c7c9611c..5a3b03ecb 100644 --- a/src/markdown-pages/docs/managers/galasa-ecosystem-manager.md +++ b/src/markdown-pages/docs/managers/galasa-ecosystem-manager.md @@ -3,7 +3,7 @@ path: "/docs/managers/galasa-ecosystem-manager" title: "Galasa Ecosystem Manager" --- -This Manager is at Alpha level. You can view the Javadoc documentation for the Manager here.
+This Manager is at Alpha level. You can view the Javadoc documentation for the Manager here.
@@ -154,7 +154,7 @@ The following are properties used to configure the Galasa Ecosystem Manager. | Required: | No | | Default value: | None | | Valid values: | Valid URL | -| Examples: | galasaecosystem.isolated.mvp.zip=https://github.com/galasa-dev/isolated/releases/download/v0.37.0/galasa-isolated-mvp-0.37.0.zip | +| Examples: | galasaecosystem.isolated.mvp.zip=https://github.com/galasa-dev/isolated/releases/download/v0.38.0/galasa-isolated-mvp-0.38.0.zip | diff --git a/src/markdown-pages/docs/managers/galasa_ecosystem-manager.md b/src/markdown-pages/docs/managers/galasa_ecosystem-manager.md index fb11e0c99..f277ed69d 100644 --- a/src/markdown-pages/docs/managers/galasa_ecosystem-manager.md +++ b/src/markdown-pages/docs/managers/galasa_ecosystem-manager.md @@ -3,7 +3,7 @@ path: "/docs/managers/galasa_ecosystem-manager" title: "Galasa Ecosystem Manager" --- -This Manager is at Alpha level. You can view the Javadoc documentation for the Manager here.
+This Manager is at Alpha level. You can view the Javadoc documentation for the Manager here.
diff --git a/src/markdown-pages/docs/managers/github-manager.md b/src/markdown-pages/docs/managers/github-manager.md index cf2de665f..2eaefbebc 100644 --- a/src/markdown-pages/docs/managers/github-manager.md +++ b/src/markdown-pages/docs/managers/github-manager.md @@ -4,7 +4,7 @@ title: "GitHub Manager" --- -This Manager is at Release level. You can view the Javadoc documentation for the Manager here.
+This Manager is at Release level. You can view the Javadoc documentation for the Manager here.
[Overview](#overview)
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 5805ddf91..6b3d311a2 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.25.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.38.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.25.0/obr \ +--obr mvn:dev.galasa/dev.galasa.simbank.obr/0.38.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.25.0/obr ` +--obr mvn:dev.galasa/dev.galasa.simbank.obr/0.38.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.25.0/obr \ +--obr mvn:dev.galasa/dev.galasa.simbank.obr/0.38.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.25.0/obr ` +--obr mvn:dev.galasa/dev.galasa.simbank.obr/0.38.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 28699b86f..ba24186c2 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.25.0` and Galasa uber OBR version `0.37.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.38.0` and Galasa uber OBR version `0.38.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.25.0/obr \ +--obr mvn:dev.galasa/dev.galasa.simbank.obr/0.38.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.25.0/obr ` +--obr mvn:dev.galasa/dev.galasa.simbank.obr/0.38.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.25.0/obr \ +--obr mvn:dev.galasa/dev.galasa.simbank.obr/0.38.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.25.0/obr ` +--obr mvn:dev.galasa/dev.galasa.simbank.obr/0.38.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 24cd93954..55b01bc40 100644 --- a/src/markdown-pages/highlights.md +++ b/src/markdown-pages/highlights.md @@ -18,11 +18,31 @@ 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.37.0 - Release Highlights +## 0.38.0 - Release Highlights + +- CLI updates: + + - You can get, set and delete secrets from the credentials store using the `galasactl secrets` command. Secrets support base64 encoding to handle special characters. + + - [Managing Ecosystem encryption keys](./docs/ecosystem/ecosystem-managing-encryption-keys.md) describes how to use `galasactl secrets get` and `galasactl resources apply` to replace the encryption key being used to encrypt credentials in the Galasa Ecosystem's credentials store. + + - Users can now be deleted with the `galasactl users delete` command. + +- Web UI updates: + + - A new settings page has been added to the web UI to manage access tokens. + + - Recent login activity is now available on the profile page. + +- This release also includes bug fixes, security updates, and other dependency updates. + +
+0.37.0 - Release Highlights - Galasa now supports Java 17. - You can delete a test run by using the `galasactl runs delete` command. Deleting a test run removes all information about the test run along with any associated artifacts from an ecosystem's RAS. +
diff --git a/src/pages/index.js b/src/pages/index.js index 9986ea416..815be073a 100644 --- a/src/pages/index.js +++ b/src/pages/index.js @@ -126,7 +126,7 @@ const IndexPage = () => ( Learn more