We are moving off a home-grown runner where the base URL was a giant switch statement in a helper. Four targets: a stack we bring up on the laptop, a shared dev box, staging and a read-only production smoke.
What does the idiomatic layout look like here? One file per target, or one file with a map inside it?
One file per target, always. An environment is one file under envs/, and its name is the file name:
projects/shop/
sdods.project.yaml
envs/local.yaml
envs/dev.yaml
envs/staging.yaml
envs/prod-smoke.yamlname: staging
ui: { baseUrl: https://staging.example.com }
api:
baseUrl: https://api-staging.example.com
headers: { Accept: application/json }
auth: { type: bearer, token: "${SHOP_API_TOKEN}" }
users: { poolSize: 4 }Then declare them so the tooling can enumerate them:
envs:
default: staging
available: [local, dev, staging, prod-smoke]A map inside one file would defeat the whole design — -e selects a file, provenance reports per environment, and secrets live in a .env.<env> named after it.
Two things that stopped us hard-coding URLs anywhere else:
Put paths in routes: in the project file rather than in steps, so a scenario says goto(cart) and the environment supplies the origin.
And for the read-only production target, use the per-environment overrides for the things that should differ in anger — timeouts, retries via ci: true, screenshots — instead of forking the project file.
If the same environment answers on more than one origin — a vanity domain and an internal one, say — put the extras in aliases: rather than making a second environment. The recorder rewrites them back to routes, so a flow recorded against the internal host still replays against the public one.
Have a different question? Ask it.