Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 12 additions & 13 deletions src/pages/docs/agent/soft-and-permanent-deletion-of-agents.md
Original file line number Diff line number Diff line change
Expand Up @@ -36,32 +36,31 @@ Managing a long list of Agents can make selecting the right Agent while executin
## **Steps to Soft Delete an Agent**

1. From the dashboard, go to **Agents**.
![Agents](https://s3.amazonaws.com/static-docs.testsigma.com/new_images/projects/agents/update_agents_1.png)

2. Hover over the agent you want to soft delete (push to an obsolete state).
2. Click the ellipsis icon against an agent that you want to delete and click **Obsolete**.
![obsolete](https://s3.amazonaws.com/static-docs.testsigma.com/new_images/projects/agents/update_agents_2.png)

3. In the warning dialog, click **Obsolete Agent**.
3. In the **Obsolete agent?** dialog, click **Obsolete Agent**.
![Obsolete Agent](https://s3.amazonaws.com/static-docs.testsigma.com/new_images/projects/agents/update_agents_3.png)

4. The agent will move to the obsolete state.

[[info | **NOTE**:]]
| - You can restore an obsolete agent by navigating to **Agents > Obsolete Agent** and clicking Restore.
| - To restore an obsolete agent, click **Restore** next to the agent you want to reactivate. ![Restore](https://s3.amazonaws.com/static-docs.testsigma.com/new_images/projects/agents/update_agents_4.png)
| - An agent in the obsolete state will not allow the user to execute tests.


Here’s a quick GIF demonstrating how to soft delete and restore the obsoleted agent.

![Soft Delete Agents](https://s3.amazonaws.com/static-docs.testsigma.com/new_images/projects/applications/SoftDeleteAgent.gif)

---

## **Steps to Delete Agents Permanently**

1. Navigate from the dashboard to **Agents > Obsolete Agent**.

2. Click on the kebab menu and select **Delete Permanently**. This will open a warning dialog.
1. From the dashboard, go to **Agents**.
![Agents](https://s3.amazonaws.com/static-docs.testsigma.com/new_images/projects/agents/update_agents_1.png)

3. In the warning dialog, confirm deletion by clicking **Delete Permanently**.
2. Click the ellipsis icon against the agent and click **Delete Permanently**.
![Delete](https://s3.amazonaws.com/static-docs.testsigma.com/new_images/projects/agents/update_agents_5.png)

![Delete Permanently](https://s3.amazonaws.com/static-docs.testsigma.com/new_images/projects/applications/DeleteAgentsPermanently.gif)
3. In the **Delete Agent Permanently?** dialog, click **Delete Permanently**.
![Delete Permanently](https://s3.amazonaws.com/static-docs.testsigma.com/new_images/projects/agents/update_agents_6.png)

---
32 changes: 16 additions & 16 deletions src/pages/docs/testsigma-tunnel/setup-installation-kubernetes.md
Original file line number Diff line number Diff line change
Expand Up @@ -258,21 +258,21 @@ Deployments:
version: amd64-latest
imagePullPolicy: Always
config:
key: "<YOUR_TUNNEL_JWT_KEY>" # JWT key from the Testsigma dashboard
key: "<YOUR_TUNNEL_API_KEY>" # API key from the Testsigma dashboard
tunnelName: "my-tunnel" # Name that appears in the Testsigma UI
verbose: true # Enable verbose logging
delegateSslValidation: false # Set true to skip SSL certificate validation
proxy: "" # HTTP proxy URL (leave empty if not required)
```

Replace the following placeholder values in your file:
- **\<YOUR\_TUNNEL\_JWT\_KEY\>**: Enter the JWT key from **Settings > Tunnels** in the Testsigma application.
- **\<YOUR\_TUNNEL\_API\_KEY\>**: Enter the API key from **Settings > Tunnels** in the Testsigma application.
- **tunnel-client-mycompany**: Enter a name that uniquely identifies this tunnel client in your cluster.
- **my-namespace**: Enter the Kubernetes namespace where you want to deploy the tunnel.
- **my-tunnel**: Enter the tunnel name that will appear in the Testsigma UI.

[[info | Note:]]
| Never store your JWT key in plain text in a values file that you commit to version control. See **Manage Secrets** for recommended alternatives.
| Never store your API key in plain text in a values file that you commit to version control. See **Manage Secrets** for recommended alternatives.

---

Expand Down Expand Up @@ -332,7 +332,7 @@ In the logs, look for a message confirming that the tunnel registered successful
| **containers.image** | string | Yes | — | Docker image name for the tunnel client. |
| **containers.version** | string | Yes | — | Docker image tag. |
| **containers.imagePullPolicy** | string | Yes | — | Image pull policy. Accepted values: **Always**, **IfNotPresent**, or **Never**. |
| **config.key** | string | Yes | — | JWT authentication key from the Testsigma dashboard. |
| **config.key** | string | Yes | — | API key from the Testsigma dashboard. |
| **config.tunnelName** | string | Yes | — | Tunnel name visible in the Testsigma UI. |
| **config.verbose** | boolean | No | true | Enables verbose logging for the tunnel client. |
| **config.delegateSslValidation** | boolean | No | false | When **true**, the tunnel skips SSL certificate validation for upstream requests. |
Expand All @@ -357,11 +357,11 @@ Namespace:

## **Manage Secrets**

The **config.key** field contains a JWT authentication token. Treat this value as a secret and never commit it in plain text to version control.
The **config.key** field contains an API key. Treat this value as a secret and never commit it in plain text to version control.

### **Option 1: Pass the Key at Deploy Time**

Use the **--set** flag with `helm install` or `helm upgrade` to inject the JWT key without storing it in your values file:
Use the **--set** flag with `helm install` or `helm upgrade` to inject the API key without storing it in your values file:

```bash
helm install my-tunnel . -f my-values.yaml \
Expand All @@ -380,28 +380,28 @@ helm install my-tunnel . -f my-values.yaml \

### **Option 2: Use a Secrets Manager**

For GitOps workflows, use Sealed Secrets or External Secrets Operator to manage the JWT key:
For GitOps workflows, use Sealed Secrets or External Secrets Operator to manage the API key:

1. Store the JWT key in your secrets backend (for example, AWS Secrets Manager or HashiCorp Vault).
1. Store the API key in your secrets backend (for example, AWS Secrets Manager or HashiCorp Vault).
2. Create an ExternalSecret resource that syncs the key into a Kubernetes Secret.
3. Reference the secret in your values file or inject it with **--set** in your CI/CD pipeline.

### **Option 3: Use CI/CD Pipeline Variables**

Store the JWT key as a pipeline secret and inject it during deployment. The following example shows a GitHub Actions workflow step:
Store the API key as a pipeline secret and inject it during deployment. The following example shows a GitHub Actions workflow step:

```yaml
- name: Deploy tunnel
run: |
helm upgrade --install my-tunnel ./testsigma-tunnel \
-f my-values.yaml \
--set "Deployments.myTunnel.config.key=${{ secrets.TUNNEL_JWT_KEY }}" \
--set "Deployments.myTunnel.config.key=${{ secrets.TUNNEL_API_KEY }}" \
-n my-namespace
```

### **Rotate a JWT Key**
### **Rotate an API Key**

When a JWT key expires or needs to be replaced:
When an API key expires or needs to be replaced:

1. Obtain a new key from **Settings > Tunnels** in the Testsigma application.
2. Update the key using your chosen secret management method.
Expand Down Expand Up @@ -554,7 +554,7 @@ Deployments:
version: amd64-latest
imagePullPolicy: Always
config:
key: "<JWT_KEY_FOR_SITE_A>"
key: "<API_KEY_FOR_SITE_A>"
tunnelName: "site-a-tunnel"
verbose: true
siteB:
Expand All @@ -566,7 +566,7 @@ Deployments:
version: amd64-latest
imagePullPolicy: Always
config:
key: "<JWT_KEY_FOR_SITE_B>"
key: "<API_KEY_FOR_SITE_B>"
tunnelName: "site-b-tunnel"
verbose: true
```
Expand Down Expand Up @@ -609,8 +609,8 @@ config:
| Symptom | Possible Cause | Resolution |
|---|---|---|
| Pod stuck in **Pending** | No nodes match the **pool-type** selector. | Run `kubectl get nodes --show-labels` and verify that at least one node has the expected **pool-type** label. |
| Pod in **CrashLoopBackOff** | Invalid JWT key or malformed tunnel configuration. | Run `kubectl logs <pod-name> -n my-namespace` to inspect the error output. Verify that **config.key** and **config.tunnelName** are correct. |
| Tunnel not visible in Testsigma UI | Incorrect **tunnelName** value or expired JWT key. | Confirm that **config.tunnelName** matches what you expect to see in the UI. Obtain a fresh JWT key from **Settings > Tunnels** if the key has expired. |
| Pod in **CrashLoopBackOff** | Invalid API key or malformed tunnel configuration. | Run `kubectl logs <pod-name> -n my-namespace` to inspect the error output. Verify that **config.key** and **config.tunnelName** are correct. |
| Tunnel not visible in Testsigma UI | Incorrect **tunnelName** value or expired API key. | Confirm that **config.tunnelName** matches what you expect to see in the UI. Obtain a fresh API key from **Settings > Tunnels** if the key has expired. |
| Connection timeouts during testing | Network policy or proxy misconfiguration. | Verify that **config.proxy** is set correctly and that cluster network policies permit outbound connections to the Testsigma platform. |
| SSL errors during test execution | The upstream application uses a self-signed certificate. | Set **config.delegateSslValidation: true** in your values file and run `helm upgrade` to apply the change. |

Expand Down
Loading