← Testkube SkillsCONTENT HISTORY

Update to Testkube Skills

Snapshot Sep 30, 2026 · 23:13 UTC · version 1.0.0

Collection source: not recorded for this historical snapshot.

WHAT CHANGED · RULE-BASED ANALYSIS

First saved snapshot

No earlier snapshot is available to establish a change.

Compare saved observations

Download comparison JSON
Full technical diff · 0 changed fields
Full snapshot data
{
  "name": "installing-testkube-oss-agent",
  "description": "Set up a local Testkube OSS standalone agent — deploy the open-source Testkube agent into a Kubernetes cluster for local testing (k3d by default when a fresh local cluster is needed; minikube, kind, k3d, or remote all work). Use when you need a local OSS Testkube environment and none is running yet. Checks for an existing Testkube agent in the current cluster of ANY type first and reuses it; installs missing pieces only after confirming each step with the user.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 245
    }
  ],
  "skill_md_contents": "---\nname: installing-testkube-oss-agent\ndescription: \"Set up a local Testkube OSS standalone agent — deploy the open-source Testkube agent into a Kubernetes cluster for local testing (k3d by default when a fresh local cluster is needed; minikube, kind, k3d, or remote all work). Use when you need a local OSS Testkube environment and none is running yet. Checks for an existing Testkube agent in the current cluster of ANY type first and reuses it; installs missing pieces only after confirming each step with the user.\"\n---\n\n# installing-testkube-oss-agent\n\nSet up a self-contained local Testkube OSS install: a Kubernetes cluster with the **Testkube standalone agent**\ndeployed into its `testkube` namespace. Standalone (OSS) mode has **no web dashboard** — everything is driven through\nthe CLI. **k3d** (k3s in Docker) is the default when you need a *fresh* local cluster, but any cluster works.\n\n**Always check for an existing Testkube agent first — in the current cluster of any type (minikube, kind, k3d,\nremote) — and reuse it.** Only create a cluster or deploy the agent when none is running, and **confirm each mutating\nstep with the user before running it** — these commands install binaries, create clusters, and deploy into them.\n\n## The Core Loop\n\nRun these in order. Reuse whatever already exists; confirm every mutating step with the user before running it.\n\n1. **Check prerequisites** — install any missing ones with the OS package manager first (confirm with the user, per\n   Rule 2).\n\n   Always required:\n   ```bash\n    TK_CMD=\"$(command -v testkube 2>/dev/null || command -v tk 2>/dev/null || command -v kubectl-testkube 2>/dev/null)\"  # Testkube CLI — else use installing-testkube-cli\n    if [ -n \"$TK_CMD\" ]; then echo \"$TK_CMD\"; else echo \"Testkube CLI not found; use installing-testkube-cli\"; fi\n   command -v kubectl                                  # kubectl — talk to the cluster\n   command -v helm                                     # helm — testkube init standalone-agent invokes Helm internally\n   command -v curl                                     # curl — k3d install script\n   ```\n\n   Only when you need a fresh local k3d cluster (steps 3–4):\n   ```bash\n   docker info >/dev/null 2>&1 && echo docker-ok       # Docker daemon must be running\n   ```\n\n   Required always: the **Testkube CLI**, **`kubectl`**, **`helm`**, and **`curl`**. **Docker** is required only when\n   creating a k3d cluster. `k3d` itself is installed in step 3 if it's missing and you need a fresh local cluster.\n2. **Check for an existing Testkube agent — in the current cluster of ANY type — and reuse it.** The agent may\n   already be running in minikube, kind, k3d, or a remote cluster; detection is cluster-agnostic. Before creating\n   anything:\n   ```bash\n   TK_CMD=\"$(command -v testkube || command -v tk || command -v kubectl-testkube)\"\n   kubectl config current-context      # which cluster are we pointed at?\n    if kubectl get namespace testkube >/dev/null 2>&1; then kubectl get pods -n testkube; else echo \"testkube namespace not found\"; fi   # is a Testkube agent Running here?\n   if [ -n \"$TK_CMD\" ]; then \"$TK_CMD\" version; else echo \"Testkube CLI not found; use installing-testkube-cli\"; fi  # does it print a SERVER version too?\n   ```\n   If the `testkube` namespace has Running agent pods and `testkube version` shows a server version, it is already\n   installed — **stop here and use it**, whatever the cluster type. If the agent runs in a different cluster, list\n   contexts and switch to it rather than creating a new one:\n   ```bash\n   kubectl config get-contexts\n   kubectl config use-context <context-with-the-agent>   # e.g. minikube, kind-..., k3d-testkube\n   ```\n   Steps 3–4 create a *fresh local* cluster with k3d — **skip both entirely if you already have a usable cluster**\n   (minikube, kind, k3d, remote) and just deploy the agent into it (step 5).\n3. **Install k3d (if missing)** — confirm with the user, then:\n   ```bash\n   command -v bash\n   curl -fsSL https://raw.githubusercontent.com/k3d-io/k3d/v5.7.4/install.sh -o /tmp/k3d-install.sh\n   TAG=v5.7.4 bash /tmp/k3d-install.sh\n   ```\n   Skip if `command -v k3d` already resolves, or if you're reusing minikube/kind/another cluster (e.g. `brew install k3d`).\n4. **Create the cluster (if missing)** — confirm, then:\n   ```bash\n   k3d cluster create testkube\n   ```\n   Skip if you already have a running cluster to use — reuse it (e.g. `minikube start` / an existing `k3d cluster\n   list` entry). k3d merges its context into your kubeconfig and switches to it.\n5. **Deploy the agent (if missing)** — confirm, then:\n   ```bash\n   TK_CMD=\"$(command -v testkube || command -v tk || command -v kubectl-testkube)\"\n   if [ -n \"$TK_CMD\" ]; then \"$TK_CMD\" init standalone-agent --no-confirm; else echo \"Testkube CLI not found; use installing-testkube-cli\"; fi\n   ```\n   (`testkube init oss` is an alias.) Skip if the `testkube` namespace already has the agent Running. **Get the\n   user's approval before running this (Rule 2).** Note: `testkube init standalone-agent` prints\n   `Do you want to continue? [Y/n]` and reads the answer from the terminal (`/dev/tty`) — piping `yes` or any answer\n   to stdin does **not** reach it, so in a non-interactive / agent / CI shell the command hangs forever. Once the user\n   has approved out of band, run it non-interactively: prefer the **Helm alternative below** (inherently\n   non-interactive), or pass `--no-confirm` (the human approval Rule 2 requires has already happened — see Rule 6).\n   Only when a real human is at the terminal should you leave the prompt for them to answer.\n6. **Verify** — wait until the API server pods are `Running` (and MinIO if installed — it is by default), then confirm\n   CLI ↔ server:\n   ```bash\n   TK_CMD=\"$(command -v testkube || command -v tk || command -v kubectl-testkube)\"\n   kubectl get all -n testkube\n   if [ -n \"$TK_CMD\" ]; then \"$TK_CMD\" version; else echo \"Testkube CLI not found; use installing-testkube-cli\"; fi  # must print client AND server versions\n   ```\n   The `testkube-api-server` pod often shows several restarts in the first ~2 minutes while it waits for MongoDB\n   or PostgreSQL, MinIO, and NATS to become ready — this is normal startup behavior, not a failure. Wait for `Ready 1/1`, \n   not for zero restarts.\n7. **Report** — state what was reused vs newly installed, and the cluster/context name.\n\n## Rules\n\n1. **MUST check for an existing agent in the current cluster (any type) before creating anything.** If a Testkube\n   agent is running in the active kube context — minikube, kind, k3d, or remote — and `testkube version` shows a\n   server version, reuse it; do not spin up a new cluster or redeploy.\n2. **MUST confirm every mutating step with the user before running it.** Installing k3d, creating a cluster, deploying\n   the agent, and teardown all change the local system — describe the exact command and wait for the user's go-ahead\n   before each one.\n3. **MUST reuse existing pieces individually.** If you already have a running cluster (minikube/kind/k3d/remote),\n   deploy into it instead of creating one. Skip k3d install if `k3d` is on PATH; skip cluster create if a usable\n   cluster exists; skip `testkube init standalone-agent` if the agent is already Running.\n4. **MUST verify before reporting success.** `testkube version` must print both a client and a server version.\n5. **MUST NOT tear down without explicit confirmation.** `testkube purge` and cluster delete commands destroy the\n   local environment — never run them unprompted.\n6. **The user must approve the init step (Rule 2) — but that approval need not be typed into the CLI's own prompt.**\n   `testkube init standalone-agent` reads its `[Y/n]` prompt from the terminal, so in a non-interactive / agent / CI\n   shell it hangs (piping `yes` does not help). Never skip the user's approval. Once they have approved, run\n   non-interactively via the Helm alternative or with `--no-confirm` — the human approval is what matters, not who\n   types `Y`. Leave the prompt for the user to answer only when a real human is interacting with the terminal.\n7. **REQUIRED SUB-SKILL:** the Testkube CLI must be present — use installing-testkube-cli. Also needs `kubectl`,\n   `helm`, and `curl` on PATH. Docker (`docker info`) is required only when creating a k3d cluster. `k3d` is installed\n   by step 3 when needed.\n\n## Helm alternative (Step 5)\n\nEquivalent to `testkube init standalone-agent`, useful for pinning chart values / CI:\n\n```bash\nhelm repo add kubeshop https://kubeshop.github.io/helm-charts\nhelm repo update\nhelm upgrade --install testkube kubeshop/testkube \\\n  --create-namespace \\\n  --namespace testkube \\\n  --set installCRDs=true\n```\n\n## Teardown\n\nDestructive — **confirm with the user first** (Rule 5).\n\n1. **Remove the agent** (any cluster type):\n   ```bash\n    TK_CMD=\"$(command -v testkube || command -v tk || command -v kubectl-testkube)\"\n    if [ -n \"$TK_CMD\" ]; then \"$TK_CMD\" purge; else echo \"Testkube CLI not found; use installing-testkube-cli\"; fi  # or: helm delete --namespace testkube testkube\n   ```\n\n2. **Delete the cluster only if this skill created it** — match the cluster type from setup:\n   - **k3d** (created in step 4): `k3d cluster delete testkube`\n   - **minikube**: `minikube delete` (or the profile-specific delete command)\n   - **kind**: `kind delete cluster --name <cluster-name>`\n   - **Remote / shared cluster**: do **not** delete the cluster — only purge the agent unless the user explicitly asks\n     to remove the whole cluster.\n\n## Common Mistakes\n\n- **Creating a new cluster when an agent already runs elsewhere** — the step-2 check is cluster-agnostic; if minikube,\n  kind, or a remote cluster already has the agent, switch context and reuse it instead of spinning up k3d. List\n  clusters with `kubectl config get-contexts` (and `k3d cluster list` for k3d specifically).\n- **`docker info` fails / k3d cluster create hangs** — Docker isn't running. k3d needs a live Docker daemon; start Docker\n  Desktop or `systemctl start docker` first. Docker is not required when reusing an existing remote/minikube/kind cluster.\n- **`testkube: command not found`** — the CLI isn't installed; see installing-testkube-cli.\n- **Using bare `testkube init`** — current CLI requires a profile; use `testkube init standalone-agent` (alias: `oss`)\n  for OSS standalone mode.\n- **Aborted `init` leaves orphaned processes / a stuck Helm release** — killing the wrapper of an `init` attempt\n  (TaskStop, Ctrl-C, timeout) can leave `testkube init` child processes running that still hold a Helm lock, so the\n  next attempt fails with `another operation (install/upgrade/rollback) is in progress`. Before retrying:\n  `pkill -f 'testkube init'`, then check `helm list -n testkube` for a stuck release and `helm uninstall` (or roll\n  back) it. This is also why a non-interactive install path (Helm, or `--no-confirm` after approval) is safer than\n  leaving the CLI hung on its TTY prompt.\n- **`testkube version` shows no server version** — kubeconfig points at the wrong context, or the agent pods aren't\n  `Running` yet. Run `kubectl config get-contexts` to identify the cluster with the agent, switch to it with\n  `kubectl config use-context <context-with-the-agent>`, and re-check `kubectl get pods -n testkube`.\n- **Expecting a dashboard** — standalone/OSS mode has none. The dashboard ships with the Testkube Control Plane, a\n  separate install (see https://docs.testkube.io/articles/install/overview).\n"
}

SHA-256: 7bf25b647d261e7da3b1d50a999aa5d5a5e083e4f9b20917dba6532c3125b3c9