### Install Signadot Operator and HotROD App (Istio)

Source: https://www.signadot.com/docs/tutorials/quickstart/first-sandbox

Installs the Signadot Operator and the HotROD demo application with Istio mesh in the 'hotrod' namespace. This is the first step for setting up the environment on a self-hosted Kubernetes cluster.

```shell
kubectl create ns hotrod --dry-run=client -o yaml | kubectl apply -f - 
kubectl -n hotrod apply -k 'https://github.com/signadot/hotrod/k8s/overlays/prod/istio'
```

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

### Install Signadot CLI via Script

Source: https://www.signadot.com/docs/getting-started/installation/signadot-cli

Installs the Signadot CLI by downloading and executing an installation script. This method works on both macOS and Linux.

```bash
$curl -sSLf https://raw.githubusercontent.com/signadot/cli/main/scripts/install.sh | sh
Downloading signadot-cli...
Installing signadot-cli to /usr/local/bin...
Installation complete!
```

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

### ResourcePlugin Specification Example

Source: https://www.signadot.com/docs/reference/resource-plugins/spec

A comprehensive example of a ResourcePlugin specification in YAML format. It includes metadata, description, runner configuration, and definitions for 'create' and 'delete' phases with script execution.

```yaml
name: hello-db  
spec:  
  description: say hello and goodbye  
  runner:  
    image: ubuntu  
  create:  
  - name: say-hello  
    inputs:  
    - name: dbname  
      valueFromSandbox: true  
      as:  
        env: DBNAME  
    script: |  
      #!/usr/bin/env bash  
      echo hello $DBNAME  
delete:  
  - name: say-goodbye  
    script: |  
    #!/usr/bin/env bash  
    echo goodbye  


```

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

### Install Signadot Operator and HotROD App (Linkerd/No Mesh)

Source: https://www.signadot.com/docs/tutorials/quickstart/first-sandbox

Installs the Signadot Operator and the HotROD demo application without a service mesh (or with Linkerd) in the 'hotrod' namespace. This is an alternative setup for self-hosted Kubernetes clusters.

```shell
kubectl create ns hotrod --dry-run=client -o yaml | kubectl apply -f - 
kubectl -n hotrod apply -k 'https://github.com/signadot/hotrod/k8s/overlays/prod/devmesh'
```

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

### Bitbucket Pipeline for Signadot Sandbox (YAML)

Source: https://www.signadot.com/docs/guides/integrate-ci/bitbucket

An example Bitbucket pipeline configuration in YAML format that automates the process of setting up Signadot environment variables, installing the Signadot CLI, applying a sandbox specification, submitting jobs, and optionally deleting the sandbox.

```yaml
image: atlassian/default-image:4  
  
pipelines:  
  default:  
    - step:  
        name: Run Tests  
        script:  
          - |  
            # Set up env vars  
            export SIGNADOT_CLUSTER=demo  
            export IMAGE_TAG="${BITBUCKET_COMMIT}"  
            # Define the sandbox name using a short version of the gitsha to respect the  
            # limit (30 chars)  
            export SANDBOX_NAME="my-svc-${BITBUCKET_COMMIT:0:6}"  
  
            # Set up Signadot CLI  
            apt update; apt install -y jq  
            curl -sSLf https://raw.githubusercontent.com/signadot/cli/main/scripts/install.sh | sh  
  
            # Create a sandbox  
            echo "Creating sandbox ${SANDBOX_NAME}..."  
            signadot sandbox apply \  
              --set name=${SANDBOX_NAME} \  
              --set image=docker-user/repo:${IMAGE_TAG} \  
              --set cluster=${SIGNADOT_CLUSTER} \  
              -f - \  
              < ${BITBUCKET_CLONE_DIR}/.signadot/my-svc-template.yaml  
  
            # Optionally run automated tests using jobs  
            echo "Running automated tests..."  
            signadot job submit --attach -f \  
              --set branch=... \  
              -f - \  
              < ${GITHUB_WORKSPACE}/.signadot/job.yaml  
  
            # Optionally delete the sandbox if only running automated tests  
            # else you may omit this and delete on PR close / using TTL  
            echo "Deleting sandbox..."  
            signadot sandbox delete ${SANDBOX_NAME}  
```

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

### Custom Configuration Installation for Signadot Operator

Source: https://www.signadot.com/docs/installation/signadot-operator

Installs the Signadot Operator with custom configuration parameters specified via command-line flags. This example demonstrates setting common labels for customization. Alternatively, a `values.yaml` file can be used.

```bash
helm install signadot-operator signadot/operator \
$ --set 'commonLabels.some-label=value1' \
$ --set 'commonLabels.other-label=value2'
NAME: signadot-operator
LAST DEPLOYED: XXX XXX XX XX:XX:XX XXXX
NAMESPACE: signadot
STATUS: deployed
REVISION: 1
```

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

### Example Trigger Configuration

Source: https://www.signadot.com/docs/reference/smart-tests/spec

This example demonstrates how to configure a trigger for hosted tests in Signadot. It specifies the cluster and workload that will initiate the test execution when a sandbox is created or updated.

```text
cluster: "cluster-1"
workload: "location"
namespace: "hotrod-istio"
```

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

### Signadot CLI Connect to Cluster

Source: https://www.signadot.com/docs/tutorials/quickstart/first-sandbox

Establishes a connection to your Kubernetes cluster using the Signadot CLI, based on the configuration in `~/.signadot/config.yaml`.

```shell
signadot local connect
```

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

### Sandbox Spec Example with Resource Plugin

Source: https://www.signadot.com/docs/reference/resource-plugins/spec

An example of a sandbox specification that defines resources to be made available using a resource plugin. It shows how to specify the plugin name and parameters.

```yaml
spec:  
  resource:  
  - name: testdb  
    plugin: mariadb  
    params:  
    - dbname: test  


```

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

### Example Label Structure for SmartTests

Source: https://www.signadot.com/docs/guides/smart-tests/smart-tests-git

This example demonstrates a structured approach to defining labels for Signadot SmartTests. Comprehensive labeling helps in organizing tests, enabling future selection capabilities, and providing metadata for tracking, filtering, and grouping test runs. Labels can include service identification, team ownership, criticality, and test categories.

```yaml
# Example label structure  
service: payment-service  
type: provider          # provider/consumer  
team: platform  
criticality: high  
owner: platform@company.com  

```

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

### Install Signadot CLI via Homebrew

Source: https://www.signadot.com/docs/getting-started/installation/signadot-cli

Installs the Signadot CLI using Homebrew package manager on macOS or Linux. Ensure Homebrew is installed before running these commands.

```bash
$brew tap signadot/tap
Tapped 1 formula.
$brew install signadot-cli
==> Downloading https://github.com/signadot/cli/releases/download/vX.X.X/signadot-cli_X.X.X_darwin_amd64.tar.gz
==> Installing signadot-cli
🍺 /opt/homebrew/Cellar/signadot-cli/X.X.X: X files, X.XMB
```

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

### Start Local Proxy for Internal Services (Signadot CLI)

Source: https://www.signadot.com/docs/guides/use-cases/run-automated-tests-ci

This command starts the Signadot local proxy, which is useful for accessing internal services not directly exposed from your CI environment. It maps a local port to an internal service and automatically injects necessary routing headers for sandbox access. This is particularly helpful for testing services within a Kubernetes cluster.

```shell
# Start proxy for specific sandbox
signadot local proxy --sandbox <sandbox-name> \
  --map http://internal-service.namespace.svc:8000@localhost:8001
```

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

### Example Signadot Job Specification

Source: https://www.signadot.com/docs/reference/jobs/spec

An example of a complete Signadot Job specification, demonstrating the arrangement of various fields to define a job's execution context, script, artifact uploads, and routing.

```YAML
spec:
  namePrefix: my-job
  runnerGroup: my-runner-group
  labels:
    my-custom-label: foo
    env: bar
  script: |
    #!/bin/sh
    echo hello > /tmp/my-artifact.txt
  uploadArtifact:
  - path: /tmp/my-artifact.txt
  routingContext:
    sandbox: my-sandbox
  trafficManager:
    injectRoutingKey: auto

```

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

### Job Phase Counts Example

Source: https://www.signadot.com/docs/reference/sandboxes/status

Demonstrates the phase counts for jobs associated with a sandbox. This example lists the number of jobs in various states such as 'queued', 'running', 'failed', and 'succeeded'.

```yaml
jobs:
  phaseCounts:
    - count: 1
      phase: queued
    - count: 1
      phase: running
    - phase: failed
    - count: 4
      phase: succeeded
    - phase: canceled

```

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

### Example Sandbox Specification YAML

Source: https://www.signadot.com/docs/guides/integrate-ci/github

A YAML template file stored in the git repository (e.g., .signadot/<service-name>-template.yaml) used to define sandbox configurations for services. This example sets up a sandbox for a single service named 'my-svc'.

```yaml
name: "@{name}"  
spec:  
  cluster: "@{cluster}"  
  forks:  
  - forkOf:  
      kind: Deployment  
      namespace: default  
      name: my-svc  
    customizations:  
      images:  
      - image: "@{image}"
```

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

### Signadot Sandbox Specification Example (JSON)

Source: https://www.signadot.com/docs/reference/sandboxes/spec

This snippet illustrates the structure of a Signadot Sandbox specification using JSON format. It mirrors the YAML example, showcasing how to define sandboxed workloads, routing, and other configuration aspects programmatically.

```json
{
  "name": "my-sandbox",
  "spec": {
    "labels": {
      "dev": "jane"
    },
    "cluster": "my-cluster",
    "description": "Testing sandboxes",
    "forks": [
      {
        "forkOf": {
          "kind": "Deployment",
          "namespace": "example",
          "name": "my-app"
        },
        "customizations": {
          "images": [
            {
              "image": "example.com/my-app:dev-abcdef"
            }
          ],
          "env": [
            {
              "name": "EXTRA_ENV",
              "value": "foo"
            }
          ]
        }
      }
    ],
    "defaultRouteGroup": {
      "endpoints": [
        {
          "name": "my-endpoint",
          "target": "http://my-app.example.svc:8080"
        }
      ]
    }
  }
}

```

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

### Signadot Routing Headers Example

Source: https://www.signadot.com/docs/guides/developer-environments/access-sandboxes

These are example headers automatically injected by the Signadot Chrome Extension to route traffic to sandbox environments. These headers are essential for directing requests to the correct isolated sandbox.

```text
baggage: sd-routing-key=vf0ju8vw50wpu

```

```text
ot-baggage-sd-routing-key: vf0ju8vw50wpu

```

```text
tracestate: sd-routing-key=vf0ju8vw50wpu

```

```text
uberctx-sd-routing-key: vf0ju8vw50wpu

```

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

### Install HotROD Application with Istio

Source: https://www.signadot.com/docs/tutorials/quickstart/smart-tests

Installs the HotROD demo application into the 'hotrod' namespace using Istio as the service mesh. This command applies Kubernetes resources defined in a kustomization file.

```bash
kubectl create ns hotrod --dry-run=client -o yaml | kubectl apply -f -
kubectl -n hotrod apply -k 'https://github.com/signadot/hotrod/k8s/overlays/prod/istio'
```

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

### Signadot CLI Authentication

Source: https://www.signadot.com/docs/tutorials/quickstart/first-sandbox

Logs in to your Signadot account using the Signadot CLI. This is a prerequisite for connecting to your cluster and managing sandboxes.

```shell
signadot auth login
```

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

### Traffic Diffs Summary Example

Source: https://www.signadot.com/docs/reference/sandboxes/status

Provides an example of the traffic diffs summary in a sandbox status. This shows the counts of 'green' and 'yellow' traffic differences, indicating expected and intermediate differences from the baseline.

```yaml
trafficDiffs:
  green: 24
  yellow: 7

```

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

### Install HotROD Application with Linkerd / No Mesh

Source: https://www.signadot.com/docs/tutorials/quickstart/smart-tests

Installs the HotROD demo application into the 'hotrod' namespace using a no-mesh or Linkerd configuration. This command applies Kubernetes resources defined in a kustomization file.

```bash
kubectl create ns hotrod --dry-run=client -o yaml | kubectl apply -f -
kubectl -n hotrod apply -k 'https://github.com/signadot/hotrod/k8s/overlays/prod/devmesh'
```

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

### Apply Sandbox Template with CLI - Signadot CLI

Source: https://www.signadot.com/docs/guides/set-up-pr-sandboxes

Applies a reusable sandbox template using the Signadot CLI, populating template variables with provided values. This command demonstrates how to set namespace, service, and image parameters for dynamic sandbox instantiation.

```bash
signadot sandbox apply -f ./my-sbx-template.yaml \ 
    --set namespace=hotrod \ 
    --set service=route \ 
    --set image=repo/image:abcdef  
    ...   

```

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

### CI Pipeline Integration for Sandbox Testing (Signadot CLI)

Source: https://www.signadot.com/docs/guides/use-cases/run-automated-tests-ci

This example illustrates a typical CI pipeline stage for integrating sandbox testing. It includes steps to apply a sandbox, export the routing key, run automated tests, and finally delete the sandbox to clean up resources. This ensures that tests are run against a dedicated, isolated environment.

```yaml
# Example CI pipeline stage
test_stage:
  script:
    # 1. Create sandbox
    - sandbox_id=$(signadot sandbox apply -f .signadot/sandbox.yaml)
      
    # 2. Export routing information
    - export SIGNADOT_ROUTING_KEY=$(signadot sandbox get $sandbox_id -o json | jq -r .routingKey)
      
    # 3. Run tests
    - ./run-tests.sh
      
    # 4. Cleanup
    - signadot sandbox delete $sandbox_id
```

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

### Response Time Check Example - Signadot Synthetic API Test

Source: https://www.signadot.com/docs/guides/use-cases/run-synthetic-tests

This Python example shows how to measure and validate API response times within Signadot synthetic tests. It records the time before and after an HTTP GET request and checks if the duration exceeds a specified threshold (500ms). `capture=True` is included for breaking change analysis.

```python
# Measure response time  
start = time.now()  
res = http.get(  
    url="https://httpbin.org/get", # can also be cluster internal URLs like http://name.namespace.svc  
    capture=True,  
    name="latencyCheck"  
)  
end = time.now()  
  
# Check if response time is under 500ms  
ck = smart_test.check("response-time")  
if end - start > 500 * time.millisecond:  
    ck.error("Response took too long: {} ms", (end - start) / time.millisecond)  

```

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

### Get Sandbox Status (YAML)

Source: https://www.signadot.com/docs/reference/sandboxes/status

Example of retrieving Signadot Sandbox status in YAML format using the CLI. This output shows details like readiness, scheduled deletion time, and test execution summaries.

```shell
# signadot sb get my-sandbox -o yaml | yq .status
local: []
message: All desired workloads are available.
ready: true
reason: AllDesiredWorkloadsReady
scheduledDeleteTime: 2025-01-31T00:42:08Z
testExecutions:
  checks:
    failed: 1
    passed: 2
  phaseCounts:
    - phase: pending
    - phase: in_progress
    - phase: failed
    - count: 3
      phase: succeeded
    - phase: canceled
  trafficDiffs:
    green: 24
    yellow: 7

```

```shell
# signadot sb get my-local-sandbox -o yaml | yq.status
local:
  - name: local-location
    tunnel:
      health:
        connected: true
        lastCheckTime: 2025-01-30T23:25:57Z
        lastConnectedTime: 2025-01-30T23:25:57Z
message: All desired workloads are available.
ready: true
reason: AllDesiredWorkloadsReady
scheduledDeleteTime: 2025-01-31T07:20:54Z

```

```shell
# signadot sb get my-sandbox -o yaml | yq .status
jobs:
  phaseCounts:
    - count: 1
      phase: queued
    - count: 1
      phase: running
    - phase: failed
    - count: 4
      phase: succeeded
    - phase: canceled
message: All desired workloads are available.
ready: true
reason: AllDesiredWorkloadsReady

```

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

### Write a SmartTest - Starlark

Source: https://www.signadot.com/docs/guides/smart-tests/smart-tests-git

This example demonstrates writing a SmartTest using Starlark to validate external API behavior. It uses the `http` module to make a GET request and `smart_test.check` to assert the status code.

```starlark
# smart-tests/frontend/api.star
# Test external API behavior (using httpbin.org as example)

def test_get_api():
    res = http.get(
        url="https://httpbin.org/get",
        capture=True,
        name="getExample"
    )

    ck = smart_test.check("api-behavior")
    if res.status_code != 200:
        ck.error("expected 200 status code, got {}", res.status_code)

```

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

### Signadot Sandbox: Frontend Highlighting Feature

Source: https://www.signadot.com/docs/tutorials/quickstart/first-sandbox

Defines a Signadot sandbox environment to test a frontend feature that adds plate number highlighting to the UI. It forks the 'frontend' deployment and applies a new image.

```yaml
name: frontend-highlight
spec:
  description: Add plate number highlighting in UI
  cluster: "@{cluster}"
  labels:
    feature: hotrod-plates
  forks:
    - forkOf:
        kind: Deployment
        namespace: hotrod
        name: frontend
      customizations:
        images:
          - image: signadot/hotrod:97de62bf5a6d91482f62db23de565282ff97e60d-linux-amd64
            container: hotrod
```

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

### Define Sandbox Infrastructure - Signadot YAML

Source: https://www.signadot.com/docs/guides/set-up-pr-sandboxes

Specifies the test workloads and routing configuration for a Signadot sandbox. This example defines a sandbox for the 'route' microservice, specifying its cluster, description, labels, TTL, and a fork of a 'Deployment' resource with a new image.

```yaml
name: route-sbx  
spec:  
  cluster: my-cluster  # name of cluster (as per app.signadot.com)  
  description: sandbox for route microservice  
  labels:  
    team: route-team  
    # ...any other metadata  
  ttl:  
    duration: 1d  
  forks:
  - forkOf:  
      kind: Deployment     # With respect to the baseline environment, this   
      namespace: hotrod    # forks (clones & customizes) route only.   
      name: route        
    customizations:  
      images:                         
      - image: repo/image:abcdef    # new version of the image  

```

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

### Create Base Docker Image for Signadot Testing

Source: https://www.signadot.com/docs/guides/testing-frameworks/custom-test

A Dockerfile defining a base image for Signadot testing environments. It starts from an Ubuntu base, installs essential tools like git and wget, and cleans up apt caches. This image can be extended to include specific testing dependencies.

```dockerfile
# You can even use a lighter image, but make sure you have all deps you need
FROM ubuntu:latest

ENV HOME /root
WORKDIR $HOME

# Install basic tools
RUN apt-get update && \
    apt-get install -y git wget && \
    apt-get clean autoclean && \
    rm -rf /var/lib/{apt,dpkg,cache,log}/

# Do more stuff ....

```

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

### Directory Structure for Infrastructure Code - File Paths

Source: https://www.signadot.com/docs/guides/use-cases/run-automated-tests

Example of organizing infrastructure configuration files within a project's directory structure, separating different types of job templates.

```file-paths
- signadot/  
  ├── job-integration-routeservice-mocha.yaml  
  └── job-e2e-routeservice-cypress.yaml  
```

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

### Example Signadot Sandbox with MariaDB Resource

Source: https://www.signadot.com/docs/reference/sandboxes/resources

This YAML configuration demonstrates how to define a Signadot sandbox that requests a MariaDB resource. It shows how to specify the resource plugin, input parameters like 'dbname', and how to access resource outputs (host, port, password) as environment variables for a forked workload.

```yaml
# customer-sandbox.yaml  
# usage: signadot sandbox apply -f customer-sandbox.yaml  
name: customer  
spec:  
  cluster: ...  
  resources:  
  - name: customerdb  
    plugin: hotrod-mariadb  
    params:  
      dbname: customer  
  forks:  
    forkOf:  
      kind: Deployment  
      namespace: hotrod  
      name: customer  
    customizations:  
      env:  
      - name: MYSQL_HOST  # set MYSQL_HOST to that provided by the plugin  
        valueFrom:  
          resource:  
            name: customerdb  
            outputKey: provision.host  
      - name: MYSQL_PORT  
        valueFrom:  
          resource:  
            name: provision.customerdb  
            outputKey: port  
      - name: MYSQL_ROOT_PASSWORD  
        valueFrom:  
          resource:  
            name: customerdb  
            outputKey: provision.root-password  

```

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

### Match Sandbox by Label Key-Value Pair

Source: https://www.signadot.com/docs/reference/route-groups/sandbox-matching

This example demonstrates how to match a Sandbox based on a specific label's key and a glob pattern for its value. The RouteGroup configuration specifies a label key 'feature' and a value glob 'x-*'. A Sandbox matches if it has a label with the key 'feature' and its value starts with 'x-'. This is useful for routing to specific feature branches.

```yaml
# routegroup  
spec:  
  cluster: staging  
  match:  
    label:              # checks whether there exists a label such that ...  
      key: feature      # key is equal to 'feature' (this is not a glob); and  
      value: x-*        # key matches the glob 'x-*'  
---
# matching sandbox  
spec:  
  cluster: staging  
  labels:  
    team: plumbing      # it doesn't matter if there are other labels  
    feature: x-backend  # matches because key is 'feature' and value matches glob 'x-*'  
---
# non-matching sandbox  
spec:  
  cluster: staging  
  labels:  
    team: plumbing  
  forks: ...  

```

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

### Health Check Example - Signadot Synthetic API Test

Source: https://www.signadot.com/docs/guides/use-cases/run-synthetic-tests

This Python snippet demonstrates a basic API health check using Signadot's synthetic testing capabilities. It performs an HTTP GET request and checks if the response status code is 200. The `capture=True` parameter enables automatic analysis of API responses for breaking changes.

```python
res = http.get(  
    url="https://httpbin.org/get", # can also be cluster internal URLs like http://name.namespace.svc  
    capture=True,  
    name="apiHealth"  
)  
  
ck = smart_test.check("api-health")  
if res.status_code != 200:  
    ck.error("Health check failed with status: {}", res.status_code)  

```

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

### Apply Signadot Sandbox Configuration

Source: https://www.signadot.com/docs/tutorials/quickstart/first-sandbox

Applies a Signadot sandbox configuration from a local YAML file. The --set flag allows overriding parameters like the cluster name. This command is used to deploy isolated testing environments for specific features.

```bash
signadot sandbox apply -f ./frontend-highlight.yaml --set cluster=<cluster>
```

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

### Install Signadot Operator using Helm

Source: https://www.signadot.com/docs/installation/signadot-operator

Installs the Signadot Operator into a Kubernetes cluster using Helm. It requires a cluster token obtained from the Signadot Dashboard for authentication. This snippet first creates a dedicated namespace and adds the Signadot Helm repository before performing the installation.

```bash
kubectl create ns signadot
namespace/signadot created
helm repo add signadot https://charts.signadot.com
"signadot" has been added to your repositories
helm install signadot-operator signadot/operator --set agent.clusterToken='<cluster-token>'
NAME: signadot-operator
LAST DEPLOYED: XXX XXX XX XX:XX:XX XXXX
NAMESPACE: signadot
STATUS: deployed
REVISION: 1
```

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

### Apply Signadot Route Group Configuration

Source: https://www.signadot.com/docs/tutorials/quickstart/first-sandbox

Applies a Signadot route group configuration from a local YAML file. This command registers the route group, generating a unique routing key that can be used to direct traffic to all associated sandboxes.

```bash
% signadot routegroup apply -f ./plates-routegroup.yaml --set cluster=<cluster>
```

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

### Submit Job using Template - CLI

Source: https://www.signadot.com/docs/guides/use-cases/run-automated-tests

Command to execute a job using a defined template, allowing dynamic setting of parameters like branch and sandbox, and attaching logs for debugging.

```bash
signadot job submit -f ./job-template.yaml --set branch=main --set sandbox=my-sandbox --attach  
```

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

### Helm Installation Command

Source: https://www.signadot.com/docs/installation/signadot-operator

This command installs the Signadot operator using Helm, applying common labels defined in a values file. It's a standard method for deploying the operator.

```bash
$helm install signadot-operator signadot/operator -f values.yaml
```

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

### Retrieve Files for Local Workloads

Source: https://www.signadot.com/docs/guides/use-cases/set-up-local-testing

Fetches files, such as configuration files, associated with a specified sandbox. It lists the directory structure and indicates the source of each file (e.g., ConfigMap). The files are populated in a local directory for use by the local application.

```bash
% signadot sandbox get-files jane-hotrod  
/Users/jane/.signadot/sandboxes/jane-hotrod/local/files  
└── app-config.yaml  
    └── debug                                           # configMap: app-config.yaml[debug]  
```

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

### Run SmartTests using CLI - Bash

Source: https://www.signadot.com/docs/guides/smart-tests/smart-tests-git

These commands demonstrate how to run SmartTests using the Signadot CLI. The first command runs tests against a staging cluster, while the second runs tests against a sandbox and publishes the results.

```bash
# Test against baseline
signadot smart-test run --cluster=staging

# Test against a sandbox and publish results
signadot smart-test run --sandbox=my-sandbox --publish

```

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

### Configure Baggage Header for Sandbox Routing

Source: https://www.signadot.com/docs/tutorials/quickstart/first-sandbox

Demonstrates setting the 'baggage' header with a routing key, which is essential for directing traffic to a specific Signadot sandbox. This can be done via browser extensions or programmatically.

```yaml
baggage: sd-routing-key=<routing-key>
```

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

### YAML Templating: Raw Expansion Encoding Example

Source: https://www.signadot.com/docs/reference/cli/templates

Shows the 'raw' expansion encoding for variables, which performs simple string interpolation. The example demonstrates combining multiple variables into a single string.

```yaml
# both dev and team are expanded with the raw expansion encoding,
# which is just string interpolation.
name: "@{dev[raw]}-@{team}"
---
# output
name: "jane-plumbers"
```

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

### RouteGroup Multi-Cluster Endpoint Example (YAML/JSON)

Source: https://www.signadot.com/docs/reference/route-groups/spec

Example of an endpoint definition for multi-cluster RouteGroups, including a 'cluster' field to specify the target cluster. This is used when routing requests across different Kubernetes clusters.

```yaml
- name: my-endpoint
  target: http://my-svc.namespace.svc:8080
  cluster: staging

```

```json
{
  "name": "my-endpoint",
  "target": "http://my-svc.namespace.svc:8080",
  "cluster": "staging"
}

```

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

### GitHub Actions Workflow for Signadot SmartTests

Source: https://www.signadot.com/docs/guides/smart-tests/smart-tests-git

This GitHub Actions workflow automates the integration of Signadot SmartTests into a CI/CD pipeline. It sets up the Signadot CLI, creates a unique sandbox environment for each pull request, and runs SmartTests with dynamic labels. The workflow requires Signadot organization and API key secrets to be configured.

```yaml
jobs:
  smart-tests:
    runs-on: ubuntu-latest
    env:
      SIGNADOT_ORG: ${{ secrets.SIGNADOT_ORG }}
      SIGNADOT_API_KEY: ${{ secrets.SIGNADOT_API_KEY }}
      SANDBOX_NAME: pr-${{ github.event.number }}-test
    steps:
      # ... other steps       
      - name: Set up Signadot CLI
        run: |
          curl -sSLf https://raw.githubusercontent.com/signadot/cli/main/scripts/install.sh | sh  

      - name: Create Sandbox
        run: |
          signadot sandbox apply \
            --set name=${SANDBOX_NAME} \
            --set github-pr=${{ github.event.number }} \
            --set image=myrepo/image:${{ github.sha }} \
            -f .signadot/sandbox-template.yaml  

      - name: Run SmartTests
        run: |
          signadot st run \
            --sandbox=${SANDBOX_NAME} \
            --set-label foo=bar \
            --publish  

```

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

### Signadot CLI Help Command

Source: https://www.signadot.com/docs/reference/cli/overview

This command displays general help information for the Signadot CLI. It serves as an entry point to understanding available commands and their structure.

```bash
signadot help
```

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

### Step Input Configuration with Environment Variable and File Output

Source: https://www.signadot.com/docs/reference/resource-plugins/overview

Demonstrates how to configure inputs for a step within a Resource Plugin's 'create' workflow. Inputs can be sourced from the sandbox specification and exposed to the step's script either as environment variables or files.

```yaml
spec:
  runner:
    ...
  create:
    - name: hello
      inputs:
      - name: ...
        valueFromSandbox: true
        as:
          env: ENV_VAR_NAME
          path: /path/to/file
      ...

      script: |
        #!/usr/bin/env bash
         echo $ENV_VAR_NAME
        ...

```