Skip to main content
Planned. This page describes designed behaviour that is not built yet. Details may change before it ships.
Ported from Garden’s documentation: garden-for/kubernetes/run-tests-and-tasks.md, gliss-cli at 3bc62a036 (Garden 0.14). Gliss runs Garden under the hood; the notes on this page say where Gliss differs.
Test actions run your tests. Run actions run one-off jobs, such as seeding a database. Both run in dependency order with the rest of the graph, and both are cached: Garden doesn’t rerun them when their version hasn’t changed. See Caching.
In Gliss, a Test or Run runs in one of two places:
  • In CI, with the exec type. The command runs in your CI job, next to your builds.
  • In the cluster, as a test release. Gliss turns the action into a release request, and the cluster agent runs it. You don’t need a kubeconfig.

​
Tests in CI

The exec type runs a command where Garden runs, which in Gliss is your CI job:

​
Tests in the cluster

The container Run and Test actions run a command in a container from a given image. Use them for integration tests that need the deployed app, or for jobs that must run next to it:
Garden’s helm-pod, kubernetes-pod and kubernetes-exec types depend on Garden’s Kubernetes provider. Which of them Gliss supports alongside level 2 deploys is not settled yet.

​
Test artifacts

Many action types, including exec, let you extract artifacts after a Test has completed. This is handy when you want to keep reports, or when a later step should check the output of a Test. List the artifacts in the Test’s spec.artifacts field:
After my-test runs, you find the files under .garden/artifacts/my-test-report in the CI workspace, where a later CI step can upload or check them. See Garden’s action type reference for the artifact options of each type.