GitLab 工作流

通过 mx_gitlab 工具管理 GitLab 项目。严格遵守团队规范。

前置条件

1. 1. 安装插件: INLINECODE1
2. 获取 API Key: 访问 morphix.app/api-keys 生成 mk_xxxxxx 密钥
3. 配置环境变量: INLINECODE3
4. 链接账号: 访问 morphix.app/connections 链接 GitLab 账号，或通过 mx_link 工具链接（app: gitlab）

参数命名规范（重要）

INLINECODE6 工具所有 action 的参数命名：

description 字段换行格式

⚠️ description 字段必须使用真实换行符，不要使用 \n 字面量字符串。
错误示例（在 GitLab 上会显示为 \n）：

> description: "改动\n- 修复 bug\n- 新增功能"
> 

正确示例（使用 YAML 多行字符串）：
CODEBLOCK1

代码审查策略（优先级顺序）

获取 MR 代码变更时，按以下顺序尝试：

✅ 优先：本地 git（推荐）

本地仓库 + git 命令是最可靠的代码审查方式：

• - 无需额外认证（使用本地已有凭证）
• 无响应体大小限制（任意规模的 diff）
• 速度快，工具丰富（log、diff、show、blame）

第一步：查找本地仓库路径

CODEBLOCK2

第二步：fetch 最新数据

CODEBLOCK3

第三步：获取 MR 的 commits（需要知道源分支和目标分支）

CODEBLOCK4

第四步：获取文件变更统计

CODEBLOCK5

第五步：获取具体文件的 diff

CODEBLOCK6

⚠️ 备用：mx_link proxy（本地无仓库时使用）

当本地不存在仓库时，通过 MorphixAI 代理调用 GitLab API。
注意：大型 MR 的 diff 可能因响应体过大返回 400，此时只能使用本地 git。

CODEBLOCK7

可用的 MR 相关 API：

• - GET /api/v4/projects/{id}/merge_requests/{iid} — MR 详情
• INLINECODE17 — 文件变更（可能因大小失败）
• INLINECODE18 — Discussion 线程
• INLINECODE19 — 评论列表
• INLINECODE20 — 发表评论
• INLINECODE21 — 审批状态

分支命名

• - feature/JIRA-{ID}-{简短描述} — 新功能
• INLINECODE23 — bug 修复
• INLINECODE24 — 发布分支
• INLINECODE25 — 生产热修复

Commit Message 格式

INLINECODE26

• - Scope：模块名（SDK、CLI、Gateway、Bot 等）
• Actions：add / update / fix / remove / refactor
• 示例：INLINECODE27
• 相关改动一个 commit，绝不混杂无关重构

核心操作（mx_gitlab）

查看当前用户

CODEBLOCK8

列出项目

CODEBLOCK9

查看项目详情

CODEBLOCK10

MR 操作

列出 MR：
CODEBLOCK11

创建 MR：
CODEBLOCK12

审批 MR：
CODEBLOCK13

查看单条 MR 详情（含合并就绪状态）：

mx_gitlab:
  action: get_merge_request
  project: "12345"
  mr_iid: 42

• - detailed_merge_status: mergeable（可合并）/ preparing（准备中，需等待）/ checking（检查中）/ ci_must_pass（CI 未通过）/ not_approved（未获批准）/ discussions_not_resolved（有未解决讨论）
• INLINECODE35: 是否有冲突
• INLINECODE36: 阻塞性讨论是否已解决
• INLINECODE37: 最新 Pipeline 状态

合并前必须先检查状态（重要）：

⚠️ 直接调用 merge_merge_request 而不检查状态会导致 500 错误（MR 未就绪时 GitLab 拒绝合并）

CODEBLOCK15

合并 MR：
CODEBLOCK16

✅ merge_merge_request 会自动检查 detailed_merge_status，若 MR 未就绪会直接返回错误和原因，无需手动 pre-check。

更新 MR（设置 Reviewer / Assignee / 标签等）：
CODEBLOCK17

CI/CD 操作

查看 Pipeline：
CODEBLOCK18

重试失败的 Pipeline：
CODEBLOCK19

Issue 操作

列出 Issue：
CODEBLOCK20

创建 Issue：
CODEBLOCK21

分支操作

列出分支：

mx_gitlab:
  action: list_branches
  project: "12345"
  search: "feature/"

MR 创建规范

标题：INLINECODE41

描述必须包含：

1. 1. 改了什么，为什么改
2. 如何测试
3. 关联的 Jira Issue 链接

至少指定 1 个 Reviewer。单个 MR 最多 500 行变更。

Code Review 检查清单

Review MR 时，按顺序检查所有项目：

1. 1. 分支命名符合规范
2. Commit message 清晰且有 scope
3. 代码符合团队风格指南
4. 有对应的测试用例
5. CI pipeline 全绿
6. 无未解决的 Discussion
7. 无硬编码的 secret 或 token
8. 破坏性变更有文档说明

所有项通过才能 approve。评论具体问题时引用行号。

常见工作流

审查指定 MR（完整流程）

CODEBLOCK23

查看我的待处理 MR

CODEBLOCK24

创建并合并 Feature MR

CODEBLOCK25

CI 失败处理

CODEBLOCK26

设置 MR Reviewer（完整流程）

CODEBLOCK27

Pipeline 监控（等待 Pipeline 完成）

⚠️ 心跳（HEARTBEAT）默认间隔 30m，Anthropic setup-token 下为 1h，不适合实时监控。
推荐做法：将监控任务写入 HEARTBEAT.md，心跳触发时自动检查：

> ## 待监控
> - Pipeline #10164 (project: tanka-electron)：等待完成，完成后通知用户
> 

或用户要求"立即检查"时，直接调用：

> mx_gitlab: list_pipelines, project: "<id>", per_page: 5
> 

对比 pipeline id 和状态，判断是否完成。

注意事项

• - project 参数：数字 ID（如 "12345"）或路径（如 "my-group/my-project"），通过 list_projects 或 get_project 获取
• INLINECODE48 是 MR 在项目内的序号（非全局 ID），从 list_merge_requests 或 create_merge_request 返回结果中获取
• INLINECODE51 参数通常省略，工具自动检测已链接的 GitLab 账号
• INLINECODE52 获取 MR diff 可能因响应体过大返回 400，优先使用本地 git