Hover/docs
EN中文
← HomeGitHub

Environments & test accounts

One suite, many targets. By default Cloud runs your specs against the app booted inside CI (default). Add an environment to point the same specs at a deployed URL — staging, production, a PR preview — and wire in the logins each one needs.

The default environment

Every project starts with default: the workflow boots your app inside the CI runner (your dev script) and tests it there. This is the default target for pull requests and pushes. Its boot settings — package manager, dev script, app URL, test pattern — live under Configure → CI settings on the project page.

Add a remote environment

On the project page, the environment tabs are the page's context — the run history, Run now, and configuration all follow the selected tab. Click + Add environment and give it a name (staging, production) and a deployed URL. Cloud then:

  1. Creates a GitHub Environment on the repo with that name.
  2. Sets its HOVER_BASE_URL variable to the deployed URL.
  3. Re-commits the workflow so the environment appears in the dispatch picker.

Now Run now on that tab dispatches the same specs against the deployed URL — nothing boots in CI, it tests the live deployment directly.

How specs read the target

Your specs read process.env.HOVER_BASE_URL for their base URL. On default it's your dev server; on a remote environment it's the deployed URL you set. Same spec, different target — no code change.

Test accounts

Most flows need a login. Under Configure → Test accounts, add a labelled credential and Cloud writes it straight into GitHub's encrypted secret store. Your specs read it as:

process.env.HOVER_ADMIN_USER   // the username/email
process.env.HOVER_ADMIN_PASS   // the password

for a label of ADMIN. Add a TEST_USER label and you get HOVER_TEST_USER_USER / HOVER_TEST_USER_PASS, and so on.

Pass-through only — Cloud never stores the values

Credentials are sealed-box encrypted in memory and sent straight to GitHub Actions. Cloud stores and displays only the names (HOVER_ADMIN_USER), never the values, and they can't be read back. Re-add the same label to overwrite.

Accounts are scoped to the selected environment. A default account is written as a repo-level secret (it resolves in every run); an account on a named environment is written as an environment-scoped secret that overrides the repo-level one when the job binds that environment. So you can point the same ADMIN label at a sandbox user on staging and a locked-down one on production.

Removing things

Each account row has a Remove button — it deletes the GitHub secrets too, and drops the name from the workflow once no other environment still uses that label. Deleting a whole environment (from Configure → Danger zone) removes the GitHub Environment, its scoped secrets, and its entry in the workflow picker; past runs stay.

What's next