CI/CD integration
Run a saved scenario from CI and wait for a verified terminal result.
Use a saved scenario when CI needs repeatable data preparation. First run it successfully in the intended test environment and verify that reruns do not duplicate target data.
The example below uses GitHub Actions on Ubuntu with curl and jq. Configure repository secrets DATAMAKER_API_KEY, DATAMAKER_PROJECT_ID and DATAMAKER_SCENARIO_ID. The key must be allowed to run that scenario; use a dedicated project-scoped key.
name: Prepare test data
on: workflow_dispatch
jobs:
prepare:
runs-on: ubuntu-latest
timeout-minutes: 15
env:
DATAMAKER_API_URL: https://api.datamaker.automators.com
DATAMAKER_API_KEY: ${{ secrets.DATAMAKER_API_KEY }}
DATAMAKER_PROJECT_ID: ${{ secrets.DATAMAKER_PROJECT_ID }}
DATAMAKER_SCENARIO_ID: ${{ secrets.DATAMAKER_SCENARIO_ID }}
steps:
- name: Run DataMaker scenario and wait
shell: bash
run: |
set -euo pipefail
body=$(jq -n \
--arg projectId "$DATAMAKER_PROJECT_ID" \
--arg scenarioId "$DATAMAKER_SCENARIO_ID" \
'{projectId:$projectId,scenarioId:$scenarioId,async:true}')
started=$(curl --silent --show-error --fail-with-body --max-time 60 \
-H "X-API-Key: $DATAMAKER_API_KEY" \
-H 'Content-Type: application/json' \
--data "$body" "$DATAMAKER_API_URL/scenarios/execute")
job_id=$(jq -er 'select(.success == true) | .jobId | strings | select(length > 0)' <<< "$started")
job_path=$(jq -nr --arg id "$job_id" '$id | @uri')
deadline=$((SECONDS + 600))
while (( SECONDS < deadline )); do
status=$(curl --silent --show-error --fail-with-body --max-time 30 \
-H "X-API-Key: $DATAMAKER_API_KEY" \
-H "X-Project-Id: $DATAMAKER_PROJECT_ID" \
"$DATAMAKER_API_URL/scenarios/jobs/$job_path/status")
state=$(jq -er '.state | strings' <<< "$status")
case "$state" in
completed)
if jq -e '.error == null or .error == ""' <<< "$status" >/dev/null; then
echo "DataMaker scenario completed"; exit 0
fi
echo "DataMaker script failed; inspect its run log"; exit 1 ;;
failed) echo "DataMaker scenario failed; inspect its run log"; exit 1 ;;
active|waiting|delayed|prioritized|waiting-children) sleep 5 ;;
*) echo "Unexpected scenario state: $state"; exit 1 ;;
esac
done
echo "Timed out waiting for the scenario; requesting cancellation"
curl --silent --show-error --fail-with-body --max-time 30 \
-X POST -H "X-API-Key: $DATAMAKER_API_KEY" \
-H "X-Project-Id: $DATAMAKER_PROJECT_ID" \
"$DATAMAKER_API_URL/scenarios/jobs/$job_path/cancel" >/dev/null || true
exit 1This expects the hosted asynchronous response. It deliberately rejects a desktop runner payload rather than treating it as a successful run. Add downstream tests only after this step succeeds. Hosted queue completion can still contain a script error, so the example checks both state and error and keeps polling queued states.
Configure the scenario
Put non-secret test configuration in the scenario's environment variables, or send the documented environmentVariables object with the start request. Never place raw secrets in workflow source. Keep logs focused on counts and status.
Targets must be reachable from DataMaker's execution host. A database started on the GitHub runner's localhost is not reachable at that address from a hosted DataMaker worker. Use a reachable test target or an execution arrangement on the appropriate network.
Failure and reproducibility
The polling deadline bounds CI waiting; cancellation does not undo target writes. If CI is interrupted or the start request times out, inspect DataMaker's run history before retrying.
For stable generated fixtures, retain reviewed field definitions and an integer generation seed. There is no template-id@v7 generation route. External data and scripts require their own reproducibility controls.
Use the REST reference for route behavior and Logs and retries for safe reruns.