mcp gitlab工作流程
mcp-gitlab-workflow 是一个用于问题驱动的GitLab开发的MCP服务器。
它可以处理需求或现有的GitLab问题,并驱动标准化的交付流程:需求分析、问题创建、分支、编码、合并请求创建和问题更新。它还提供了一组原子GitLab API工具,用于自定义编排和细粒度控制。
1.核心能力
workflow_*:将通用需求打包到交付流中的高级工具流入单个工具调用gitlab_*:用于自定义编排和细粒度控制的原子GitLab API工具
问题和代码交付的目标项目配置如下 WORKFLOW_ISSUE_PROJECT_ID 和 WORKFLOW_CODE_PROJECT_ID。有关完整的配置矩阵,请参阅下面的环境变量部分。
工作流工具
workflow_requirement_to_issue:分析需求并创建GitLab问题workflow_review_mr_post_comment:审核目标合并请求并发布审核意见workflow_issue_to_delivery:从现有问题开始并完成分支->代码更改->MR->问题注释->问题日志workflow_requirement_to_delivery:从需求运行完整的端到端流
原子GitLab工具
问题工具回退到 WORKFLOW_ISSUE_PROJECT_ID 默认情况下,代码和合并请求工具会回退到 WORKFLOW_CODE_PROJECT_ID.
- 用户和标签:
gitlab_get_current_user,gitlab_list_labels,gitlab_create_label,gitlab_update_label,gitlab_delete_label - 问题:
gitlab_create_issue,gitlab_get_issue,gitlab_get_issue_notes,gitlab_add_issue_comment,gitlab_get_issue_images - 存储库:
gitlab_create_branch,gitlab_get_file,gitlab_commit_files,gitlab_upload_project_file - 合并请求:
gitlab_get_merge_request,gitlab_get_mr_notes,gitlab_create_merge_request,gitlab_create_mr_note,gitlab_get_mr_changes,gitlab_approve_mr,gitlab_unapprove_mr
2.示例
使用 workflow_requirement_to_delivery 例如,最好在提示中明确地命名工具,或者用更高级的自定义指令/技能来包装它,这样LLM就可以可靠地选择预期的工作流程。
输入
Use workflow_requirement_to_delivery to add a forum interaction feature
结果
工作流可以自动完成以下流程:
requirement analysis -> issue creation -> branch -> code change -> MR -> issue update
(1) 问题创建
(2) 根据问题进行代码更改和MR提交
(3) 问题评论
(4) 本地 issue-log.md
通过此工作流,开发人员可以将需求或分配的问题直接交给代理,并让其以问题驱动的方式完成整个开发流程。
3.配置
3.1净现值
{
"mcpServers": {
"gitlab-workflow": {
"command": "npx",
"args": ["-y", "@chntif/mcp-gitlab-workflow"],
"env": {
"GITLAB_TOKEN": "YOUR_TOKEN",
"GITLAB_API_BASE_URL": "https://gitlab.com/api/v4",
"WORKFLOW_ISSUE_PROJECT_ID": "82346102",
"WORKFLOW_ISSUE_PROJECT_PATH": "tchen1690/test",
"WORKFLOW_CODE_PROJECT_ID": "82346102",
"WORKFLOW_CODE_PROJECT_PATH": "tchen1690/test",
"WORKFLOW_BASE_BRANCH": "develop",
"WORKFLOW_TARGET_BRANCH": "develop",
"WORKFLOW_LOCAL_REMOTE_NAME": "origin"
}
}
}
}3.2食品法典
(1) 从终端添加
codex mcp add gitlab-workflow \
--env GITLAB_TOKEN=YOUR_TOKEN \
--env GITLAB_API_BASE_URL=https://gitlab.com/api/v4 \
--env WORKFLOW_ISSUE_PROJECT_ID=80376102 \
--env WORKFLOW_ISSUE_PROJECT_PATH=tchen1690/test \
--env WORKFLOW_CODE_PROJECT_ID=80376102 \
--env WORKFLOW_CODE_PROJECT_PATH=tchen1690/test \
--env WORKFLOW_BASE_BRANCH=develop \
--env WORKFLOW_TARGET_BRANCH=develop \
--env WORKFLOW_LOCAL_REMOTE_NAME=origin \
-- npx -y @chntif/mcp-gitlab-workflow(2) 或将其添加到 config.toml
[mcp_servers.gitlab-workflow]
command = "npx"
args = ["-y", "@chntif/mcp-gitlab-workflow"]
[mcp_servers.gitlab-workflow.env]
GITLAB_TOKEN = "YOUR_TOKEN"
GITLAB_API_BASE_URL = "https://gitlab.com/api/v4"
WORKFLOW_ISSUE_PROJECT_ID = "80376102"
WORKFLOW_ISSUE_PROJECT_PATH = "tchen1690/test"
WORKFLOW_CODE_PROJECT_ID = "80376102"
WORKFLOW_CODE_PROJECT_PATH = "tchen1690/test"
WORKFLOW_BASE_BRANCH = "develop"
WORKFLOW_TARGET_BRANCH = "develop"
WORKFLOW_LOCAL_REMOTE_NAME = "origin"3.3克劳德代码
claude mcp add gitlab-workflow \
-e GITLAB_TOKEN=YOUR_TOKEN \
-e GITLAB_API_BASE_URL=https://gitlab.com/api/v4 \
-e WORKFLOW_ISSUE_PROJECT_ID=80376102 \
-e WORKFLOW_ISSUE_PROJECT_PATH=tchen1690/test \
-e WORKFLOW_CODE_PROJECT_ID=80376102 \
-e WORKFLOW_CODE_PROJECT_PATH=tchen1690/test \
-e WORKFLOW_BASE_BRANCH=develop \
-e WORKFLOW_TARGET_BRANCH=develop \
-e WORKFLOW_LOCAL_REMOTE_NAME=origin \
-- npx -y @chntif/mcp-gitlab-workflow您还可以直接将3.1中的配置写入Claude Code的配置文件。
3.4本地启动
{
"mcpServers": {
"gitlab-workflow": {
"command": "node",
"args": ["/gitlab-workflow-server/dist/src/server.js"],
"env": {
"GITLAB_TOKEN": "YOUR_TOKEN",
"GITLAB_API_BASE_URL": "https://gitlab.com/api/v4",
"WORKFLOW_ISSUE_PROJECT_ID": "82346102",
"WORKFLOW_ISSUE_PROJECT_PATH": "tchen1690/test",
"WORKFLOW_CODE_PROJECT_ID": "82346102",
"WORKFLOW_CODE_PROJECT_PATH": "tchen1690/test",
"WORKFLOW_BASE_BRANCH": "develop",
"WORKFLOW_TARGET_BRANCH": "develop",
"WORKFLOW_LOCAL_REMOTE_NAME": "origin"
}
}
}
}3.5关于 uv/uvx
这个项目是一个Node.js包。 npx 是运行它的推荐方式。
4.环境变量
参数解析顺序:
tool args -> user-provided env -> built-in defaults
如果用户没有显式传递参数,例如 project_id,该工具可以使用环境变量中的运行时配置。一些变量也有内置的默认值。
| 环境变量 | 用途 | 默认值 | 必填 |
|---|---|---|---|
GITLAB_TOKEN | 服务器和所有GitLab操作使用的GitLab API访问令牌 | 无 | 是 |
GITLAB_API_BASE_URL | GitLab API的基本URL | https://gitlab.com/api/v4 | 没有 |
WORKFLOW_ISSUE_PROJECT_ID | 问题相关工具的默认目标项目ID | 无 | 否 |
WORKFLOW_ISSUE_PROJECT_PATH | 模板和引用中使用的默认问题项目路径 | 无 | 否 |
WORKFLOW_CODE_PROJECT_ID | 存储库、分支、提交和MR工具的默认目标项目ID | 无 | 否 |
WORKFLOW_CODE_PROJECT_PATH | 模板、日志和输出中使用的默认代码项目路径 | 无 | 否 |
WORKFLOW_BASE_BRANCH | 创建新传递分支之前使用的默认基分支 | develop | 没有 |
WORKFLOW_TARGET_BRANCH | 默认合并请求目标分支 | develop | 没有 |
WORKFLOW_LOCAL_REMOTE_NAME | 本地git工作流使用的默认git remote | origin | 没有 |
WORKFLOW_LABEL | 默认问题标题前缀和回退标签 | 无 | 否 |
WORKFLOW_ASSIGNEE_USERNAME | 问题和合并请求的默认受让人用户名 | 无 | 否 |
WORKFLOW_ISSUE_LOG_PATH | 本地问题日志文件的路径 | issue-log.md | 没有 |
WORKFLOW_UPDATE_ISSUE_LOG | 默认情况下,交付工作流是否更新本地问题日志 | true | 没有 |
WORKFLOW_DELIVERY_METHOD | 默认交付模式,支持 local_git 和 remote_api | local_git | 没有 |
WORKFLOW_CHECKOUT_LOCAL_BRANCH | 是否 remote_api 交付应在本地同步并签出创建的分支 | false | 没有 |
WORKFLOW_LOCK_ISSUE_PROJECT_ID | 将问题操作限制为固定的问题项目ID | 无 | 否 |
WORKFLOW_LOCK_CODE_PROJECT_ID | 将代码和MR操作限制为固定的代码项目ID | 无 | 否 |
推荐配置
GITLAB_TOKEN,GITLAB_API_BASE_URL:需要连接到GitLabWORKFLOW_ISSUE_PROJECT_ID,WORKFLOW_CODE_PROJECT_ID:定义问题项目和代码项目,可以指向同一项目WORKFLOW_ISSUE_PROJECT_PATH,WORKFLOW_CODE_PROJECT_PATH:改进渲染引用和显示输出,但这是可选的WORKFLOW_BASE_BRANCH,WORKFLOW_TARGET_BRANCH:应遵循您的团队分支策略WORKFLOW_LOCAL_REMOTE_NAME:通常origin
如果特定操作的目标值与默认环境配置不同,则传递显式工具参数将覆盖配置的值。
5.许可证
麻省理工学院
