Configurator workflow
End-to-end deployment workflow for Saleor Configurator: validate, diff, plan, deploy. Use whenever deploying, syncing, or debugging store configuration, or when building automation that chains CLI commands.From its SKILL.md
npx -y skills add saleor/configurator --skill configurator-workflowAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
What its file declares
Copied from the file, not written here
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
5.7 KB, as published. Nobody here has run it
Configurator Workflow
Overview
This skill defines the optimal workflow sequence for deploying Saleor configurations. It covers the validate-diff-plan-deploy pipeline, JSON envelope parsing at each step, failure recovery with entity-scoped drill-down, and report-based context gathering.
When to Use
- "Deploy my config to the store"
- "What would change if I deploy?"
- "The last deploy failed, help me fix it"
- "Set up a deployment pipeline"
- Building CI/CD automation around the CLI
- When NOT looking for individual command flags -- use
configurator-cliinstead - When NOT parsing JSON output structure -- use
agent-output-parsinginstead
Core Workflow Sequence
Always follow this sequence for safe deployments:
Step 1: Validate (No Network)
pnpm dlx @saleor/configurator validate --json 2>/dev/null
Parse the envelope:
- If
result.valid === false: fixconfig.ymlerrors before proceeding - If
result.valid === true: continue to diff
Step 2: Diff (Read-Only)
pnpm dlx @saleor/configurator diff --json 2>/dev/null
Parse the envelope:
- If
result.summary.totalChanges === 0: config is in sync, no deployment needed - If
result.hasDestructiveOperations === true: warn about deletions - Otherwise: show summary of changes
Step 3: Plan (Preview)
pnpm dlx @saleor/configurator deploy --plan --json 2>/dev/null
Parse the envelope:
- Show creates, updates, deletes counts
- If
result.willDeleteEntities === true: explicitly warn - Ask for confirmation before proceeding
Step 4: Deploy (Execute)
pnpm dlx @saleor/configurator deploy --json 2>/dev/null
Parse the envelope:
- If
exitCode === 0: success - If
exitCode === 5: partial failure, drill down into errors - Other exit codes: follow the exit code decision tree
Workflow Diagram
validate --json
|
v
valid? --no--> fix config.yml --> validate again
|
yes
|
v
diff --json
|
v
changes? --no--> done (in sync)
|
yes
|
v
deploy --plan --json
|
v
review plan
|
v
deploy --json
|
v
exitCode 0? --no--> check errors, drill down
|
yes
|
v
done
Failure Recovery
When exitCode === 5 (partial failure):
- Parse
.errorsarray for failed entities - For each failed entity, drill down:
pnpm dlx @saleor/configurator diff --entity "Type/name" --json 2>/dev/null - Analyze field-level differences
- Fix config.yml for the specific entities
- Re-validate and redeploy
Drill-Down Example
# 1. Deploy fails with partial errors
OUTPUT=$(pnpm dlx @saleor/configurator deploy --json 2>/dev/null)
echo "$OUTPUT" | jq -r '.errors[] | "\(.entity): \(.message)"'
# 2. Drill into the failing entity type
pnpm dlx @saleor/configurator diff --entity-type "Categories" --json 2>/dev/null | jq '.result'
# 3. Drill into the specific entity
pnpm dlx @saleor/configurator diff --entity "Categories/electronics" --json 2>/dev/null | jq '.result.operations[].changes'
# 4. Fix config.yml based on field-level diff
# 5. Validate fix
pnpm dlx @saleor/configurator validate --json 2>/dev/null
# 6. Redeploy
pnpm dlx @saleor/configurator deploy --json 2>/dev/null
Using Reports for Context
Check previous deployment reports before starting a new workflow:
# List recent reports
ls -lt deployment-report-*.json 2>/dev/null | head -5
# Read latest report
ls -t deployment-report-*.json 2>/dev/null | head -1 | xargs cat | jq '.'
# Check for previous failures
ls -t deployment-report-*.json 2>/dev/null | head -1 | xargs cat | jq '.result.operations[] | select(.status == "failed")'
Exit Code Handling
| Code | Action |
|---|---|
| 0 | Success - report completion |
| 1 | Unexpected - check .errors and .logs |
| 2 | Auth - verify SALEOR_URL and SALEOR_TOKEN |
| 3 | Network - verify URL is reachable |
| 4 | Validation - run validate, fix errors |
| 5 | Partial - drill down with --entity, fix, redeploy |
| 6 | Deletions blocked - show deletions, confirm intent |
| 7 | Breaking blocked - show breaking changes, confirm intent |
CI/CD Pipeline Pattern
#!/bin/bash
set -e
# Step 1: Validate
VALIDATE=$(pnpm dlx @saleor/configurator validate --json 2>/dev/null)
if [ "$(echo "$VALIDATE" | jq -r '.result.valid')" != "true" ]; then
echo "Validation failed:"
echo "$VALIDATE" | jq -r '.result.errors[] | " \(.path): \(.message)"'
exit 4
fi
# Step 2: Plan
PLAN=$(pnpm dlx @saleor/configurator deploy --plan --json 2>/dev/null)
echo "Plan: $(echo "$PLAN" | jq -r '.result.summary | "creates=\(.creates) updates=\(.updates) deletes=\(.deletes)"')"
# Step 3: Deploy with safety guards
pnpm dlx @saleor/configurator deploy --fail-on-delete --json 2>/dev/null
Credentials
Credentials come from .env.local (auto-loaded) or environment variables:
SALEOR_URL- Saleor GraphQL endpoint (must end with/graphql/)SALEOR_TOKEN- API authentication token
Safety Rules
- Always validate before deploying
- Always show diff/plan before executing
- Warn explicitly about deletions
- Use
--fail-on-deletein CI/CD pipelines - Parse JSON envelopes rather than scraping text output
- Non-interactive mode is auto-detected in non-TTY environments
Related Skills
configurator-cli- Individual command reference and flagsagent-output-parsing- JSON envelope structure and parsing patternsconfigurator-troubleshoot- Error diagnosis and fix guidance