---
name: dataflow-service-e2e
description: Run or troubleshoot e2e tests for tidbcloud/dataflow-service. Use when the user asks to execute, parameterize, rerun, or understand `make run-e2e`, `.github/workflows/e2e-test.yaml`, or the Go e2e harness under `test/e2e`. Covers both GitHub Actions workflow-dispatch runs and local `test/e2e` execution, including domain/env/case_group/cases/org/project/cluster selection.
---

# Dataflow Service E2E

Use this skill for `tidbcloud/dataflow-service` e2e work.

## Repo location

Business repos should live in the current agent workspace. Default repo path for this skill:

- `/home/openclaw/.openclaw/workspace-defaults/repos/dataflow-service`

Use the `tidbcloud-github-access` skill for GitHub authentication and `tidbcloud/*` repo access rules.

## Two execution modes

### 1) Preferred: dispatch the GitHub Actions workflow

This mirrors root `make run-e2e` behavior and is the standard way to execute org-managed e2e.

Use bundled script:

- `scripts/run-e2e-gh.sh`

Required input:

- `AUTH_TOKEN`: TiDB Cloud bearer token **without** the `Bearer ` prefix

Useful env vars:

- `BRANCH` default `master`
- `DOMAIN` default `cdc` (`cdc` or `br`)
- `TEST_ENV` default `dev` (`dev`, `staging`, `prod`)
- `CASE_GROUP` default `smoke`
- `CASES` optional comma-separated case names; when non-empty, this overrides case-group intent in the workflow
- `ORG_ID` optional
- `PROJECT_ID` optional
- `CLUSTER_IDS` optional comma-separated cluster ids
- `AWS_REGIONS`, `GCP_REGIONS`, `AZURE_REGIONS` optional region overrides

Example:

```bash
AUTH_TOKEN=... \
BRANCH=master \
DOMAIN=cdc \
TEST_ENV=dev \
CASE_GROUP=smoke \
/home/openclaw/.openclaw/workspace-defaults/skills/dataflow-service-e2e/scripts/run-e2e-gh.sh
```

### 2) Local Go harness execution

Use this only when the user explicitly wants local execution/debugging on the current machine.

Typical commands:

```bash
cd /home/openclaw/.openclaw/workspace-defaults/repos/dataflow-service/test/e2e
make dedicated-e2e-test-local
make dedicated-e2e-test-dev
make dedicated-e2e-test-staging
make dedicated-e2e-test-prod
```

Notes:

- local execution uses `gotestsum` over `run_dedicated_test.go` and `run_test.go`
- config is loaded from `config.common.yaml` + `config.<env>.yaml`
- if `tidbCloudToken` is absent in config, the harness may attempt interactive/browser-style login using configured console credentials
- for repeatable automation, prefer a pre-supplied token over interactive login

## What to read when reasoning

Read `references/e2e-logic.md` when you need:

- exact mapping between `make run-e2e` and workflow inputs
- workflow-side setup details
- config loading and token behavior
- differences between remote dispatch and local test execution

Read `references/cases.md` when you need:

- list of available cases and case groups
- case names, providers (AWS/GCP/Azure), and categories (CDC/BR)
- which cases belong to which case group

## Practical workflow

1. Confirm the repo exists at the workspace path; clone/update it with the GitHub App if needed.
2. Decide whether the user wants remote workflow dispatch or local execution.
3. For remote dispatch, prefer `scripts/run-e2e-gh.sh`.
4. For local execution, inspect `test/e2e/Makefile`, config files, and any required secrets before running.
5. After starting a run, report the exact parameters used.
6. If asked to troubleshoot failures, inspect the workflow file, `test/e2e` config logic, and the produced `e2e-report.xml` / logs.

## Guardrails

- Do not invent extra workflow inputs.
- Do not assume `cases` and `case_group` combine; treat `cases` as the more specific selector.
- Do not move the repo to a shared directory; keep business repos in the agent workspace.