Publish stubs by using the command line
You can publish a stub to HCL Quality Server, Dockerfile and build context, or Kubernetes by using the HCL OneTest™ API command line.
IntegrationTesterCmd Options publish-stubs
HCL Quality Server
IntegrationTesterCmd --serverUrl "https://Host name or IP address:5443/RTCP/"
--domain <Domain name> --environment <Environment name>
--project <Path to project file> publish-stubs
Starting from version 10.0.0, you can publish a managed stub with a default configuration to HCL Quality Server and the stub is not started automatically after publishing. For more information about managed or server-based stubs, refer to the related links.
- Publishing the first instance of a stub. A new managed stub instance is created in the selected environment and domain, with a default configuration and is in the STOPPED state.
- Publishing to update the version of an existing stub. All existing instance of that stub type are updated but their configuration settings are not changed.
The following table lists the options that you can
use with the IntegrationTesterCmd
command to publish
stubs to HCL Quality Server.
Options | Description | Required |
---|---|---|
--optionsFile |
The path to an XML file that contains the command options. Any options that are explicitly specified override those options set in this file. For details of the format of this file, refer to the related links. |
No |
--serverUrl/-u |
URL of the HCL Quality Server. |
Yes |
--domain/-d |
Domain name. |
Yes |
--environment/-e |
Environment name. |
Yes |
--project/-p | The full path to a project file. | Yes |
--stubFilter |
The filter that is used to select which stubs are published. A filter is defined by XML type tags that describe the hierarchy of the stubs to publish as it appears in the project within HCL OneTest™ API. Each filter declares the component names, an operation name, and the folder names that belong to the stubs to publish. If not specified, the filter defaults to publishing all stubs. For more information about selecting stubs by using a stub filter, refer to the related links. |
No, default is to publish to all stubs in the project. |
--majorVersion | The major version at which to publish the stubs (optional). The default is to use the latest version on the server for that project, domain, environment combination. For more information about specifying stub versions, see the related links. | No, default is to use the latest version on the server for that project, domain, and environment combination. |
--minorVersion | The minor version at which to publish the stubs (optional). The default is to use the latest version on the server for that project, domain, environment combination. For more information about specifying stub versions, see the related links. | No, default is to use the latest version on the server for that project, domain, environment combination. |
--updateMode | The updateMode option can be specified to further control
which stubs are published. |
No, default is publish all stubs, old and new. |
--securityToken | The value of the security token to use for authentication with HCL Quality Server when domain security is enabled (optional). For more information, refer to the related links. | No, default is to send no token. |
Publishing stubs to Dockerfile and build context by using the command line
Before you build the Docker image for a stub that has been published to a Dockerfile and build context, you must set up to use Docker.
IntegrationTesterCmd --destination docker --outputDirectory <Path to output directory>
--dockerfileTemplate ubuntu --environment <Name of environment>
--project <Path to project file> --stubFilter <Filter value> publish-stubs
The following table lists the options that you can use with the
IntegrationTesterCmd
command to publish stubs to a Dockerfile and build context
output directory.
Options | Description | Required |
---|---|---|
--optionsFile |
The path to an XML file that contains the command options. Any options that are explicitly specified override those options set in this file. For details of the format of this file, refer to the related links. |
No |
--destination | The destination to publish stubs. The value can be docker or
rtcp . The default is rtcp and is used if the destination option is
not specified. docker must be specified to publish to a Dockerfile and build
context. |
Yes |
--outputDirectory | The path to the directory where the Dockerfile and other context files are output. | Yes |
--dockerfileTemplate | A template Dockerfile that is used to generate a Dockerfile. HCL OneTest™ API provides the ubuntu template for you to use. | Yes |
--dockerfileComment | Optional text in quotation marks that is added as a comment in the generated Dockerfile. | No |
--environment/-e |
Environment name. |
Yes |
--project/-p | The full path to a project file. | Yes |
--stubFilter |
The filter that is used to select which stubs are published. A filter is defined by XML type tags that describe the hierarchy of the stubs to publish as it appears in the project within HCL OneTest™ API. Each filter declares the component names, an operation name, and the folder names that belong to the stubs to publish. If not specified, the filter defaults to publishing all stubs. For more information about selecting stubs by using a stub filter, refer to the related links. |
No, default is to publish to all stubs in the project. |
IntegrationTesterCmd --destination docker --outputDirectory C:\myImages\stubA
--dockerfileTemplate ubuntu --environment Env1
--project C:\projects\P1\P1.ghp --stubFilter "<O>TestOperation</O>" publish-stubs
Build a Docker image by using the Dockerfile
The Dockerfile and context files in the output directory can be used to build a Docker image.
docker build -t <name> <dockerfile_location>
Where name is the name and optionally a tag in the 'name:tag' format for the image that you want to create.
Where dockerfile_location is the output directory that contains the Dockerfile and build context files.
The following example on Windows systems, builds a Docker image that is named stubimage from a Dockerfile and build context files that were published to C:\myImages\StubA
docker build -t stubimage C:\myImages\stubA
If the output directory is not accessible by the Docker client, for example it is on a different
computer, the directory must be copied to an accessible directory on the Docker client computer
before you run the Docker build
command with the
dockerfile_location updated.
When the Docker image is created, it can be run as a container. For information about running the container, refer to the related links.
For more information about building Docker images, refer to the related links.
Publishing stubs to Kubernetes by using the command line
IntegrationTesterCmd --destination k8s --outputDirectory <Path to output directory>
--k8sIdentifier <Name of identifier> --DockerRegistry <Name of Docker registry> --LicensingServer <URL of licensing server> --LicensingServerID <ID of licensing server>
--environment <Name of environment> --project <Path to project file> --stubFilter <Filter value> publish-stubs
The following table lists the options that you can use with the
IntegrationTesterCmd
command to publish stubs to the Kubernetes output
directory.
Options | Description | Required |
---|---|---|
--optionsFile |
The path to an XML file that contains the command options. Any options that are explicitly specified override those options set in this file. For details of the format of this file, refer to the related links. |
No |
--destination | The destination to publish stubs. k8s must be specified to
publish to Kubernetes. |
Yes |
--outputDirectory | The path to the directory where the YAML file, project files, and Library files are output. | Yes |
--k8sIdentifier |
An identifier string that is used to name and label resources within the Kubernetes container so you can identify the stubs that you are running. The identifier can be a maximum of 40 lowercase alphanumeric characters [a-z, 0-9]. You can use a hyphen (-) anywhere except as the first or last character. |
Yes |
--DockerRegistry |
The Docker registry and namespace in the format
|
Yes |
--LicensingServer |
The FlexNet server URL. By default, the server URL is taken from the HCL_ONETEST_LICENSING_URL environment variable. Use this option to override the value. This information is copied into the generated YAML file such that it is passed to the container. If you do not know the value of the licensing server, you must edit the YAML file and add the correct value before deployment. |
No |
--LicensingServerID |
The ID of the FlexNet server. By default, the server ID will be taken from the HCL_ONETEST_LICENSING_ID environment variable. This information is copied into the generated YAML file such that it is passed to the container. If you do not know the value of the licensing server, you must edit the YAML file and add the correct value before deployment. |
No |
--environment/-e |
Environment name. |
Yes |
--project/-p | The full path to a project file. | Yes |
--stubFilter |
The filter that is used to select which stubs are published. A filter is defined by XML type tags that describe the hierarchy of the stubs to publish as it appears in the project within HCL OneTest™ API. Each filter declares the component names, an operation name, and the folder names that belong to the stubs to publish. If not specified, the filter defaults to publishing all stubs. For more information about selecting stubs by using a stub filter, refer to the related links. |
No, default is to publish to all stubs in the project. |
You must copy the project files and the library files to a file server from where they can be downloaded by an intiContainer called fetch-project that is run before the stub container is started. You can then run the stubs in the Kubernetes cluster.
Publishing stubs to Istio by using the command line
IntegrationTesterCmd --destination istio --outputDirectory <Path to output directory>
--k8sIdentifier <Name of identifier> --DockerRegistry <Name of Docker registry> --LicensingServer <URL of licensing server> --LicensingServerID <ID of licensing server>
--environment <Name of environment> --project <Path to project file> --stubFilter <Filter value> publish-stubs
The following table lists the options that you can use with the
IntegrationTesterCmd
command to publish stubs to the Istio output directory.
Options | Description | Required |
---|---|---|
--optionsFile |
The path to an XML file that contains the command options. Any options that are explicitly specified override those options set in this file. For details of the format of this file, refer to the related links. |
No |
--destination | The destination to publish stubs. istio must be specified to
publish to Istio on Kubernetes. |
Yes |
--outputDirectory | The path to the directory where the YAML file, project files, and Library files are output. | Yes |
--k8sIdentifier |
An identifier string that is used to name and label resources within the Kubernetes container so you can identify the stubs that you are running. The identifier can be a maximum of 40 lowercase alphanumeric characters [a-z, 0-9]. You can use a hyphen (-) anywhere except as the first or last character. |
Yes |
--DockerRegistry |
The Docker registry and namespace in the format
|
Yes |
--LicensingServer |
The FlexNet server URL. By default, the server URL is taken from the HCL_ONETEST_LICENSING_URL environment variable. Use this option to override the value. This information is copied into the generated YAML file such that it is passed to the container. If you do not know the value of the licensing server, you must edit the YAML file and add the correct value before deployment. |
No |
--LicensingServerID |
The ID of the FlexNet server. By default, the server ID will be taken from the HCL_ONETEST_LICENSING_ID environment variable. This information is copied into the generated YAML file such that it is passed to the container. If you do not know the value of the licensing server, you must edit the YAML file and add the correct value before deployment. |
No |
--environment/-e |
Environment name. |
Yes |
--project/-p | The full path to a project file. | Yes |
--stubFilter |
The filter that is used to select which stubs are published. A filter is defined by XML type tags that describe the hierarchy of the stubs to publish as it appears in the project within HCL OneTest™ API. Each filter declares the component names, an operation name, and the folder names that belong to the stubs to publish. If not specified, the filter defaults to publishing all stubs. For more information about selecting stubs by using a stub filter, refer to the related links. |
No, default is to publish to all stubs in the project. |
You must copy the project files and the library files to a file server from where they can be downloaded by an intiContainer called fetch-project that is run before the stub container is started. You can then run the stubs in Istio.
Error codes
For details of any error codes, see Exit codes for Command-line client and Ant client.