[Feature]: 支持 GitLab，以及通过 Git SSH 接入 Gogs 等其它仓库

未关闭
  • 哪里不对？
#128 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
25/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
活跃
技术栈
gitlab, go
领域
developer-experience, devtools

调研方向

Start by reading the repository binding and clone URL handling, including the catalog validation that rejects provider gitlab; inspect the existing GitHub clone, push, and pull request paths and the SSRF constraints in issues #85 and #86. The proposal leaves the GitLab API, SSH protocol, and UI entry points for a design phase. Done means the agreed first version binds and delivers changes to GitLab and a Gogs or equivalent SSH repository, handles credentials safely, and documents supported hosting and setup.

由索引模型根据 Issue 内容生成。

描述

enhancement
Problem

公开版绑定仓库、导入 Issue、发现/合入 PR 目前只接 github.com。文档也写明：GitHub Enterprise 和非 GitHub 托管需要额外适配，默认适配器只针对 github.com。

社区里不少团队代码在 GitLab 或自建 Gogs（以及同类的 Gitea 等）上。现在他们可以把需求跑在对话工作区里，但无法把这些仓库绑进项目、让沙箱按身份检出，也不能把结果以 MR/推送交回去。

代码侧也能对上这个缺口：

  • 添加仓库时 provider: gitlab 会被拒绝（catalog 用例 400）。
  • GitLab clone URL 不会被当成 GitHub 仓库，PR 对比链接为空。
  • 遗留的 GitLab 兼容托管（工蜂等）在公开 UI 里是隐藏的，不能当公开 GitLab / Gogs 适配器用。
  • 仓库里没有 Gogs / 通用 git@host:path SSH 绑定与推送路径。

社区反馈与目前的产品判断一致：GitLab 正在支持；其它 Git 托管先考虑用 Git SSH 撑住克隆和推送，不必一开始就做完整 Issue/MR API。

Proposed behavior

分两层，先把「能改到仓库里」打通，再补平台功能。

  1. GitLab 仓库（一等公民）

    • 个人设置 / 快速接入可绑定 GitLab.com 或自建 GitLab（HTTPS token 或 SSH）。
    • 对话工作区和 SOP 沙箱能按当前用户身份 clone / fetch / push。
    • 能创建或更新 Merge Request，并回写状态（对齐现有 GitHub PR 发现、合入、状态刷新）。
    • 文档写清支持的 GitLab 版本、凭据方式和能力边界（Issue 导入等可后置）。

  2. 其它 Git 托管：先走 Git SSH（Gogs 及同类）

    • 允许绑定 git@host:owner/repo.git（或等价 SSH URL），用于 Gogs、Gitea 以及没有现成 HTTP API 适配器的自建 Git。
    • 沙箱或执行机器用部署方配置的 SSH 密钥（或用户提供的 deploy key）完成 clone 与推送到指定分支。
    • 首版可以不做 Gogs Issue / PR API；交付可以是推分支，MR 链接能填就展示、不能填就只给 branch 与 SHA。
    • SSH 主机密钥、密钥注入与任务结束后擦除，走现有凭证生命周期，避免明文密钥进镜像或日志。

  3. 安全与隔离

    • Clone / SSH URL 继续走现有 SSRF 与凭据脱敏约束（#85、#86），内网 Git 只在可信团队部署下由管理员显式允许。
    • 不把组织内网域名或内部凭据写进默认镜像和文档示例。

GitLab HTTP API 与通用 SSH 的具体协议、UI 入口在方案阶段确定；本 issue 先记下社区对 GitLab + Gogs/SSH 的需求。

Scope

Platform — UI / integrations

Acceptance criteria
  • 明确首版范围：GitLab（含是否覆盖自建实例）与通用 Git SSH（Gogs 至少作为一种验证对象）。
  • 能绑定一个 GitLab 仓库，跑通最小改文件 → 推送 → MR（或文档声明的等价交付）。
  • 能绑定一个 Gogs（或同类）仓库的 SSH URL，沙箱检出并推送到指定分支；未配置密钥时有明确引导。
  • 安装 / 卸载密钥与仓库绑定时，不覆盖无关用户配置，日志中不出现明文密钥。
  • README / 部署文档更新支持的托管类型与凭据方式。
Alternatives considered
  • 继续只支持 GitHub：自建 GitLab / Gogs 的团队无法用 LoopForge 做真实交付，只能在工作区里改完再手工推。
  • 为每个托管写完整 Issue/MR 适配器：长期需要，但对 Gogs 等可先用 SSH clone/push 覆盖「改到仓库里」这条主路径。
  • 让用户在沙箱里自己配 git remote：没有项目级绑定、身份注入和交付回写，也无法进快速接入。
Checks
  • This proposal does not require organization-specific infrastructure or credentials.
  • 已检索现有 issues，无 GitLab / Gogs / 通用 Git SSH 的功能需求；#85 / #86 是 CloneURL 安全约束，实现时应遵守。当前 Discussions 已启用，本条仍作为可跟踪的功能需求。
主要语言
Go
星标
141
派生
28
平均合并
2 天 15 小时
30 天内合并 PR
41

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

Tencent/LoopForge 的其他 Issue

查看 Tencent/LoopForge 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。