连接仓库

连接仓库是告诉 Orbi 它可以处理哪个仓库的 Issue，以及往哪个分支提交拉取请求。 Orbi Cloud 同一时间只在一个生效的仓库里工作。连接是自助的：你在连接页上挑好仓库和基础分支，开通随即开始。

​

连接

在状态页上点 连接仓库 (Connect repository)（或者绑定的仓库 (Connected repository) 卡片里的 更换仓库 (Connect / change repository)）。

1. Repository —— 从你的 GitHub App 安装所覆盖的仓库里挑。
2. Base branch —— Orbi 提交拉取请求的目标分支。选中一个仓库之后，页面会载入它真实的分支列表并预选默认分支，所以通常你只需要确认。
3. 点 连接仓库。

你会回到状态页，绑定的仓库卡片这时列出了这个仓库，带一个 生效中 (Active) 标记，开通开始。

​

仓库要满足的条件

一个仓库只有在下面两条都成立时才能被连接：

• 它在你的 GitHub App 安装范围内。Orbi 只看得见你授权过的仓库。
• 它开启了 Issues。Orbi 的输入渠道全部是 Issue，所以关掉了 Issues 的仓库会被拒掉。

这两条在你提交时都会重新检查，不只是在页面渲染时查一次 —— 所以中间被取消授权的仓库也会被拦住。

​

列表里没有你的仓库时

下拉里只有你的 App 安装覆盖到的仓库。如果你的不在里面，展开连接页上的 没找到你的仓库？ (Cannot find your repository?)：它会说明原因，并给出指向 GitHub App 设置的链接，你可以在那里把仓库加进安装范围。 你也可以在任一个下拉里用 手动填写 (Enter manually) 直接输入一个 OWNER/REPO 值。这在列表暂时读不出来的时候有用，但它不会绕过授权检查 —— App 访问不到的仓库在提交时照样会被拒掉。 如果 GitHub 的仓库列表完全读不出来，页面会降级成手动填写并告诉你原因，而不是把你堵在那里。

​

会卡住每一次合并的分支保护

如果你的基础分支要求合并前必须有批准评审，连接页会立刻用红色警告你，因为这个设置会让每一次交付都停在合并那一步。 原因在身份：Orbi 用同一个 GitHub App 的身份提交拉取请求并合并它，而 GitHub 不允许一个拉取请求的作者批准自己的拉取请求。在必须批准的规则生效时，每次交付都只能走到「评审过、可以合了」这一步，然后合不进去。 有三种解法 —— 按你的策略挑一个：

1. 每次交付你自己批准。你或者同事在拉取请求上点 Approve，合并就继续。每一个改动都保留人在环里。
2. 让 admin 可以绕过。在 Settings → Branches → Branch protection rules（或者 Settings → Rules → Rulesets）下面开启 Allow admins to bypass，或者把这个账号加进 ruleset 的 bypass 列表。
3. 把必须批准数设成 0，同一处设置里改。

改完不需要重新连接 —— 下一次交付的拉取请求就能正常合并。

​

更换绑定的仓库

用 更换仓库，连一个别的。新仓库变成生效状态，前一个转入历史 —— 它不会被删掉，在状态页的历史仓库 (Historical repositories) 里还能看到。 换仓库会为新的那个重新开通一个环境，同样需要一两分钟。

​

各种报错是什么意思

​

接下来会发生什么

连接会触发开通 —— Orbi 搭起你的交付所运行的隔离环境，并把 ai-* 标签装进你的仓库。盯着开通状态 (Provisioning status) 那一列，直到它显示开通成功 (Provisioned)，然后建你的第一张 Issue。