Credentials File Layout
Manage test account usernames, passwords, API keys, and client secrets securely. Credentials map to target environments and are stored inside .gherkio/credentials/.
🔒 Directory Convention & Security
Credentials files are mapped exactly to environments:
--env stagingloads.gherkio/credentials/staging.yamlif it exists.
[!CAUTION] Add
.gherkio/credentials/*.yamlto your project's.gitignorefile to ensure sensitive client secrets are never committed to version control.
📝 Credentials YAML Layout
# .gherkio/credentials/staging.yaml
accounts:
# Account Role key
admin:
username: admin@company.com
password: super-secret-key-1
clientId: cid_12389
# Additional Account Roles
manager:
username: manager@company.com
password: manager-secret-key
clientId: cid_45678
⚡ Referencing Credentials in DSL
Gherkio makes all variables nested inside an account map immediately available inside test scenarios via two pathways:
1. Direct Explicit Variable Binding
Use $accounts.<role>.<field> to reference any credential property explicitly:
steps:
- request:
method: POST
url: /login
body:
email: $accounts.admin.username
pass: $accounts.admin.password
2. Contextual Active Role Auto-Injection
If you execute the test run specifying a selected account, Gherkio dynamically flattens the account keys directly into the root context:
gherkio run my-test.yaml --env staging --account manager
Now, inside the test, you can directly reference $username and $password without specifying the account role prefix:
steps:
- request:
method: POST
url: /login
body:
email: $username # Dynamically binds to manager@company.com
pass: $password # Dynamically binds to manager-secret-key
This is the ultimate pattern for verifying role isolation boundaries with identical test scripts.