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 the same question?
Ask it with the command you ran and the output you got, and it will be answered here.
Ask a question