We moved our workloads to Kubernetes and now want to run our tests in the cluster. In this series I describe our journey with Testkube. This setup works for us, your milage may vary. You can view all posts in this series by filtering on tag testkube-journey

Artifacts

When we run our tests we hope everything is but prepare for ❗ . The output of the tests is placed on a location that is shared with all steps in the TestWorkflow. Testkube can collect these files in an artifact.

TLDR: artifacts is a wildcard path filter relative to the workingDir.

We added the artifacts to the TestWorkflow with “/data/**/*” as path, but gitops kept synchronising. The artifact entry never showed up in the resource. Turns out the path must be relative to the workingDir. After changing to “**/*” all files from “/data” are saved as artifact with the TestExecution.

To download the artifacts we used the cli. Only to be presented with a failure of EOF.

testkube get artifact 1234abcde1234abcde --client direct --api-url http://testkube-api-server:8088
testkube download artifacts 1234abcde1234abcde --download-dir /tmp --client direct --api-url http://testkube-api-server:8088

The logs from the Testkube-api showed the execution was not found. Printing the artifacts would show no execution is registered with the artifacts. We think this was caused by setting up Testkube without Minio first and adding it later. After removing MongoDB and Minio to get a clean install again, it still would not work. We think this was caused by enabling the legacyTests. So we disabled it in the values.yaml without any change in behaviour . Turns out this was a bug that was fixed in a later release. After the upgrade we were able to download all artifacts.

Another way to get the artifacts is by downloading them from the api.

https://testkube-api-server/v1/test-workflow-executions/1234abcde1234abcde/artifact-archive

We struggled some time to get the api working. The v1 in the url was missing at first. Not sure why this is not on the docs, but we got it from slack.

The api will be used to get our pipeline connected to the tests. As described in Testkube journey – where we start we want to automate the decision to release software to production. More about that in a future post.