Hover/docs
EN中文
← HomeGitHub

Connect a repo

Connecting a repo takes about a minute: sign in with GitHub, pick the repo your specs live in, and Cloud writes the CI workflow for you. Nothing runs on Cloud — the workflow runs in your GitHub Actions.

Sign in

Open cloud.gethover.dev and sign in with GitHub. Hover Cloud requests the repo and workflow scopes — it needs them to read your repos, commit the workflow file, and set the Actions secrets the specs depend on. The token is held in a short-lived session cookie; Cloud stores no long-lived GitHub credential.

Pick a repo and generate CI

From the dashboard, choose New project and pick the repo your __vibe_tests__/ specs live in. Cloud then:

  1. Detects your package manager from the lockfile (pnpm-lock.yaml, package-lock.json, yarn.lock, bun.lockb) — the choice in the form is only a fallback.
  2. Generates .github/workflows/hover-e2e.yml and commits it to your default branch. The workflow installs deps, boots your app, runs playwright test, and reports the results back to Cloud.
  3. Mints a per-project ingest token and stores it as the repo secret HOVER_INGEST_TOKEN. Cloud keeps only a SHA-256 hash — the reporter step authenticates with it when it POSTs results.

What the workflow contains

Triggers on pull requests, pushes to your default branch, a manual workflow_dispatch (that's what the dashboard's Run now uses), and — once you set it — a schedule. It runs plain @playwright/test; the only Hover-specific step is the reporter that POSTs hover-results.json to Cloud.

Optional: also test a deployed site

The form ends with two optional fields — Staging URL and Production URL, under "Remote environments" (hover the ? for an in-form explainer). Leave them blank if your app isn't deployed yet, or if you're not sure — a project works fine without them, and you can add environments any time from the project page.

Fill one in and Cloud creates a GitHub Environment of that name, sets its HOVER_BASE_URL variable to the URL, and adds it to the workflow's run picker. Then Run now (and scheduled monitoring) can run the same specs against that live URL — nothing boots in CI, it tests the deployment directly. The spec reads process.env.HOVER_BASE_URL for its base URL, so no code changes: same spec, different target. Full details in Environments & accounts.

First run

Once the workflow is on your default branch you can trigger it two ways:

  • Open a pull request — PRs always run, and Cloud posts a summary comment with the pass/fail/flaky verdict.
  • Run now from the project page — dispatches the workflow immediately.

Watch it live in your repo's Actions tab; when the reporter step finishes, the run appears on the project page with its specs, timings, and any failure hints.

Re-running an old job won't work

GitHub's "re-run jobs" replays the old commit. To pick up a workflow change (a new environment, a new secret), trigger a new run — push, open a PR, or use Run now.

What's next