Publishing stubs

You can publish a stub to IBM® DevOps Test Virtualization Control Panel (Test Virtualization Control Panel), Dockerfile and build context, Kubernetes, or Istio with Kubernetes by using the IBM DevOps Test Integrations and APIs (Test Integrations and APIs) Publish Stubs wizard.

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.

Publishing stubs to Test Virtualization Control Panel

You can publish a stub to Test Virtualization Control Panel by using the Test Integrations and APIs Publish Stubs wizard.

From the Test Integrations and APIs Publish Stubs wizard, publish one or more stubs to an Test Virtualization Control Panel instance.

In Test Integrations and APIs Test Factory perspective, right-click the Stubs folder that contains the stub that you want to publish and click Publish Stubs on the menu.
Alternatively, right-click the operation or component that contains the stub that you want to publish and click Publish Stubs on the menu.
Notes:
- If the operation or component or logical root that is selected does not contain any stubs, an error message is displayed.
- When publishing stubs to Test Virtualization Control Panel, it is more efficient to publish a container to avoid sending multiple instances of projects to Test Virtualization Control Panel when you run the stubs.
The Publish Stubs wizard is displayed.
On the Publish Destination page, select Control Panel.
Click Next.
In the Version fields, enter a version number (an integer) for the stub or set of stubs if more than one was selected for publication.
A stubs version number assists Test Virtualization Control Panel users when they are selecting the stubs that they want to run.
Note:
If you republish a stub with the same version, the old stub in the server is deleted. If multiple stubs are published with a specific version, a republish by using the same version must contain all of those stubs.

On the Environments pane, select one or more check boxes of the environment or environments where you want to publish one or more selected stubs.

An environment enables Test Integrations and APIs and Test Virtualization users to define groups of variables or tags that can be used in both tests and transport definitions.

Note:

By default, the current environment for the project is selected.

The following table describes the icons that can be displayed on the Environments pane.


Icon	Description
	The specified environment is created on the specified Test Virtualization Control Panel instance.
	The specified environment exists on the specified Test Virtualization Control Panel instance.
"N"	N" number of new stubs are published ("created") to the specified Test Virtualization Control Panel instance.
"N"	N" number of existing stubs are published ("updated") at a new version level to the specified Test Virtualization Control Panel instance.
"N"	N" number of existing stubs are published ("replaced") at the same version level on the specified Test Virtualization Control Panel instance.

Click Finish.

One or more selected stubs are published to the specified Test Virtualization Control Panel instance.

A status message is displayed to confirm this.
Click OK.

Publishing stubs to Dockerfile and build context

As part of your testing with Docker, you can publish stubs that you create in Test Integrations and APIs to Docker and build context by using the Publish Stubs wizard.

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. For more information, refer to the related links.

From the Test Integrations and APIs Publish Stubs wizard, publish one or more stubs to a Dockerfile and build context.

In Test Integrations and APIs Test Factory perspective, right-click the Stubs folder that contains the stub that you want to publish and click Publish Stubs on the menu.

Alternatively, right-click the operation or component that contains the stub that you want to publish and click Publish Stubs on the menu.

Note:
If the operation or component or logical root that is selected does not contain any stubs, an error message is displayed.

The Publish Stubs wizard is displayed.
On the Publish destination page, select Dockerfile and build context. Click Next. The Environment page is displayed.
In the Environment list, select the environment where you want to run one or more selected stubs.
An environment is used to select the physical bindings and tag values when you run the stubs within the Docker container. This selection might affect network addresses that are used to connect to and from a stub.
Note:
By default, the current environment in Test Integrations and APIs is selected.
Click Next. If two or more ports that are required by the chosen stubs conflict when they run in a Docker container, the Exposing ports page is displayed. Otherwise, the Dockerfile template and comment page is displayed.
Optionally, modify the settings for transports with conflicting port values to avoid the conflicts. Changes that you make are applied to the project.
From the Dockerfile template and comment page, in the Template list, select the template to be used to generate the Dockerfile. Test Integrations and APIs provides a ubuntu template for you to use that will generate Dockerfiles that will build images based on the Ubuntu operating system.
Enter the path to an empty directory outside of the project to which the Dockerfile and other required files are output. If the directory does not exist, it is created. Alternatively you can click Browse to browse to and select an empty directory outside of the project.
Click Finish.

One or more selected stubs are published to the Dockerfile and build context output directory.

A status message is displayed to confirm this.

Note:
After you publish a TIBCO Rendezvous stub, you must copy the TIBCO Rendezvous libraries that are required by TIBCO Rendezvous to the UserLibs folder of the output directory. If you are publishing a TIBCO EMS stub, you can ignore the message about copying TIBCO Rendezvous libraries. For more information, refer to Supported transports to publish stubs to a Dockerfile and build context in Related concepts.

The Dockerfile and build context files in the output directory can be used to build a Docker image.

Build the Docker image by using the Dockerfile

Build the Docker image by using the Dockerfile with following command:
```
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
```
Note:
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.

For more information about building Docker images, see the Docker Documentation in Related information.

When the Docker image is created, it can be run as a container. For information about running the container, refer to Publishing stubs to Docker in Related concepts.

Publishing stubs to Kubernetes

As part of your testing with Kubernetes, you can publish stubs that you create in Test Integrations and APIs to Kubernetes by using the Publish Stubs wizard.

From the Test Integrations and APIs Publish Stubs wizard, you can publish one or more stubs to Kubernetes.

In Test Integrations and APIs Test Factory perspective, right-click the Stubs folder that contains the stub that you want to publish and click Publish Stubs on the menu.

Alternatively, right-click the operation or component that contains the stub that you want to publish and click Publish Stubs on the menu.

Note:
If the operation or component or logical root that is selected does not contain any stubs, an error message is displayed.

The Publish Stubs wizard is displayed.
On the Publish destination page, select Kubernetes and then click Next.

The Environment dialog is displayed.
Select the environment from the Environment list.
An environment is used to select the physical bindings and tag values when you run the stubs within the Kubernetes container. This selection might affect network addresses that are used to connect to and from a stub.
Click Next.

Enter values for the Identifier, Docker registry, and Licensing server in the Resource configuration details dialog.


Option	Description
Identifier	An identifier string that is used to name and label resources within the Kubernetes cluster so that 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.
Docker registry	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`.
Licensing server	The host and port in the format `port@fully_qualified_host` for the IBM Common License Key Server. 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.

Enter the path to an empty directory outside of the project to which the generated YAML file and other required files are copied. If the directory does not exist, it is created. Alternatively, click Browse to browse to and select an empty directory outside of the project.
Click Finish.
The following resource files are generated in your output directory:
- A YAML file with an example definition of a Deployment and NodePort Service to run and expose the stub within Kubernetes.
- A tar.gz file that contains the project files required to run the stub.
- A tar.gz file that contains the third-party library files required to run the stub (if applicable).
A status message is displayed to confirm the generated resource files.

Note:
If one or more stubs do not listen on a port, for example, WebSphere MQ stubs, no NodePort service definition is generated in the YAML file.

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.