Publish stubs by using an Ant task

You can publish stubs by using the HCL DevOps Test Virtualization Control Panel (Test Virtualization Control Panel) Ant task, the Dockerfile and build context Ant task or the Kubernetes Ant task.

Note: To publish to a Dockerfile and build context or Kubernetes, only stubs that are based on specific transports are supported. For more information, refer to the related links.

The following is the syntax to use:

<taskdef name="publishStubs" classname="com.ghc.ghTester.ant.PublishStubs" classpathref="tasklib" />

Test Virtualization Control Panel

The following is an example of the syntax to publish a stub by using the Test Virtualization Control Panel Ant task:

<publishStubs serverUrl="https://<Hostname or IP address>:5443/RTCP/" 
domain="<Domain name>" environment="<Environment name>" project="<Path to project file>" />

The following table lists the attributes that you can use with the Test Virtualization Control Panel publishStubs Ant task for publishing stubs.


Attribute	Description	Required
domain	Domain name	Yes
environment	Environment name	Yes
failureProperty	The name of a property that is set in the event of a failure.	No
haltOnFailure	Set to true to fail the Ant script if the stub fails to start (flag).	No, default is false.
majorVersion	The major version at which to publish the stubs. 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. 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.
optionsFile	A 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
project	The full path to project file.	Yes
securityToken	The value of the security token to use for authentication with Test Virtualization Control Panel when domain security is enabled (optional).	No, default is to send no token.
serverUrl	URL of the Test Virtualization Control Panel.	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 DevOps Test Integrations and APIs (Test Integrations and APIs). 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.
updateMode	The `updateMode` option can be specified to further control which stubs are published.	No, default is publish all stubs, old and new.

Publishing stubs to Dockerfile and build context Ant task

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. See Preparing to use Docker.

The following is an example syntax to publish a stub by using the Dockerfile and build context Ant task:

<publishStubs destination="docker" outputDirectory="<Path to output directory>" 
dockerfileTemplate="ubuntu" environment="<Name of environment>" 
project="<Path to project file>" stubFilter="<Filter value>" />

The following table lists the attributes that you can use with the Dockerfile and build context publishStubs Ant task for publishing stubs.


Attribute	Description	Required
destination	The destination to publish stubs. The value can be `docker` or `hqs`. The default is `hqs` and is used if the destination option is not specified. `docker` must be specified to publish to a Dockerfile and build context.	Yes
dockerfileComment	Optional text in quotation marks that is added as a comment in the generated Dockerfile.	No
dockerfileTemplate	A template Dockerfile that is used to generate a Dockerfile. Test Integrations and APIs provides the ubuntu template for you to use.	Yes
environment	Environment name.	Yes
project	The full path to a project file.	Yes
optionsFile	A 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
outputDirectory	The path to the directory where the Dockerfile and other context files are output.	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 DevOps Test Integrations and APIs (Test Integrations and APIs). 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.

The following example on Windows systems outputs a Dockerfile and build context files to C:\myImages\stubA.

<publishStubs destination="docker" outputDirectory="C:\myImages\stubA" 
dockerfileTemplate="ubuntu" environment="Env1" 
project="C:\projects\P1\P1.ghp" stubFilter="&lt;O&gt;TestOperation&lt;/O&gt;" />

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.

The following is an example syntax to build a Docker image from the output of the Ant task:

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 more information about building Docker images, refer to the related links.

Publishing stubs to Kubernetes Ant task

The following is an example syntax to publish a stub by using the Kubernetes Ant task:

<publishStubs 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>" />

The following table lists the attributes that you can use with the Kubernetes publishStubs Ant task for publishing stubs.


Attribute	Description	Required
destination	The destination to publish stubs. `k8s` must be specified to publish to Kubernetes.	Yes
dockerRegistry	The Docker registry and namespace in the format `host:port/namespace`. This value is used to reference the Docker image. The default is `my.docker.registry:5000`.	Yes
environment	Environment name.	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
licensingServer	The FlexNet server URL. By default, the server URL is taken from the HCL_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_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
optionsFile	A 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
outputDirectory	The path to the directory where the YAML file, project files and Library files are output.	Yes
project	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 DevOps Test Integrations and APIs (Test Integrations and APIs). 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.

Error codes

For details of any error codes, see Exit codes for Command-line client and Ant client.