学习笔记 · Obsidian
GitHub Integrations v1
这组 API 只负责读取当前 LangSmith 租户可用的 GitHub App 安装与仓库，用于为 Deployment 选择 integration_id 和 repository。安装、授权或删除 GitHub App 不在这四个端点中。
普通与 Forge 两组入口
| 类型 | 列安装 | 列安装下仓库 |
|---|---|---|
| GitHub | GET /v1/integrations/github/install | GET /v1/integrations/github/{integration_id}/repos |
| Forge GitHub | GET /v1/integrations/forge/github/install | GET /v1/integrations/forge/github/{integration_id}/repos |
安装列表成功返回 200；仓库接口的 integration_id 是必填路径参数，格式错误可能返回 422。
返回模型
普通 GithubIntegration 包含：
- LangSmith integration
id； - GitHub
installation_id； - 安装名称
name。
Forge 模型还包含 repository_selection 与 settings_url，可判断是全部仓库还是选择性授权，并为用户提供正确的 GitHub 设置入口。
两类仓库都使用 GithubRepository：host_integration_id、仓库 id、name、owner、url、default_branch。
与部署创建的衔接
- 先列可用 installation，让用户选择明确的组织/账户。
- 用选择的 integration ID 列仓库，只展示该安装实际授权的仓库。
- 创建 Deployment 时把 integration ID、repo URL 和 revision ref 一起写入
source_config/source_revision_config。 - 发布审计同时保存仓库不可变 ID 与 commit SHA；
name、owner、默认分支和 URL 都可能变化。
安全边界
- UI 不应把“能列出 installation”解释成对所有仓库有权限；仓库列表才是当前授权范围。
- repository selection 变化或 GitHub App 被卸载后，旧缓存立即失效；创建部署前应重新验证。
- 对仓库 URL、owner、branch/ref 做服务端校验，不能信任前端回传；尤其禁止借 integration ID 访问另一租户资源。
- 文档没有定义客户端分页参数，不要虚构分页行为。若仓库很多，应观察实际响应与后续 API 版本再设计缓存/分页。