parasoft/ctp-helm repository overview

⁠Quick reference

Maintained by: Parasoft⁠

Where to get help: Parasoft Documentation⁠, Parasoft Forums⁠, or Parasoft Support and Technical Services⁠

⁠What is Parasoft Continuous Testing Platform?

Parasoft Continuous Testing Platform provides a centralized server with web interface for all environment management, API testing and service virtualization activities. Multiple Parasoft SOAtest & Virtualize servers can register with a single Continuous Testing Platform to coordinate test environments across multiple teams.

⁠Prerequisites

1. Helm version 3+ installed

2. Namespace for CTP to run in. For example:

   kubectl create namespace parasoft-ctp-namespace
   

   Copy

   Note: The namespace name "parasoft-ctp-namespace" is used throughout this documentation in command and resource examples. If you use a different name for your namespace, be sure to change any instances of "parasoft-ctp-namespace" in those examples to your namespace name.

   Warning: Once CTP has been licensed, deleting the namespace will invalidate machine-locked licenses, even if you recreate the same namespace.

3. (Optional) Persistent Volumes and Persistent Volume Claims

   Note: Whether or not you need any volumes (and which you would need) depends on how you intend to use CTP. Read the rest of this documentation to determine your specific needs.

   Warning: Any volumes used must have permissions for the Parasoft user to be able to read and write to the volume. For example, execute the command chown 1000:0 <shared_path>.

⁠How to use this Helm Chart

⁠Download the Parasoft Continuous Testing Platform Helm Chart

Download the Parasoft Continuous Testing Platform chart archive and (optionally) unpack it in a local directory with command:

$ helm pull oci://registry-1.docker.io/parasoft/ctp-helm --version TAG --untar

• --version TAG - Tag for the version of the Helm Chart to download
• --untar - Optional flag that unpacks the chart archive (.tgz) in a local directory called soavirt-server-helm

⁠Setting up persistent volumes, if needed

Persistent volumes can be used to store database configuration information, exported test data repositories, persist the builtin HyperSQL database, or mount JDBC drivers for MySQL, MariaDB, or Oracle databases. All, some, or no volumes can be customized and created according to user needs.

The following volumes are enabled by default:

1. ctp-config-storage: This volume can be used to persist database configuration information. See below for how to configure a database either through the values.yaml file of the unpacked chart archive or the command line as alternatives. The settings for the persistent volume and persistent volume claim relating to database configuration storage can be found in the values.yaml file of the unpacked chart under persistence.configStorage. By default it is of type hostPath, although it can easily be configured to use nfs by changing this type and specifying a nfs server. The relevant template can be found in the unpacked chart archive in the template ctp-pv.yaml.

   If using this volume, it must contain a valid db_config.xml file. See the db_config.xml below for an example of one that is well-formatted. You can copy the example below into the volume you are mounting if you prefer; whatever configuration you need to do will be done within the application itself. Note that if the URL JDBC string is for MariaDB, MySQL, or Oracle, then your CTP deployment/pod should be configured with the correct JDBC adapter; if the URL JDBC string is for HyperSQL, it should start up regardless of your CTP deployment/pod configuration.

   <?xml version="1.0" encoding="UTF-8"?>
   <configuration>
       <db_config>
           <connection>
               <url>jdbc:hsqldb:file:/usr/local/parasoft/ctp/hsqldb/em;ifexists=true</url>
               <username>em</username>
               <password>em</password>
           </connection>
       </db_config>
   </configuration>
   

   Copy

2. ctp-exports-storage: This volume can be used to persist exported test data repositories. The settings for the persistent volume and persistent volume claim relating to exports can be found in the values.yaml file of the unpacked chart under persistence.exportStorage. By default it is of type hostPath, although it can easily be configured to use nfs by changing this type and specifying a nfs server. The relevant template can be found in the unpacked chart archive in the template ctp-pv.yaml.

3. ctp-hsqldb-storage: This volume can be used to persist the built-in HyperSQL database. The settings for the persistent volume and persistent volume claim relating to the HyperSQL database can be found in the values.yaml file of the unpacked chart under persistence.hsqldb. By default it is of type hostPath, although it can easily be configured to use nfs by changing this type and specifying a nfs server. The relevant template can be found in the unpacked chart archive in the template ctp-hsqldb.yaml.

The following volumes correspond to mounts for database JDBC drivers to connect to MariaDB, MySQL, or Oracle databases. They are disabled by default. If one if used, it should contain an appropriate JDBC driver for that database type; be sure to update the relevant value (found under pod.jdbcAdapterJars) to the name of the JDBC driver file in the values.yaml file of the unpackated chart or provide it on the command line when using helm install. Note that an alternative to mounting a volume for a JDBC driver is to provide a URL to download it from upon container startup. See below for more information.

1. ctp-mariadbadapter-storage: This volume can be used to a JDBC driver to connect to a MariaDB database. The settings for the persistent volume and persistent volume claim can be found in the values.yaml file of the unpacked chart under persistence.jdbcAdapters.mariaDB. By default it is of type hostPath, although it can easily be configured to use nfs by changing this type and specifying a nfs server. The relevant template can be found in the unpacked chart archive in the template ctp-mariadb.yaml.

2. ctp-mysqladapter-storage: This volume can be used to a JDBC driver to connect to a MySQL database. The settings for the persistent volume and persistent volume claim can be found in the values.yaml file of the unpacked chart under persistence.jdbcAdapters.mysql. By default it is of type hostPath, although it can easily be configured to use nfs by changing this type and specifying a nfs server. The relevant template can be found in the unpacked chart archive in the template ctp-mysql.yaml.

3. ctp-oracleadapter-storage: This volume can be used to a JDBC driver to connect to a dan Oracle database. The settings for the persistent volume and persistent volume claim can be found in the values.yaml file of the unpacked chart under persistence.jdbcAdapters.oracle. By default it is of type hostPath, although it can easily be configured to use nfs by changing this type and specifying a nfs server. The relevant template can be found in the unpacked chart archive in the template ctp-oracle.yaml.

⁠Database and JDBC Driver Configuration

You can change the values of the Helm chart to specify a database configuration they want to start with, in addition to or as an alternative to mounting a database configuration volume as described above. The following values are used for this (set either via editing the values.yaml of an unpacked chart archive or using --set when running helm install):

1. pod.env.db.configureDB: This must be set to true to enable database configuration using Helm; false by default.
2. pod.env.db.type: The type of database to configure. Valid options are HyperSQL, MariaDB, MySQL, and Oracle. The default is MariaDB.
3. pod.env.db.user: The username to use with the database. The default is em.
4. pod.env.db.password: The (optional) password to use with the database. The default is the empty string (no password).

The following settings apply specifically when the type is set to MariaDB, MySQL, or Oracle:

1. pod.env.db.remote.host: The host for the database. The default is localhost.
2. pod.env.db.remote.port: The port for the database. The default is 3306.

The following setting applies specifically when the type is set to either MariaDB or MySQL:

1. pod.env.db.mysql.schema: The schema for the database. The default is em.

The following settings apply specifically when the type is set to Oracle:

1. pod.env.db.oracle.sid: The SID for the database. The default is XE
2. pod.env.db.oracle.serviceName: The Service Name for the database. Note that if the SID is defined as well, the value for SID is used and the value for serviceName is ignored. The default is XE.

The following setting applies specifically when the type is3 set to HyperSQL:

1. pod.env.db.hsqldb.filepath: The file path for the database. The default is /HyperSQL/em

You can provide a URL as a value for the Helm chart to download a JDBC driver for a database from as an alternative to mounting a volume to provide the driver as described above. To do this, the following value should be provided (set either via editing the values.yaml of an unpacked chart archive or using --set when running helm install):

1. pod.env.db.jdbcDriverUrl: The url for the JDBC driver jar. The default is the empty string (none provided).

⁠Licensing

You need to read and accept the EULA to use CTP. To accept the EULA, either change the value pod.env.acceptEula to true in the values.yaml of the unpacked chart archive or do so on the command line using --set when running helm install.

Other values can be changed if necessary. For example, if you are using a network license, update these values as needed:

1. pod.env.licenseServerUrl: Configures CTP to connect to license server at the specified base URL
2. pod.env.licenseServerAuthEnabled: Configures CTP to use basic authentication when connecting to license server
3. pod.env.licenseServerUsername: Configures CTP to connect to license server as the specified user
4. pod.env.licenseServerPassword: Configures CTP to connect to license server with the specified password

In the case of pod.env.licenseServerPassword, consider modifying the value in values.yaml as well as its usage in the template ctp-pod.yaml to be more secure by using a secret.

⁠Install Parasoft Continuous Testing Platform

To install CTP with either the default values (in the case of a packaged chart archive) or customized values in values.yaml (in the case of an unpacked chart archive), use the command:

$ helm install RELEASE_NAME [ PACKAGED_CHART_PATH | UNPACKAGED_CHART_PATH ] --namespace NAMESPACE --create-namespace

• RELEASE_NAME - Name for the new release being installed
• PACKAGED_CHART_PATH - Path of the downloaded chart archive
• UNPACKAGED_CHART_PATH - Path of the ctp-helm local directory unpacked from the downloaded chart archive
• --namespace NAMESPACE - Namespace for the new release being installed
• --create-namespace - Creates the namespace for the new release being installed if it does not exist already

To install Continuous Testing Platform while customizing values on the command line, use the command:

$ helm install RELEASE_NAME [ PACKAGED_CHART_PATH | UNPACKAGED_CHART_PATH ] --set ARGUMENTS --namespace NAMESPACE --create-namespace

• RELEASE_NAME - Name for the new release being installed
• PACKAGED_CHART_PATH - Path of the downloaded chart archive
• UNPACKAGED_CHART_PATH - Path of the ctp-helm local directory unpacked from the downloaded chart archive
• --set ARGUMENTS - Apply a comma-separated list of arguments of the form key1=value1,key2=value2 to modify the Helm chart's values; i.e. --set pod.env.acceptEula=true,pod.env.licenseServerUrl=http://localhost:8081⁠
• --namespace NAMESPACE - Namespace for the new release being installed
• --create-namespace - Creates the namespace for the new release being installed if it does not exist already

⁠Uninstall Parasoft Continuous Testing Platform

Uninstall CTP with command:

$ helm uninstall RELEASE_NAME

• RELEASE_NAME - Name for the release being uninstalled