Role: Pipeline  ·  API: POST /api/v1/restores then GET /api/v1/executions/{id}

Prefer the quemsi CLI: it posts the restore and waits. Curl below is the same contract. For clicks in the console, use Restore a tagged snapshot. For why known states matter, read Testing with Known Database States.

Before you start

Steps

1

Restore with the CLI

--wait is the default. Exit 0 on SUCCESS; non-zero on FAILED or SKIPPED. Then run tests.

quemsi restore --agent ci-staging --target-datasource app-db \ --data shopping-cart --tag use-case=e2e-baseline
2

Or POST the restore with curl

Pass data and tags to pick the latest matching version, or pass versionId if the job already resolved one.

RESPONSE=$(curl -sS -X POST "$QUEMSI_URL/api/v1/restores" \ -H "Authorization: Bearer $QUEMSI_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "data": "shopping-cart", "agent": "ci-staging", "targetDatasource": "app-db", "tags": { "use-case": "e2e-baseline" } }') EXECUTION_ID=$(printf '%s' "$RESPONSE" | jq -r .id)
3

Poll until terminal (curl only)

Status starts as SCHEDULED. Wait for SUCCESS. Fail the job on FAILED or SKIPPED.

while true; do STATUS=$(curl -sS "$QUEMSI_URL/api/v1/executions/$EXECUTION_ID" \ -H "Authorization: Bearer $QUEMSI_TOKEN" | jq -r .status) case "$STATUS" in SUCCESS) break ;; FAILED|SKIPPED) echo "restore $STATUS"; exit 1 ;; esac sleep 2 done
4

Run tests

Only start the suite after SUCCESS. Restore again at the start of the next job so leftover rows cannot leak between runs.

If restore fails

Not this page

Next