test/

The test suites, and when each one runs

Dexaflow has several test trees and they answer different questions. This page says which is which, what each one proves, and when CI runs it, so a contributor can tell whether the suite that stayed silent was meant to speak.

The suites

When the heavy Kubernetes jobs are skipped

The four k3d jobs (operator-e2e, split-e2e, e2e-dbt, deploy-e2e) cost about six to eight minutes each. A pull request that touches only the paths below cannot change what they test, so scripts/ci-heavy-gate.sh skips them:

docs/
spec/
test/load/
website/
\.changes/
.*\.md$

Anything else runs them, including Makefile, scripts/, .github/ and the chart. The rule is deliberately one-sided: a file we have not thought about runs the jobs rather than skipping them.

This table is checked, not decorative. The fenced skip-paths block above is read by scripts/ci-heavy-gate.sh --self-test, which fails when it and the gate disagree. Editing one without the other turns the build red, which is the point: the same list living in prose and in code with nothing between them is how .changes/ came to be missing from the gate for a whole release cycle (#1234).

The warm pools leg of the deploy job

deploy-e2e runs twice, as a matrix: once at the shipped default and once with warm pools on (DEXAFLOW_E2E_WARM_POOLS=on, #1707). The default leg keeps the gate above. The warm pools leg costs as much again, so it runs only when a file on the warm placement or deploy path changed (--scope warm-pools), and on every event decides by that path: a pull request against its base branch, a merge queue run against the queue's base and a push against the commit before it. Prose under these paths does not count, as in the gate above.

internal/dispatch/
internal/executor/
internal/agentrpc/
internal/agent/
internal/kubeexchange/
internal/scheduler/
internal/storage/scheduler_store\.go
internal/storage/agent_store\.go
internal/storage/queries/runs\.sql
internal/domain/resource_unit\.go
internal/domain/default_limits\.go
internal/auth/agent_token\.go
internal/cli/deploy
internal/build/
cmd/dexaflow-agent/
proto/
test/e2e/deploy-e2e\.sh
test/e2e/lib\.sh
scripts/ci-heavy-gate\.sh

They are warm placement and the warm worker (dispatch, executor, the agent, its binary and its RPC side, the agent protocol, the agent token, the token exchange warm pools require), the scheduler that picks the version a task is dispatched for, the storage that resolves that version, the warm targets and the warm binding (BindWarmAttempt in runs.sql, and its generated runs.sql.go), the warm eligibility rules (resource_unit.go, default_limits.go), the deploy command and the image build, and the leg itself. The server wiring (cmd/dexaflow-server/), internal/config/, go.mod and ci.yaml are left out on purpose: with them the leg ran on 57 of 100 merges; with this list it runs on 37 of the last 100. A change confined to those paths that affects warm pools says in its pull request how warm pools were checked, for example with DEXAFLOW_E2E_WARM_POOLS=on bash test/e2e/deploy-e2e.sh on a local k3d. The same --self-test checks this block against the gate.

printf '%s\n' internal/api/dags.go | scripts/ci-heavy-gate.sh --decide-warm
# skip

printf '%s\n' internal/dispatch/dispatch.go | scripts/ci-heavy-gate.sh --decide-warm
# run

Asking the gate a question

printf '%s\n' README.md .changes/unreleased/x.yaml | scripts/ci-heavy-gate.sh --decide
# skip

printf '%s\n' internal/executor/reconcile.go | scripts/ci-heavy-gate.sh --decide
# run

The gate runs inside each job, on purpose

Not as a paths: filter and not as a job-level if:. A skipped job reports nothing, so a failure already recorded on that commit stays red forever: rerunning a pull_request run replays the original event payload, so the condition evaluates the same way every time and no remedy can clear the check. .github/workflows/changelog-guard.yaml carries that lesson, learned from the v0.4.7 cut (#1176).