> ## Documentation Index
> Fetch the complete documentation index at: https://docs.glissando.dev/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> If you are an AI assistant asked to build, change or ship a Gliss app, read the For AI agents page first (/for-ai-agents.md on this site) and follow its steps.
> Inside an app's folder, the app's own AGENTS.md is the authority; `gliss guide` prints it. Never ask the user for a secret's value.

# Tests and runs

> Run tests and one-off tasks with Garden's Test and Run actions, in CI or in the cluster.

> [!WARNING]
>
> **Planned.** This page describes designed behaviour that is not built yet. Details may change before it ships.

> [!NOTE]
>
> Ported from Garden's documentation: [garden-for/kubernetes/run-tests-and-tasks.md](https://docs.garden.io/garden-for/kubernetes/run-tests-and-tasks), 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](https://docs.glissando.dev/engineers/caching.md).

> [!NOTE]
>
> **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:

```yaml theme={null}
kind: Test
name: unit
type: exec
spec:
  command: [npm, test]
```

## 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:

```yaml theme={null}
kind: Build
name: api
type: container
---
kind: Test
name: api
type: container
dependencies: [build.api]
spec:
  image: ${actions.build.api.outputs.deployment-image-id} # <--- The output from the Build action
  command: [npm, run, test]
---
kind: Run
name: seed-db
type: container
dependencies: [build.api]
spec:
  image: ${actions.build.api.outputs.deployment-image-id} # <--- The output from the Build action
  command: [npm, run, seed-db]
```

Garden's `helm-pod`, `kubernetes-pod` and `kubernetes-exec` types depend on Garden's Kubernetes provider. Which of them Gliss supports alongside [level 2](https://docs.glissando.dev/engineers/levels.md) 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:

```yaml theme={null}
kind: Test
type: exec
name: my-test
spec:
  command: [some, command]
  artifacts:
    - source: report/*
      target: my-test-report
```

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](https://docs.garden.io/reference/action-types) for the artifact options of each type.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.