### Initialize Testkube Demo Installation

Source: https://docs.testkube.io/articles/tutorial/quickstart/individual-evaluation

Start the Testkube installer for a demo environment. This command initiates the setup process for a local, single-user installation.

```bash
testkube init demo
```

--------------------------------

### Install a Marketplace Workflow with Defaults

Source: https://docs.testkube.io/articles/examples/marketplace

Install a workflow using its default configuration. This is the simplest way to get started with a workflow.

```bash
# Install with the workflow's defaults  
testkube marketplace install redis-connectivity
```

--------------------------------

### Testkube MCP Server Output Example

Source: https://docs.testkube.io/articles/mcp-cli

Example output when starting the MCP server with verbose logging. This shows the server configuration, including organization, environment, and API URLs.

```bash
➜  ~ testkube mcp serve --verbose  

✔ loading config  

Starting MCP server with configuration:  

  Organization: Testkube Internal Demo (tkcorg_XXX)  

  Environment: Paris (tkcenv_YYY)  

  API URL: https://api.testkube.io  

  Dashboard URL: https://app.testkube.io  

  

Configure AI tools: https://docs.testkube.io/articles/mcp-configuration  

Feedback welcome: https://bit.ly/testkube-slack  

```

--------------------------------

### Install TestWorkflow from Marketplace

Source: https://docs.testkube.io/cli/testkube-marketplace-install

Use this command to download a TestWorkflow from the Testkube Marketplace. It allows overriding default configurations using the --set flag and can create or update an existing TestWorkflow in the specified namespace. Interactive prompts guide parameter configuration unless disabled.

```bash
testkube marketplace install <name> [flags]
```

--------------------------------

### Install go-junit-report Tool

Source: https://docs.testkube.io/articles/test-workflows-reports

Install the `go-junit-report` tool using `go install` to convert Go test output to JUnit format.

```bash
go install github.com/jstemmer/go-junit-report/v2@latest
```

--------------------------------

### Probe Configuration Examples

Source: https://docs.testkube.io/openapi/cloud/Agent-Operations----test-workflow-executions

Examples of different probe configurations for readiness, liveness, and startup checks.

```json
{
  "terminationGracePeriodSeconds": {
    "value": 0
  },
  "exec": {
    "command": [
      "string"
    ]
  },
  "httpGet": {
    "path": "string",
    "port": "string",
    "host": "string",
    "scheme": "string",
    "httpHeaders": [
      {
        "name": null,
        "value": null
      }
    ]
  },
  "tcpSocket": {
    "port": "string",
    "host": "string"
  },
  "grpc": {
    "port": 0,
    "service": {
      "value": "string"
    }
  }
}
```

--------------------------------

### Verify Bash Completion Setup

Source: https://docs.testkube.io/cli/testkube-completion-bash

After installing the completion script, start a new shell session to verify that the autocompletion is active.

```bash
testkube completion bash
```

--------------------------------

### Control Step Execution Order with Setup and After

Source: https://docs.testkube.io/articles/test-workflow-templates

Illustrates the execution order of workflow and template steps using 'setup' and 'after' hooks to control ordering. This is useful for defining pre-execution setup and post-execution teardown logic.

```yaml
# my-template-a  
spec:  
  steps:  
  - shell: echo a1  
  after:  
  - shell: echo a2  
  
# my-template-b  
spec:  
  setup:  
  - shell: echo b1  
  steps:  
  - shell: echo b2  
  after:  
  - shell: echo b3  
  
# my-workflow-w  
spec:  
  use:  
  - name: my-template-a  
  - name: my-template-b  
  setup:  
  - shell: echo w1  
  steps:  
  - shell: echo w2  
  
```

--------------------------------

### Testkube Install Command Usage

Source: https://docs.testkube.io/cli/testkube-install

Basic usage of the testkube install command. Use this to initiate the installation process.

```bash
testkube install [flags]
```

--------------------------------

### Create and install a Testkube Agent in one command

Source: https://docs.testkube.io/articles/multi-agent-cli

Combines agent creation and installation into a single command, specifying the agent name, the `--create` flag, and labels. This installs an Agent with runner and listener capabilities by default.

```bash
$ testkube install agent staging-runner --create -l env=staging  
```

--------------------------------

### Install Backstage UI Plugin

Source: https://docs.testkube.io/articles/backstage-integration

Install the Testkube UI plugin for Backstage using yarn.

```bash
yarn workspace packages/app add @testkube/backstage-plugin
```

--------------------------------

### Install Testkube CLI on Ubuntu

Source: https://docs.testkube.io/articles/install/cli

Install the Testkube CLI on Ubuntu using apt. This involves updating package lists, adding the Testkube repository key, and installing the testkube package.

```bash
sudo apt-get update && sudo apt-get install -y gnupg wget
sudo install -m 0755 -d /etc/apt/keyrings
wget -qO- https://repo.testkube.io/key.pub | sudo gpg --dearmor -o /etc/apt/keyrings/testkube.gpg
echo "deb [signed-by=/etc/apt/keyrings/testkube.gpg] https://repo.testkube.io/linux linux main" | sudo tee /etc/apt/sources.list.d/testkube.list
sudo apt-get update
sudo apt-get install -y testkube
```

--------------------------------

### Setup Configuration

Source: https://docs.testkube.io/openapi/cloud/Agent-Operations----test-workflow-with-executions

Defines setup steps for a workflow, including conditions, name, and whether the step is pure or paused.

```json
{
          "setup": [
            {
              "name": "string",
              "condition": "string",
              "pure": {
                "value": true
              },
              "paused": true
            }
          ]
}
```

--------------------------------

### Install Backstage Backend Plugin

Source: https://docs.testkube.io/articles/backstage-integration

Install the Testkube backend plugin for Backstage using yarn.

```bash
yarn workspace packages/backend add @testkube/backstage-plugin-backend
```

--------------------------------

### Testkube Install Command Options

Source: https://docs.testkube.io/cli/testkube-install

Specific options available for the 'testkube install' command. Use the help flag for more details.

```bash
-h, --help   help for install
```

--------------------------------

### Install Testkube CLI with Chocolatey on Windows

Source: https://docs.testkube.io/articles/install/cli

Install the Testkube CLI on Windows using Chocolatey. First, add the Kubeshop repository, then install the package.

```bash
choco source add --name=kubeshop_repo --source=https://chocolatey.kubeshop.io/chocolatey
choco install testkube -y
```

--------------------------------

### Install Testkube Runner

Source: https://docs.testkube.io/articles/tutorial/quickstart

Execute this command to install a Testkube Runner separately after initializing the Control Plane.

```bash
testkube install runner
```

--------------------------------

### Testkube Diagnostics Install Help Option

Source: https://docs.testkube.io/cli/testkube-diagnostics-install

This flag provides help information for the 'install' subcommand within 'testkube diagnostics'.

```bash
  -h, --help   help for install  
```

--------------------------------

### Initialize Testkube Standalone Agent

Source: https://docs.testkube.io/cli/testkube-init-standalone-agent

Use this command to install Testkube OSS in your current context. Various flags are available to customize the installation, such as specifying agent and API URIs, authentication details, and installation namespace.

```bash
testkube init standalone-agent [flags]
```

--------------------------------

### Troubleshoot Pods Not Starting

Source: https://docs.testkube.io/articles/install/deploy-on-aws-eks

Use `kubectl describe` and `kubectl logs` to diagnose why pods are not starting in the Testkube namespace.

```bash
kubectl describe pod <pod-name> -n testkube
kubectl logs <pod-name> -n testkube
```

--------------------------------

### Testkube Create Help Option

Source: https://docs.testkube.io/cli/testkube-create

Use the -h or --help flag to display help information for the create command.

```bash
-h, --help       help for create
```

--------------------------------

### Example k6 Test Script

Source: https://docs.testkube.io/test-types/executor-k6

A basic k6 test script that performs an HTTP GET request. This script can be used as a starting point for load testing.

```javascript
import http from "k6/http";  
  
  
export default function () {  
  http.get("https://testkube.kubeshop.io/");  
}  

```

--------------------------------

### Create MongoDB Directory

Source: https://docs.testkube.io/articles/inventory/generated/bitnami-mongodb-8.2.7_linux_arm64

This command creates a directory for MongoDB within the Bitnami installation. It is part of the Dockerfile setup.

```dockerfile
# mongo-8.dockerfile (114:114)
RUN mkdir -p /opt/bitnami/mongodb  

```

--------------------------------

### Full Example: Using Output Values and Step Results

Source: https://docs.testkube.io/articles/test-workflows-step-sharing

A comprehensive example showing how one step can produce both an output value and a file in its results directory, which are then consumed by subsequent steps.

```yaml
steps:
  - name: Produce
    id: produce
    shell: |
      echo "my_token" > /testkube/outputs/token
      echo '#!/bin/sh' > {{step.results}}/app
      echo 'echo "running"' >> {{step.results}}/app
      chmod +x {{step.results}}/app
  - name: Consume
    id: consume
    shell: |
      test "{{step.produce.outputs.token}}" = "my_token"  
      {{step.produce.results}}/app  
      echo "consumed" > /testkube/outputs/status  
  - name: Verify
    id: verify
    shell: |
      test "{{step.consume.outputs.status}}" = "consumed"  
      test "{{step.produce.outputs.token}}" = "my_token"  
      {{step.produce.results}}/app
```

--------------------------------

### Affected Range Example

Source: https://docs.testkube.io/articles/inventory/generated/bitnami-mongodb-8.2.7_linux_arm64

This indicates the version range of the software that is affected by a vulnerability. It is crucial for identifying if your installation is at risk.

```markdown
>=1.25.0
<1.25.6
```

--------------------------------

### Minikube Mount Output Example

Source: https://docs.testkube.io/articles/local-dev-loop

This is an example of the output you can expect when successfully mounting a local folder using `minikube mount`. It confirms the mount details and indicates the process must stay alive.

```bash
➜  testkube git:(main) ✗ minikube mount /Users/olensmar/Dev/cursor/testkube/testkube:/minikube-host/testkube --uid=1000 --gid=1000 

📁  Mounting host path /Users/olensmar/Dev/cursor/testkube/testkube into VM as /minikube-host/testkube ...  

    ▪ Mount type:   9p  

    ▪ User ID:      1000  

    ▪ Group ID:     1000  

    ▪ Version:      9p2000.L  

    ▪ Message Size: 262144  

    ▪ Options:      map[]  

    ▪ Bind Address: 127.0.0.1:61734  

🚀  Userspace file server: ufs starting  

✅  Successfully mounted /Users/olensmar/Dev/cursor/testkube/testkube to /minikube-host/testkube  
  
📌  NOTE: This process must stay alive for the mount to be accessible ...
```

--------------------------------

### Check Installed Testkube CRDs

Source: https://docs.testkube.io/articles/crds

Use `kubectl get crds` to list all Custom Resource Definitions installed in your Kubernetes cluster that are related to Testkube. This command helps verify the presence and availability of Testkube's CRDs.

```bash
kubectl get crds -n testkube
```

--------------------------------

### Parallel Playwright Tests with Dependency Transfer

Source: https://docs.testkube.io/articles/test-workflows-parallel

This example demonstrates running Playwright tests in parallel. It clones a Git repository, installs Node.js dependencies, and then distributes the tests across two parallel instances, transferring the cloned repository and installed modules.

```yaml
apiVersion: testworkflows.testkube.io/v1

kind: TestWorkflow

metadata:
  name: example-sharded-playwright-test
spec:
  content:
    git:
      uri: https://github.com/kubeshop/testkube
      paths:
      - test/playwright/playwright-project
  container:
    image: mcr.microsoft.com/playwright:v1.32.3-focal
    workingDir: /data/repo/test/playwright/playwright-project

  steps:
  - name: Install dependencies
    shell: 'npm ci'

  - name: Run tests
    parallel:
      count: 2
      transfer:
      - from: /data/repo
      shell: 'npx playwright test --shard {{ index + 1 }}/{{ count }}'
```

--------------------------------

### Use Templates for Reusability

Source: https://docs.testkube.io/articles/test-workflows-best-practices

Extract common workflow setups into templates to promote DRY principles. This example shows how to use an official k6 template.

```yaml
steps:
  - name: Run k6
    template:
      name: official/k6/v1
      config:
        version: "1.1.0"
        run: "k6 run test.js"

```

--------------------------------

### Get Curl Test Execution Details

Source: https://docs.testkube.io/test-types/executor-curl

Retrieve detailed information about a specific test execution, including its status, start and end times, and repository parameters.

```bash
kubectl testkube get execution curl-test-1
```

--------------------------------

### Example Webhook Resource Configuration

Source: https://docs.testkube.io/articles/webhooks

A complete example of a Webhook resource definition, including name, namespace, URI, events it should trigger on, and custom headers.

```yaml
apiVersion: executor.testkube.io/v1
kind: Webhook
metadata:
  name: example-webhook
  namespace: testkube
spec:
  uri: <YOUR_ENDPOINT_URL>
  events:
    - start-testworkflow
    - end-testworkflow-success
    - end-testworkflow-failed
  selector: ""
  headers:
    X-Token: "12345"

```

--------------------------------

### Example cURL to test internal service

Source: https://docs.testkube.io/test-types/executor-postman

Use this cURL command to test an internal Kubernetes service endpoint. Ensure the service name and port match your setup.

```shell
curl http://testkube-api-server:8088/health  
```

--------------------------------

### Install a Marketplace Workflow Interactively

Source: https://docs.testkube.io/articles/examples/marketplace

Install a workflow and be prompted for each parameter. Use --interactive=false to force non-interactive mode, using defaults and --set values.

```bash
# When attached to a terminal, install prompts for every parameter the workflow  
# exposes by default. --set values become the pre-filled default; empty input  
# keeps the current value; sensitive parameters are read with masked input.  
testkube marketplace install redis-connectivity  

# Force non-interactive (use defaults + --set as-is) -- handy on a terminal  
# when you know the overrides already cover everything you need.  
testkube marketplace install redis-connectivity --interactive=false
```

--------------------------------

### Get Test Suite Execution Details

Source: https://docs.testkube.io/articles/running-test-suites

After starting a test suite, use these commands to retrieve its execution details and watch its progress. The IDs will vary per execution.

```bash
$ kubectl testkube get tse 61e1136165e59a3183465125
```

```bash
$ kubectl testkube watch tse 61e1136165e59a3183465125
```

--------------------------------

### Configure Services for Selenium Grid

Source: https://docs.testkube.io/articles/test-workflows-best-practices

Set up Selenium Hub and browser nodes as services with readiness probes to ensure they are available before tests start. This example configures a standalone Chrome service.

```yaml
services:
  chrome:
    image: selenium/standalone-chrome:112.0
    timeout: 120s
    readinessProbe:
      httpGet:
        path: /wd/hub/status
        port: 4444
      periodSeconds: 1

```

--------------------------------

### Custom Step to Load Repositories into EmptyDir

Source: https://docs.testkube.io/articles/test-workflows-content

Use a custom setup step with `bitnami/git` to clone repositories into a common `EmptyDir` volume, making them available for all subsequent steps.

```yaml
spec:
  pod:
    volumes:
      - name: repos
        emptyDir: {}
  container:
    volumeMounts:
      - name: repos
        mountPath: /repos
  setup:
    - name: Load common repositories
      run:
        image: bitnami/git:2.49.0
        shell: |
          git clone --depth 1 https://github.com/kubeshop/testkube /repos/testkube
          git clone --depth 1 https://github.com/kubeshop/testkube-operator /repos/operator
    - shell: tree /repos
```

--------------------------------

### Get Test Execution Details using kubectl

Source: https://docs.testkube.io/test-types/executor-postman

Retrieve detailed information about a specific test execution, including its status, start and end times, and associated repository parameters. This command is helpful for post-execution analysis.

```bash
$ kubectl testkube get execution postman-test-6
```

--------------------------------

### Testkube Agent Installation Options

Source: https://docs.testkube.io/cli/testkube-install-agent

These options customize the agent installation. Use `--create` to automatically create the agent, specify environment IDs with `-e` or `--env`, and set labels with `-l` or `--label`.

```bash
      --create                        auto create that agent  

      --dry-run                       display helm commands only  

  -e, --env strings                   (with --create) environment ID or slug that the agent have access to  

  -N, --execution-namespace string    namespace to run executions (defaults to installation namespace)  

      --floating                      (with --create) create as a floating agent  

      --gitops                        enable gitops capability  

      --global                        make it global agent  

  -g, --global-template-path string   include global template  

      --group string                  make it grouped agent  

  -h, --help                          help for agent  

  -l, --label strings                 (with --create) label key value pair: --label key1=value1  

      --listener                      enable listener component (default: enabled when no component flags are set)  

  -n, --namespace string              namespace to install the agent  

      --runner                        enable runner component (default: enabled when no component flags are set)  

  -s, --secret string                 secret key for the selected agent  

      --version string                agent version to use (defaults to latest)  

      --webhooks                      enable webhooks capability  
```

--------------------------------

### Sharded Cypress Workflow Example

Source: https://docs.testkube.io/articles/examples/cypress-sharded

This YAML defines a TestWorkflow to run sharded Cypress tests. It loads tests from a Git repository, installs dependencies, and configures parallel execution with dynamic sharding based on test files.

```yaml
apiVersion: testworkflows.testkube.io/v1

kind: TestWorkflow

metadata:

  name: example-sharded-cypress

spec:

  content:

    git:

      uri: https://github.com/kubeshop/testkube

      paths:

        - test/cypress/cypress-13

  container:

    image: cypress/included:13.6.4

    workingDir: /data/repo/test/cypress/cypress-13

  

  steps:

    - name: Install dependencies

      shell: 'npm ci'

  

    - name: Run tests

      parallel:

        maxCount: 5

        shards:

          testFiles: 'glob("cypress/e2e/**/*.js")'

        description: '{{ join(map(shard.testFiles, "relpath(_.value, \"cypress/e2e\")"), ", ") }}'

        transfer:

          - from: /data/repo

        container:

          resources:

            requests:

              cpu: 1

              memory: 1Gi

          env:

            - name: CYPRESS_CUSTOM_ENV

              value: CYPRESS_CUSTOM_ENV_value

        run:

          args:

            - --env

            - NON_CYPRESS_ENV=NON_CYPRESS_ENV_value

            - --spec

            - '{{ join(shard.testFiles, ",") }}'


```

--------------------------------

### Setup Configuration for Git Repository

Source: https://docs.testkube.io/openapi/cloud/Agent-Operations----test-workflow-with-executions

Configures the setup phase of a workflow, specifically for fetching content from a Git repository. Includes URI and revision details.

```json
{
            "git": {
              "uri": "string",
              "revision": "string"
}
```

--------------------------------

### Kubectl Workflow Example

Source: https://docs.testkube.io/articles/examples/kubectl-basic

This example demonstrates a multi-step workflow for executing various kubectl commands, including checking cluster connectivity, listing pods, and checking service status. It uses the bitnami/kubectl image for each step.

```yaml
apiVersion: testworkflows.testkube.io/v1

kind: TestWorkflow

metadata:
  name: kubectl-sample
  namespace: testkube
  labels:
    docs: example
spec:
  steps:
  - name: Check cluster connectivity
    container:
      image: bitnami/kubectl:1.28
    shell: |
      kubectl cluster-info
      kubectl get nodes
  - name: List pods in default namespace
    container:
      image: bitnami/kubectl:1.28
    shell: |
      kubectl get pods -n default
  - name: Check service status
    container:
      image: bitnami/kubectl:1.28
    shell: |
      kubectl get services -A
      kubectl get deployments -A

```

--------------------------------

### Configure Global Template with Helm Chart Values

Source: https://docs.testkube.io/articles/test-workflow-templates

Example of enabling and configuring a global template directly within Helm Chart values for agent installation. This is used to apply company-wide configurations like labels or security contexts to all Test Workflows.

```yaml
global:  
  testWorkflows:  
    globalTemplate:  
      enabled: true  
      spec:  
        pod:  
          labels:  
            key: value  
          securityContext:  
            runAsNonRoot: true  

```

--------------------------------

### Example Action Parameters Configuration

Source: https://docs.testkube.io/articles/test-triggers

Illustrates how to use static values, JSONPath expressions, and Golang templates for config and tags. Use JSONPath to extract data from the trigger event's resource object.

```yaml
spec:  
  actionParameters:  
    config:  
      environment: production  
      datavalue: jsonpath={.data.test} # if the resource object is a configmap with key `test`  
      labels: "{{ .ObjectMeta.Labels }}"  
    tags:  
      workflow: core  
      trigger: jsonpath={.metadata.namespace} # namespace of the resource object  
      name: "{{ .ObjectMeta.Name }}"  
```

--------------------------------

### Synchronized k6 Workers for Distributed Performance Testing

Source: https://docs.testkube.io/articles/test-workflows-best-practices

Configure distributed execution for performance tools like k6 using `parallel` and `paused: true` to ensure all workers start simultaneously. This example demonstrates fanning out load generation across multiple pods.

```yaml
steps:
  - name: Run k6 distributed
    parallel:
      count: 5
      paused: true
      transfer:
        - from: /data/repo
      container:
        image: grafana/k6:1.1.0
        workingDir: /data/repo/test/k6
      run:
        shell: |
          k6 run k6-smoke-test.js \
            --execution-segment '{{ index }}/{{ count }}:{{ index + 1 }}/{{ count }}'

```

--------------------------------

### Workflow with Selenium Hub and Nodes

Source: https://docs.testkube.io/articles/test-workflows-services

This example defines a Test Workflow that starts a Selenium Hub service at the workflow level and two Selenium Chrome Nodes as step-level services. It configures environment variables for the nodes to connect to the hub and sets up test execution parameters.

```yaml
kind: TestWorkflow

apiVersion: testworkflows.testkube.io/v1

metadata:
  name: selenium-java-hub-and-nodes
description: "Selenium Java + Hub + Chrome Nodes"
spec:
  config:
    chromeNodes: {type: integer, default: 2}
    junitParallelism: {type: integer, default: 4}
  content:
    git:
      uri: https://github.com/kubeshop/testkube
      revision: main
      paths:
        - test/selenium/selenium-java
  container:
    image: maven:3.9.11-eclipse-temurin-17
    workingDir: /data/repo/test/selenium/selenium-java
    resources:
      requests:
        cpu: 1
        memory: 512Mi
  services:
    hub:
      image: selenium/hub:4.34.0-20250727
      timeout: 120s
      logs: always
      resources:
        requests:
          cpu: 300m
          memory: 256Mi
      readinessProbe:
        httpGet:
          path: /status
          port: 4444
        periodSeconds: 1
  steps:
    - name: Start node-chrome
      services:
        node-chrome:
          image: selenium/node-chrome:112.0-chromedriver-112.0-grid-4.34.0-20250727
          timeout: 120s
          logs: always
          count: config.chromeNodes
          resources:
            requests:
              cpu: 500m
              memory: 512Mi
          readinessProbe:
            httpGet:
              path: /status
              port: 5555
            periodSeconds: 1
          env:
            - name: SE_EVENT_BUS_HOST
              value: '{{ services.hub.0.ip }}'
            - name: SE_EVENT_BUS_PUBLISH_PORT
              value: "4442"
            - name: SE_EVENT_BUS_SUBSCRIBE_PORT
              value: "4443"
      steps:
      - name: Run test
        run:
          env:
            - name: REMOTE_WEBDRIVER_URL
              value: 'http://{{ services.hub.0.ip }}:4444/wd/hub'
            - name: BROWSER
              value: 'chrome'
            - name: JUNIT_JUPITER_EXECUTION_PARALLEL_ENABLED
              value: "true"
            - name: JUNIT_JUPITER_EXECUTION_PARALLEL_MODE_DEFAULT
              value: concurrent
            - name: JUNIT_JUPITER_EXECUTION_PARALLEL_MODE_CLASSES_DEFAULT
              value: concurrent
            - name: JUNIT_JUPITER_EXECUTION_PARALLEL_CONFIG_STRATEGY
              value: fixed
            - name: JUNIT_JUPITER_EXECUTION_PARALLEL_CONFIG_FIXED_PARALLELISM
              value: "{{ config.junitParallelism }}"
          shell: |
            mvn test
            mvn surefire-report:report
        artifacts:
          paths:
            - target/site/**/*
            - target/surefire-reports/**/*

```

--------------------------------

### Test Workflow with Various Step Configurations

Source: https://docs.testkube.io/articles/test-workflows-examples-basics

This example demonstrates how to configure steps with optionality, negative outcomes, conditions, retries, and default behavior.

```yaml
apiVersion: testworkflows.testkube.io/v1

kind: TestWorkflow

metadata:

  name: overview--example-8

spec:

  steps:

    - name: "Step 1"

      optional: true

      shell: exit 1

    - name: "Step 2"

      negative: true

      shell: exit 1

    - name: "Step 3"

      negative: true

      shell: exit 0

    - name: "Step 4"

      shell: echo hello

    - name: "Step 5"

      condition: always

      retry:

        count: 3

      shell: echo foo; exit 1

```

--------------------------------

### Install kind on Windows

Source: https://docs.testkube.io/articles/install/quickstart-no-k8s

Install the 'kind' tool on Windows using Chocolatey. Ensure Chocolatey is installed first.

```powershell
choco install kind
```

--------------------------------

### Execution Configuration Sample

Source: https://docs.testkube.io/openapi/cloud/Agent-Operations----test-workflow-with-executions

This sample details the execution configuration, including working directory, image details, environment variables, and resource limits.

```json
{
  "shell": "string",
  "run": {
    "workingDir": {
      "value": "string"
    },
    "image": "string",
    "imagePullPolicy": "Always",
    "env": [
      {
        "global": {
          "value": true
        },
        "name": "string",
        "value": "string",
        "valueFrom": {
          "configMapKeyRef": {
            "key": null,
            "name": null,
            "optional": null
          },
          "fieldRef": {
            "apiVersion": null,
            "fieldPath": null
          },
          "resourceFieldRef": {
            "containerName": null,
            "divisor": null,
            "resource": null
          },
          "secretKeyRef": {
            "key": null,
            "name": null,
            "optional": null
          }
        }
      }
    ],
    "envFrom": [
      {
        "prefix": "string",
        "configMapRef": {
          "name": "string",
          "optional": false
        },
        "secretRef": {
          "name": "string",
          "optional": false
        }
      }
    ],
    "command": {
      "value": [
        "string"
      ]
    },
    "args": {
      "value": [
        "string"
      ]
    },
    "shell": {
      "value": "string"
    },
    "resources": {
      "limits": {
        "cpu": "string"
      }
    }
  }
}

```

--------------------------------

### Install Runner Agent with Helm

Source: https://docs.testkube.io/articles/agents-overview

Commands to install a Runner Agent using Helm. Ensure you have Helm installed and configured.

```bash
helm upgrade --install testkube-agent testkube/testkube-agent \
  --namespace testkube \
  --set agent.name=my-agent \
  --set agent.namespace=testkube \
  --set agent.token=$(testkube oauth2-token) \
  --set agent.apiUris.controlPlane=https://api.testkube.io \
  --set agent.apiUris.collector=https://collector.testkube.io
```

--------------------------------

### Testkube Install CRD Command Usage

Source: https://docs.testkube.io/cli/testkube-install-crd

Basic usage of the 'testkube install crd' command. Use this to initiate the installation of Testkube CRDs.

```bash
testkube install crd [flags]
```

--------------------------------

### Testkube SEE ALSO Command

Source: https://docs.testkube.io/cli/testkube-create-ticket

This section provides a reference to the main Testkube entrypoint command. Use this to navigate to the primary CLI documentation.

```bash
testkube - Testkube entrypoint for kubectl plugin
```

--------------------------------

### Install Testkube Agent with Helm

Source: https://docs.testkube.io/articles/install/standalone-agent

Installs the Testkube agent using Helm, creating the namespace if it doesn't exist and ensuring CRDs are installed.

```bash
helm upgrade --install testkube kubeshop/testkube \
  --create-namespace \
  --namespace testkube \
  --set installCRDs=true
```

--------------------------------

### Testkube Pro Connect Command Options

Source: https://docs.testkube.io/cli/testkube-pro-connect

Lists the specific options available for configuring the connection to Testkube Pro, including agent details, URIs, and installation parameters.

```bash
--agent-prefix string         usually don't need to be changed [required for custom cloud mode] (default "agent")  
      --agent-token string          Testkube Pro agent key [required for centralized mode]  
      --agent-uri string            Testkube Pro agent URI [required for centralized mode]  
      --agent-uri-override string   agent uri override  
      --api-prefix string           usually don't need to be changed [required for custom cloud mode] (default "api")  
      --api-uri-override string     api uri override  
      --auth-uri-override string    auth uri override  
      --callback-port int           usually don't need to be changed [required for custom cloud mode] (default 8090)  
      --chart string                chart name (usually you don't need to change it) (default "kubeshop/testkube")  
      --custom-auth                 usually don't need to be changed [required for custom cloud mode]  
      --dry-run                     dry run mode - only print commands that would be executed  
      --embedded-nats               embedded NATS server in agent  
      --env-id string               Testkube Pro environment id [required for centralized mode]  
  -h, --help                        help for connect  
      --logs-prefix string          usually don't need to be changed [required for custom cloud mode] (default "logs")  
      --logs-uri string             Testkube Pro logs URI [required for centralized mode]  
      --logs-uri-override string    logs service uri override  
      --master-insecure             should client connect in insecure mode (will use http instead of https)  
      --minio-replicas int          MinIO replicas  
      --mongo-replicas int          MongoDB replicas  
      --name string                 installation name (usually you don't need to change it) (default "testkube")  
      --namespace string            namespace where to install (default "testkube")  
      --no-confirm                  don't ask for confirmation - unatended installation mode  
      --no-minio                    don't install MinIO  
      --no-mongo                    don't install MongoDB  
      --org-id string               Testkube Pro organization id [required for centralized mode]  
      --root-domain string          usually don't need to be changed [required for custom cloud mode] (default "testkube.io")  
      --ui-prefix string            usually don't need to be changed [required for custom cloud mode] (default "app")  
      --ui-uri-override string      ui uri override  
      --values string               path to Helm values file  
```

--------------------------------

### Get Board

Source: https://docs.testkube.io/assets/files/testkube-control-plane-openapi-47dda1e87b7a2ce9c9944a75c3ffb617.yaml

Get a board by its `id` or `slug`.

```APIDOC
## GET /organizations/{id}/boards/{boardID}

### Description
Get a board by its `id` or `slug`.

### Method
GET

### Endpoint
/organizations/{id}/boards/{boardID}

### Parameters
#### Path Parameters
- **id** (string) - Required - The organization ID
- **boardID** (string) - Required - The ID or slug of the board
```

--------------------------------

### Run Test Workflow from Template

Source: https://docs.testkube.io/articles/test-workflows

This example demonstrates how to execute a test workflow using a predefined template. It specifies the template name and configuration parameters, including version and custom command-line arguments.

```yaml
steps:
  - name: Run from template
    template:
      name: example-template/cypress
      config:
        version: 13.5.0
        params: '--env NON_CYPRESS_ENV=NON_CYPRESS_ENV_value --config ''{"screenshotsFolder":"/data/artifacts/screenshots","videosFolder":"/data/artifacts/videos"}'''
```

--------------------------------

### Install cert-manager using Helm

Source: https://docs.testkube.io/articles/install/deploy-on-aws-eks

Installs the cert-manager component, which is recommended for managing TLS certificates within your EKS cluster. Ensure Helm is installed and configured.

```bash
helm repo add jetstack https://charts.jetstack.io && helm repo update

helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager --create-namespace \
  --set crds.enabled=true
```

--------------------------------

### Install a Runner Agent using Testkube CLI

Source: https://docs.testkube.io/articles/test-workflows-running

Use this command to create and install a Runner Agent with a specified name. Ensure the Testkube CLI is installed and logged in.

```bash
$ testkube install agent staging-runner --create --runner
```

--------------------------------

### Connect Testkube OSS to Pro (Full Data Migration)

Source: https://docs.testkube.io/articles/install/oss-to-cloud

Use this command to connect to Testkube Pro and migrate all existing execution data from your OSS installation. Ensure you have your Pro credentials and `kubectl` configured.

```bash
testkube pro connect --api-key <key> --org-id <org> --env-id <env> --root-domain <domain>
```

--------------------------------

### Namespace Command Help

Source: https://docs.testkube.io/cli/testkube-config-namespace

Displays help information for the `testkube config namespace` command.

```bash
  -h, --help   help for namespace
```