Files
.pouch/skills/manage-release/references/forge-adapters.md
T
2026-07-31 23:58:47 +08:00

4.0 KiB
Raw Blame History

代码托管平台适配

区分 Git 与 Forge 能力

fetch、查询 remote refs、推送分支和推送单个 tag 属于 Git transport 能力,可直接通过 已配置的 Git remote 完成。创建或查看 PR/MR、合并以及创建 Forge Release 才需要平台 CLI。只发布 tag 时,不要因为缺少 Forge CLI 而停止;仍要验证 remote、认证目标和推送 授权,并在 push 后读回远端 ref。

选择 Forge 适配器

从 push remote URL 识别平台,并使用对应官方 CLI:

平台 CLI PR/MR 命令域 Release 命令域
GitHub gh gh pr gh release
GitLab glab glab mr glab release
Gitea / Forgejo tea tea pulls tea releases

先运行 CLI 的版本、认证状态和只读查看命令。记录匹配 remote host 的活动账号;存在多 个账号或 profile 时,必须唯一确定本次使用的身份。CLI 版本之间的 flags 可能不同, 每次执行写操作前读取对应子命令的 --help,不要凭记忆拼接参数。

当请求确实涉及 PR/MR、合并或 Forge Release,且 remote host 无法识别、CLI 缺失、认证 失败或 CLI 指向另一个实例时,停止对应平台阶段并报告:

  • host、owner/repository、remote 名称。
  • base、head 和当前 commit。
  • 已完成的本地验证。
  • 尚需人工执行的创建 PR/MR、合并或 release 步骤。

不要自动安装 CLI,也不要把 token 放进命令行后改用 curl。用户明确提供受支持的其他 集成时,可以使用该集成,但仍遵守同一套授权和验证闸门。

创建 PR/MR

使用显式的 repository、base、head、title 和 body,避免交互式默认值改变目标。把动态 值作为独立 argv 或结构化输入传递,不拼接 shell 命令。创建前:

  1. 确认当前分支已经推送到计划中的 remote。
  2. 查询同一 head/base 是否已有 open PR/MR,有则复用并更新状态,不重复创建。
  3. 确认 head commit 与本地已验证 commit 相同。
  4. 确认 CLI 不会隐式创建 fork 或推送到另一个 remote。
  5. 再次读取活动账号,向用户展示 host、repository、账号和授权的最远阶段。

PR/MR body 包含目标版本、变更摘要、验证命令与结果、发布后续。创建后读取平台返回的 URL、编号、head/base 和状态,不以命令退出码代替远端读回。

检查和合并

用结构化输出读取 draft、head commit、base、review、required checks、冲突或 mergeability、允许的合并方式。平台字段缺失时,使用平台提供的只读详情命令补足;不能 证明闸门通过时保持未合并。

GitHub 使用 gh pr viewgh pr checksgh pr mergeGitLab 使用 glab mr view、pipeline 状态和 glab mr mergeGitea 或 Forgejo 使用 tea pulls 的查看、检查和合并能力。实际参数以当前 CLI 的 --help 为准。

若用户要求检查通过后自动合并,优先使用仓库已经启用的 auto-merge 或 merge queue。 不要用管理员选项绕过 review、CI、conversation resolution 或 protected branch。

合并后重新读取 PR/MR,取得平台确认的 merged commit。随后 fetch 远端 base,并验证该 commit 已进入远端 base。只看到本地 merge commit 或分支关闭不足以证明平台已合并。

创建 Forge Release

把 Git tag 和 Forge Release 当成两个独立状态。先创建、推送并验证 tag,再创建 release。

  • GitHub 创建 release 时使用能够拒绝缺失 tag 的选项,例如当前 CLI 支持的 --verify-tag
  • GitLab、Gitea 或 Forgejo 创建 release 前,先用只读命令证明 tag 已存在并指向计划的 commit;不要使用会顺便创建 tag 的默认行为。
  • 预发布版本按项目规则标记 prerelease,不要自动把它标为 latest 或 stable。
  • 发布后重新读取 release URL、tag 和可见性。

Forge Release 创建失败但 tag 已成功推送时,保留 tag 并从 release 阶段恢复,不要重新 合并或创建另一个 tag。