[pull] next from main

src/markdown-pages/docs/cli-command-reference/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 <a href="https://github.com/galasa-dev/simplatform" target="_blank"> Galasa simplatform repository</a> 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 `Launching SimBank` section in the [Exploring Galasa SimBank online](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.34.1`.
+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.35.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.
 

src/markdown-pages/docs/ecosystem/ecosystem-installing-k8s.md

@@ -53,8 +53,8 @@ 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.<br>
-    _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  <a href=https://github.com/galasa-dev/helm/blob/ecosystem-0.34.1/charts/ecosystem/values.yaml target="_blank"> values.yaml</a> 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 <a href=https://github.com/galasa-dev/helm/blob/ecosystem-0.34.1/charts/ecosystem/values.yaml target="_blank"> values.yaml</a> 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  <a href=https://github.com/galasa-dev/helm/blob/ecosystem-0.35.0/charts/ecosystem/values.yaml target="_blank"> values.yaml</a> 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 <a href=https://github.com/galasa-dev/helm/blob/ecosystem-0.35.0/charts/ecosystem/values.yaml target="_blank"> values.yaml</a> file 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`.
 
@@ -225,22 +225,22 @@ You can then deploy your Galasa tests to a Maven repository and set up a test st
 ## 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.34.1 - 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.35.0 - by running the following command:
 
 On Mac or Unix:
 
 ```console
 helm repo update \
 helm upgrade <release-name> galasa/ecosystem --reuse-values \
---set galasaVersion=0.34.1 --wait
+--set galasaVersion=0.35.0 --wait
 ```
 
 On Windows (Powershell):
 
 ```console
 helm repo update `
 helm upgrade <release-name> galasa/ecosystem --reuse-values `
---set galasaVersion=0.34.1 --wait
+--set galasaVersion=0.35.0 --wait
 ```
 
 where:<br>

src/markdown-pages/docs/managers/core-manager.md

@@ -58,10 +58,10 @@ The following are properties used to configure the Core Manager:
 | Property: | Resource String Pattern CPS Property |
 | --------------------------------------- | :------------------------------------- |
 | Name: | core.resource.string.[length].pattern |
-| Description: | Defines the pattern of characters within a string of a specified length.  The patterns are from the Galasa ResourcePoolingService which uses a custom syntax.   |
+| Description: | The Resource String Pattern CPS property allows Galasa to form a string based upon a certain standard or pattern, for example, must begin with the letter `A`, must end with a numeral. The patterns are formed from the Galasa `ResourcePoolingService` which uses a custom syntax. This property is used when the Core Manager provisions a `@ResourceString` into a test.  This string can used for anything within the test class, for example, to create new z/OS PDS names, or a piece of data that the test will use. The string must be unique to that test across all the other tests within the Ecosystem.  |
 | Required:  | No |
 | Default value: | {A-Z} for each byte for the specified length |
-| Valid values: | For each character the value can be a constant or a random choice from a literal, eg {A-Z results in a single character between A and Z inclusive. {0-9} or {a-zA-Z0-9} are options. DFH{A-Z}{0-1}{0-9}{0-9}{0-9}, results in DFHA1789 for example, the 5th character can only be 0 or 1. 
+| Valid values: | For each character the value can be a constant or a random choice from a literal, eg {A-Z} results in a single character between A and Z inclusive. {0-9} or {a-zA-Z0-9} are options. DFH{A-Z}{0-1}{0-9}{0-9}{0-9}, results in DFHA1789 for example, the 5th character can only be 0 or 1. 
 | Examples: | <code>core.resource.string.8.length={A-Z}{A-Z}{A-Z}{A-Z}{A-Z}{A-Z}{A-Z}{A-Z}<br> </code> |
 
 </details>

src/markdown-pages/docs/managers/galasa-ecosystem-manager.md

@@ -48,7 +48,7 @@ The following annotations are available with the Galasa Ecosystem Manager
 | Attribute: `windowsImageTag` |  The <code>windowsImageTag</code> identifies which tagged Windows image is to be used to deploy the Galasa Ecosystem into. |
 | Attribute: `javaInstallationTag` |  The <code>javaInstallationTag</code> to which Java installation on the image is to be used to run the Galasa tests and services. |
 | Attribute: `isolationInstallation` |  |
-| Syntax: | <code>@LocaEcosystem(linuxImageTag="PRIMARY")<br> public ILocalEcosystem ecosystem;<br> <br> @LocalEcosystem(windowsImageTag="PRIMARY")<br> public ILocalEcosystem ecosystem;<br> </code> |
+| Syntax: | <code>@LocalEcosystem(linuxImageTag="PRIMARY")<br> public ILocalEcosystem ecosystem;<br> <br> @LocalEcosystem(windowsImageTag="PRIMARY")<br> public ILocalEcosystem ecosystem;<br> </code> |
 | Notes: | The <code>ILocalEcosystem</code> interface gives the test access FPF services and the ability to run tests from the commandline. The Manager will pre-configure the CPS, DSS and CREDS before the test begins.<br> <br> The test must provide a @LocalNamespace ILocalNamespace annotation, as this is where the Ecosystem is provisioned in. <br> The annotation must provide either a Windows or Linux image tag, but not both and must provide a @JavaInstallation tag. |
 
 </details>

src/markdown-pages/docs/writing-own-tests/running-test-modes.md

@@ -20,13 +20,18 @@ There are three modes in which you can run a Galasa test:<br><br>
 -  remotely, by submitting the test to run in the Galasa Ecosystem<br> 
 
 
+If you are running a test locally but using a shared configuration that is hosted by the Galasa Ecosystem, or running a test remotely by submitting the test to run in the Galasa Ecosystem, you are interacting with the Galasa Ecosystem. 
+
+Before you can interact with the Galasa Ecosystem, you must authenticate with it by using a personal access token. Tokens are stored in the `GALASA_TOKEN` in the `galasactl.properties` in your Galasa home folder. You can request a personal access token by using the Galasa Web UI. For more information about setting up authentication with an Ecosystem, see the [Configuring authentication](../ecosystem/ecosystem-authentication) documentation.
+
+
 The mode in which you choose to run a test depends on what you are trying to achieve. Use the following information to understand which mode is most appropriate for a given scenario. 
 
 
 ## <a name="locally"></a>Running a test locally
 
 
-When you run a test locally, without using shared configuration, everything runs on your local machine. The Galasa bootstrap file is blank and makes no reference to an ecosystem. The Galasa framework is launched within the JVM on the local machine and the local file system holds all the configuration that is used by the test. The test runs in the local JVM and all test results and artifacts are stored on the local disk. 
+When you run a test locally, without using shared configuration, everything runs on your local machine. The Galasa bootstrap file is blank and makes no reference to an Ecosystem. The Galasa framework is launched within the JVM on the local machine and the local file system holds all the configuration that is used by the test. The test runs in the local JVM and all test results and artifacts are stored on the local disk. 
 
 ![running in local mode:](running-local.svg)
 
@@ -35,21 +40,35 @@ You can run a test in this mode by using the `runs submit local` <a href="https:
 
 ## <a name="remotely"></a>Running a test in the Galasa Ecosystem
 
-To submit your test to an Ecosystem for remote execution, the Galasa bootstrap is set to the URL of the Galasa Ecosystem in which you want to run your test. The configuration of the test is also held within that ecosystem, and Galasa starts up in a container in which the test code will run. The test results and artifacts are stored in a database within the specified ecosystem, and users on client machines can view the test results. 
+To submit your test to an Ecosystem for remote execution, the Galasa bootstrap is set to the URL of the Galasa Ecosystem in which you want to run your test. The configuration of the test is also held within that Ecosystem, and Galasa starts up in a container in which the test code will run. The test results and artifacts are stored in a database within the specified Ecosystem, and users on client machines can view the test results. 
 
 
 ![running remotely:](run-remote.svg)
 
-You can run a test in this mode by setting up your bootstrap file to refer to the ecosystem that you want to use and running the `runs submit` <a href="https://github.com/galasa-dev/cli/blob/main/docs/generated/galasactl_runs_submit.md" target="_blank"> Galasa CLI</a> command.
+After configuring authentication, you can run a test in this mode by setting up your bootstrap file to refer to the Ecosystem that you want to use and running the `runs submit` <a href="https://github.com/galasa-dev/cli/blob/main/docs/generated/galasactl_runs_submit.md" target="_blank"> Galasa CLI</a> command.
 
 ## <a name="hybrid"></a>Running a test locally but using shared configuration
 
-When you run a test locally, but using shared configuration, the Galasa bootstrap is set to the URL of the Galasa Ecosystem where the shared configuration is stored. The Galasa framework is launched within the JVM on the local machine, but the framework consults the remote ecosystem to read configuration data, but not the credentials properties as these are drawn from a local file. This is the key difference between running a test in this "hybrid" mode versus running a test locally without using shared configuration. In hybrid mode, the test still runs in the local JVM and all test results and artifacts are stored on the local disk. 
+When you run a test locally, but using shared configuration, you need to run the `galasactl auth login` command to access the remote system using the Galasa bootstrap. You can then unset the bootstrap so that your local `bootstrap.properties` file is used, or alternatively you can refer explicitly to the local bootstrap file. For more information about the `galasactl auth login` command, see the [Configuring authentication](../ecosystem/ecosystem-authentication) documentation.
+
+
+The Galasa framework is launched within the JVM on the local machine, but the framework consults the remote Ecosystem to read configuration data, but not the credentials properties as these are drawn from a local file. This is the key difference between running a test in this "hybrid" mode versus running a test locally without using shared configuration. In hybrid mode, the test still runs in the local JVM and all test results and artifacts are stored on the local disk. 
 
 
 ![running in local mode with shared configuration:](hybridrunmode.svg)
 
-You can run a test in this mode by setting up your bootstrap to refer to the ecosystem in which the shared configuration is stored, and using the `runs submit local` <a href="https://github.com/galasa-dev/cli/blob/main/docs/generated/galasactl_runs_submit_local.md" target="_blank"> Galasa CLI</a> command. 
+To run tests in hybrid mode, add the following properties into your local `bootstrap.properties` file:
+
+```
+framework.config.store=galasacps://my.ecosystem.url/api
+framework.extra.bundles=dev.galasa.cps.rest
+```
+
+where: <br>
+- `https://my.ecosystem.url` refers to the Web UI used to allocate tokens and <br>
+- `framework.extra.bundles` tells the Galasa framework to load the `dev.galasa.cps.rest` extension. This extension tells the Galasa framework how to handle URLs that start with `galasacps` as the *scheme* part of the URL. <br>
+
+After setting the `GALASA_TOKEN` to be a valid token for the Ecosystem from which the CPS property values will be drawn, log into the Ecosystem by running the `galasactl auth login` command. You can then run a test in hybrid mode by setting your bootstrap to refer to the Ecosystem in which the shared configuration is stored, and using the `galasactl runs submit local` <a href="https://github.com/galasa-dev/cli/blob/main/docs/generated/galasactl_runs_submit_local.md" target="_blank"> Galasa CLI</a> command. 
 
 ### <a name="whenremote"></a>When to run a test in the Galasa Ecosystem
 
@@ -60,7 +79,7 @@ Running a test remotely is useful in the following scenarios:
 
 If you are able to dynamically provision a system, then running tests from a local JVM can work well, as the system under test might have few resource contraints and can be used exclusively by the tests before being de-provisioned. However, if you want to run many test in parallet, you cannot do so reliably from a single system using the local JVM method on one user account. Any contention to name test runs uniquely, or other stateful changes in the test framework might cause the tests to clash, over-write each other, fail, or produce unexpected results. Running multiple tests in series can avoid some of these issues but running large numbers of tests in this way can take a long time. 
 
-To reliably run many tests in parallel, deploy your tests to the Galasa Ecosystem, letting the ecosystem manage the test runs, and the Galasa Manager components manage any shared or constrained resources. 
+To reliably run many tests in parallel, deploy your tests to the Galasa Ecosystem, letting the Ecosystem manage the test runs, and the Galasa Manager components manage any shared or constrained resources. 
 
 - <b>Test results and reports need gathering from a single point. For example, when test results need reporting or exporting to another report-generating system, or when bug investigation can proceed by independent inspection test results and artifacts.</b>
 

src/markdown-pages/highlights.md

@@ -17,8 +17,13 @@ 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.35.0 - Release Highlights
 
-## 0.34.1 - Release Highlights
+- A fix to the database connector of the DB2 Manager
+
+
+<details>
+<summary><b>0.34.1 - Release Highlights</b></summary>
 
 - Retrieve a list of all active personal access tokens in the Ecosystem by using the `galasactl auth tokens get` command. Use the information to revoke or delete an access token.
 
@@ -29,6 +34,7 @@ Access the Galasa source code in [GitHub](https://github.com/galasa-dev) and ope
 - Various bug fixes
 
 - Various documentation updates
+</details> 
 
 
 <details>

src/pages/index.js

@@ -126,7 +126,7 @@ const IndexPage = () => (
             Learn more
           </Button>
           <Button target={"/releases"} flash={true} isPrimary={true}>
-            0.34.1 highlights
+            0.35.0 highlights
           </Button>
         </div>
       </div>