连接仓库

连接一个仓库大约一分钟：用 GitHub 登录，选中 spec 所在的仓库，Cloud 替你写好 CI workflow。Cloud 上什么都不跑——workflow 跑在你的 GitHub Actions 里。

打开 cloud.gethover.dev，用 GitHub 登录。Hover Cloud 申请 repo 和 workflow 两个 scope——它需要这些来读取你的仓库、提交 workflow 文件、设置 spec 依赖的 Actions secret。token 存在一个短期会话 cookie 里；Cloud 不保存任何长期 GitHub 凭据。

选仓库并生成 CI

在仪表盘选 New project，挑中 __vibe_tests__/ spec 所在的仓库。随后 Cloud 会：

从 lockfile 检测包管理器（pnpm-lock.yaml、package-lock.json、yarn.lock、bun.lockb）——表单里的选择只是兜底。
生成 .github/workflows/hover-e2e.yml 并提交到你的默认分支。这个 workflow 安装依赖、启动应用、跑 playwright test，然后把结果回传给 Cloud。
为每个项目铸造一个 ingest token 并存为仓库 secret HOVER_INGEST_TOKEN。Cloud 只保存 SHA-256 哈希——回传步骤用它做鉴权 POST 结果。

workflow 里有什么

触发条件：pull request、推送到默认分支、手动 workflow_dispatch（仪表盘的 Run now 用的就是它），以及——你设置之后——定时任务。它跑纯 @playwright/test；唯一 Hover 专有的步骤是把 hover-results.json POST 给 Cloud 的回传步骤。

可选：顺便测试线上站点

表单最后有两个可选字段——Staging URL 和 Production URL,在*「远程环境」*一节下(把鼠标悬停在 ? 上可看到表单内的说明)。如果应用还没部署,或者你还没想好,留空即可——不填也能正常建项目,而且之后随时可以在项目页面添加环境。

填上任意一个,Cloud 就会创建一个同名的 GitHub Environment,把它的 HOVER_BASE_URL 变量设为该 URL,并加进 workflow 的运行选择器。之后 Run now(以及定时监控)就能把同一套 spec 跑在这个线上 URL 上——CI 里什么都不启动,直接测线上部署。spec 通过 process.env.HOVER_BASE_URL 读取 base URL,所以无需改代码:同一套用例,不同目标。完整说明见环境与测试账号。

首次运行

workflow 到了默认分支后，你有两种方式触发：

开一个 pull request —— PR 总会运行，Cloud 会贴一条汇总评论，给出 pass/fail/flaky 结论。
在项目页点 Run now —— 立即 dispatch workflow。

在仓库的 Actions 标签页看实时进度；回传步骤结束后，运行会带着它的 spec、耗时和失败提示出现在项目页。

重跑旧 job 没用

GitHub 的「re-run jobs」重放的是旧提交。要让 workflow 的改动生效（新环境、新 secret），请触发一次全新运行——推送、开 PR，或用 Run now。

下一步

环境与测试账号 —— 把同一套 spec 跑在 staging 或 production 上，并接入测试登录。
运行、告警与自愈 —— 读取结果并设置回归告警。