ChatGPT 中文教程
中文
联系我 goolvyouyou@gmail.com

使用 Codex 审查 GitLab 合并请求

为 GitLab 合并请求设置代码审查，并使用 @codex review 请求审查。

使用 Codex 代码审查，对 GitLab 合并 请求再进行一轮高信号审查。Codex 会审查合并请求差异、遵循仓库 指南，并发布一份重点关注严重问题的标准 GitLab 代码审查。

GitLab 支持目前处于 beta 阶段，适用于所有 ChatGPT 方案。Codex 集成在 Codex cloud 中运行。桌面应用中 GitHub 风格的仓库控件（例如 创建拉取请求）不包含在此 beta 版本中。

开始之前

请确保你具备：

  • 已连接的 GitLab 账户。GitLab.com 需要使用 标准连接流程； 自托管或 Dedicated GitLab 实例需要进行 工作区管理员模板设置。
  • 如果希望 Codex 遵循仓库特定的审查 指南，请准备一个 AGENTS.md 文件。

设置 Codex 代码审查

设置 GitLab 连接和 Codex 审查身份

对于 GitLab.com，请先在 ChatGPT 中连接 GitLab， 然后在 Codex 中连接你的 GitLab 账户。 对于自托管或 Dedicated GitLab，每位审查者都应在 工作区管理员模板发布后进行连接。

对于自托管或 Dedicated GitLab，请打开 Codex Cloud → 设置 → 连接器。 工作区管理员可以让 Codex 创建服务账户，也可以保存现有 服务账户的个人访问令牌。

让 Codex 创建账户

在 Codex Cloud → 设置 → 连接器 中，选择适用于你的 自托管或 Dedicated GitLab 主机的应用 → 选择设置服务账户 → 创建服务账户。完成设置的工作区管理员必须拥有 GitLab 实例的管理员访问权限。选择选定的群组 或仅选定的项目，然后选择 Codex 应在哪些位置运行并创建 账户。群组选项会授予对每个所选群组的 Developer 访问权限， 其项目和子群组会继承该权限；项目选项只会授予对你所选各个 项目的 Developer 访问权限。Codex 将创建 ChatGPT Codex Connector 实例服务账户，并为其生成具有 api scope 的个人访问令牌。

使用现有账户

在 GitLab 中创建或选择服务账户，并且只在 Codex 应运行的 群组或项目中授予其 Developer 访问权限。在服务 账户页面中，选择该账户 → 管理访问令牌 → 添加新 令牌，以 创建个人访问令牌， 该令牌须具有 api scope，且到期日期至少在 30 天后。返回 Codex，选择使用现有服务账户，粘贴令牌，然后选择 保存令牌。令牌在保存时会被加密，之后不会再次显示。

管理服务账户令牌

工作区管理员可以在 Codex Cloud → 设置 → 连接器中管理服务账户。对于 Codex 创建的账户，管理员可以撤销 当前令牌并生成新令牌。对于现有账户，管理员可以在 Codex 中替换或移除已保存的令牌，并根据需要在 GitLab 中单独撤销该令牌。 配置有效令牌之前，Codex 无法响应 GitLab 活动。

选择如何将 GitLab 活动传递给 Codex

为编码任务或项目特定的设置创建项目环境

在 Codex Cloud → 设置 → 环境中选择 GitLab 项目； 当你希望 Codex 为该项目编写或执行代码时，请创建项目环境， 例如编辑文件、提交变更或向合并请求分支推送更新；如果审查依赖 项目特定的密钥、网络访问权限或设置命令，也应创建项目环境。

对于 GitLab.com，启用 Codex 审查也需要项目环境。

创建环境时，开启允许来自 GitLab 的 Codex 活动， 以安装项目 webhook，将合并请求、评论和议题 事件传递给 Codex。创建项目 webhook 需要 Maintainer 或 Owner 访问权限、管理员访问权限，或可管理项目 webhook 的自定义角色。签名的项目和群组 webhook 要求 GitLab 19.0 或更高版本。在 自托管 GitLab 19.0 上，请确认已启用 webhook_signing_token 功能标志； 该标志默认启用，并已在 GitLab 19.1 中移除。

为 GitLab 群组中的项目启用 Codex 审查活动

对于自托管或 Dedicated GitLab，工作区管理员可以打开环境 → GitLab 活动 → 管理群组，在整个群组 及其子群组中启用 Codex 审查。Codex 将安装覆盖该群组 所有项目的群组 webhook。已连接的 GitLab 用户必须是群组 Owner，且 群组 webhook 需要 GitLab Premium 或 Ultimate 以及 GitLab 19.0 或更高版本。

群组活动会启用代码审查，但不会创建项目环境。 如需运行由 GitLab 触发的编码任务，例如编辑文件、运行命令、 提交变更或向合并请求推送更新，请创建项目 环境。

配置代码审查策略

在 Codex 审查设置 中配置代码审查策略。 选择仓库策略：Review my MRs、Review team MRs、 Review all MRs 或 Follow personal。然后选择运行审查的时机：MR 打开时、 每次推送时或智能触发器（实验性）。仓库设置可以 覆盖个人默认设置。

请求 Codex 审查

  1. 在合并请求评论中提及 @codex review。
  2. 等待 Codex 作出反应 (👀) 并发布审查。

Codex 会像团队成员一样，在合并请求中发布 GitLab 讨论和备注。 默认情况下，手动请求的审查可以包含 P0、P1 和 P2 级别的发现，而自动审查重点关注 P0 和 P1 级别的发现。

启用自动审查

如需自动审查符合条件的合并请求，请在 Codex 设置中开启自动 审查，选择 GitLab 仓库策略，然后选择 触发器：MR 打开时、每次推送时或智能触发器（实验性）。 当合并请求事件符合该策略和触发器时，Codex 无需 @codex review 评论 即可运行。

必须通过项目 webhook 或上级群组 webhook 启用 GitLab 活动。对于自托管或 Dedicated GitLab，所配置的服务账户 还必须拥有向项目写回内容的权限。如果已配置 项目环境，Codex 会使用该环境。如果上级群组已经启用 活动，其后代项目会继承该覆盖范围。

自定义 Codex 的审查内容

Codex 会在仓库中搜索 AGENTS.md 文件，并遵循适用的 代码审查规则。请在距离规则所约束代码最近的文件中添加 ## Code Review Rules 部分。 在有助于组织内容时，可使用 ### 标题对相关检查进行分组。

例如，实验报告服务可以避免曝光后的行为 改变对照组：

## Code Review Rules

### Experiment cohorts

- Do not filter treatment comparisons on post-exposure behavior, including conversion or retention.
  Safe path: build cohorts from assignment or exposure; report conversion as an outcome.

将适用于整个仓库的规则放在根目录的 AGENTS.md 中，将特定于服务的规则放在 嵌套文件中，例如 services/experiment_reporting/AGENTS.md。Codex 会对每个变更文件应用 覆盖该文件的根目录指南和更具体的指南，因此无关 变更无需携带服务特定的上下文。

首先编写两三条简洁规则，编码审查者经常需要 解释的检查。实用规则包括：

  • 聚焦于影响重大的仓库特定行为。 说明需要标记的 兼容性约束、数据边界或不安全的副作用，以及 其重要性。
  • 说明安全路径或例外。 为 Codex 提供足够的上下文，以区分 真实问题与预期行为。
  • 确保规则范围明确且持久。 优先描述预期结果，而不是可能 变化的函数名称，并将指南放在其所约束代码的附近。
  • 将机械性检查留给 CI。 不要在审查规则中加入格式化、lint 和其他 确定性检查。

打开一个有代表性的合并请求，并使用 @codex review 请求审查。 根据你看到的发现和反馈完善规则，并缩小或 移除产生噪声的指南。

代码审查规则用于指导 Codex；它们不能取代测试、分支保护或 必要审批。

如需临时聚焦于某个方面，请将其添加到合并请求评论中：

@codex review for issues in the database migration

处理审查发现

修复审查发现需要已配置的项目环境；仅启用群组 活动虽可支持审查，但无法运行编码任务。如果项目已有 环境，可再留一条评论，让 Codex 在同一个合并请求中修复 问题：

@codex fix the P1 issue

Codex 会启动一个以该合并请求为上下文的云端聊天，并且 在拥有相应权限时，可以将修复推送回该分支。

向 Codex 分配其他任务

其他编码任务同样需要已配置的项目环境；仅启用群组 活动只能支持审查。如果你在评论中提及 @codex，且内容不是 review，Codex 会使用你的合并请求作为上下文启动云端聊天。

@codex fix the CI failures

排查代码审查问题

如果 Codex 没有作出反应或发布审查：

  • 确认已选择预期的 GitLab 应用；如果使用项目特定的 设置，请确认该项目拥有预期的 Codex cloud 环境。
  • 确认已为该项目或某个上级群组启用活动。在 GitLab 中检查 Webhooks → 最近的事件， 并验证合并请求和备注是否成功传递。
  • 对于自托管或 Dedicated GitLab，请确认项目或群组 webhook 已 签名、已启用 SSL 验证，并且实例使用 GitLab 19.0 或 更高版本。在自托管 GitLab 19.0 上，请确认已启用 webhook_signing_token 功能 标志；修复因失败而被自动禁用的 hook。
  • 对于自托管或 Dedicated GitLab，请确认现有服务账户的 个人访问令牌处于有效状态，并具有 api scope。如果服务账户由 Codex 创建， 请确认其已在 Codex 连接器设置 中正确配置，并且该项目或群组已启用。
  • 对于自托管或 Dedicated GitLab，请确认工作区服务 账户（而不仅仅是已连接的 GitLab 用户）拥有该项目 或上级群组的 Developer 访问权限，以便 Codex 发布审查和反应。成员资格会 被继承；活动与服务账户访问权限彼此独立。
  • 确认已启用代码审查或自动审查，并且 MR 符合 仓库策略和触发器。
  • 使用 @codex review。