Certyn signs in to your app with a test account, and calls other services with keys you give it. All of these are environment variables: each environment (staging, production) has its own. Secret variables are stored encrypted and never shown again, not to you and not in the chat.
Give Certyn an account made for testing, never a real customer's. Runs sign in many times and create data.
Add them in Ask Certyn
Say what you need, for example add a test account or add my GitLab token. Certyn opens a small form in the chat:
- Sign-in for the test account. For a web or mobile app: an email or username and a password. For an API: an API key, a bearer token, a username and password, or something else.
- Secret for one named value. Certyn suggests the name (like
GITLAB_TOKEN) and shows the service's logo and a link to where you create the key. You can change the name.
You type the value in the form. It goes straight into the environment; the chat only learns which names were saved. If you paste a secret into the chat by mistake, Certyn will not repeat it, but it is in the conversation: change it.
You can also add variables on the Environments page. There, Secret is on by default. Turn it off for settings you want to read back later, like a region or a provider name. Every value is stored encrypted, secret or not.
Variables for the whole project
Some values are the same everywhere: a shared test account, a device-cloud key, a token for your issue tracker. Save them once on the project (Project settings → Variables, or ask Certyn to save it for the project) and every environment gets them. When an environment has its own variable with the same name, the environment's value wins. The environment's page shows the project's variables it gets, and lets you override one.
The names runs use
| Name | What it is |
|---|---|
LOGIN_USERNAME, LOGIN_PASSWORD | The test account. Runs sign in with them. |
API_KEY | An API key, sent in the header you name. |
API_TOKEN | A bearer token, sent as Authorization: Bearer. |
TOTP_SECRET | The setup key of a 2FA app, so runs make the six-digit codes themselves. |
OPENAPI_SPEC_URL | Your API's OpenAPI spec, for API tests. |
GH_TOKEN | A GitHub token, so Certyn can run your tests from your repo and open pull requests. See Work in Your Repo. |
How to use API credentials (which header, which login endpoint) is saved as a rule in the project's wiki, so every run follows it.
Sign-ins that need more than a password
- A 2FA app (Google Authenticator, 1Password and similar): add
TOTP_SECRETwith the setup key. You find it when you set up 2FA for the test account, often under can't scan the code?. The key with spaces, or the wholeotpauth://link behind the QR code, both work. - A code sent by email: when a run signs up a new account, it uses an inbox of its own and reads the code itself. For your test account, use one that does not need a code. If there is none, runs cannot sign in with it on their own; in Ask Certyn you can type the code yourself on the Machine.
- SSO: use a test account that signs in with a password. If there is none, sign in yourself on the Machine, and runs test the pages that do not need a sign-in.
Machines and variables
A Machine (the browser Ask Certyn uses while you watch) gets the environment's variables when it starts. If you add a variable while a Machine is running, restart the Machine; Certyn offers it in the chat.