能否通过glab API配置GitLab的"Merge request branch workflow"规则？

可以的，你完全可以通过GitLab的REST API或GraphQL API来配置「Merge request branch workflow」相关规则，官方的glab CLI工具也能基于这些API完成配置操作。以下是具体的配置方向和实操示例：

1. 分支保护规则（MR工作流的核心基础） #

MR分支工作流的核心逻辑大多依赖分支保护规则，比如强制要求通过MR合并、设置合并权限、审批要求等，这些都能通过API配置：

• 使用REST API创建/更新分支保护规则：

  # 示例：给main分支设置必须通过MR合并，且至少1个审批才能合并
  curl --request POST --header "PRIVATE-TOKEN: <你的访问令牌>" \
    "https://你的GitLab域名/api/v4/projects/<项目ID>/protected_branches" \
    --form "name=main" \
    --form "merge_access_level=30" \ # 30代表Developer权限，可根据需求调整
    --form "require_merge_requests=true" \
    --form "require_approvals=1"
  

• 用glab CLI调用API的简化写法：

  glab api POST /projects/<项目ID>/protected_branches -f name=main -f require_merge_requests=true -f require_approvals=1 --token <你的访问令牌>
  

2. 项目级MR合并规则配置 #

你还能通过API直接设置项目的MR合并行为，比如合并方式、是否自动删除源分支等：

# 示例：设置项目合并方式为变基合并，且合并后自动删除源分支
curl --request PUT --header "PRIVATE-TOKEN: <你的访问令牌>" \
  "https://你的GitLab域名/api/v4/projects/<项目ID>" \
  --form "merge_method=rebase_merge" \
  --form "auto_delete_source_branches=true"

关键注意事项 #

• 操作时确保你的访问令牌拥有Maintainer或Owner权限，否则无法修改分支保护和MR工作流规则
• 不同GitLab版本的API参数可能略有差异，建议对应版本的官方文档核对参数细节
• 像线性历史要求、CI通过才能合并这类细分规则，也能通过分支保护的require_push_signatures、require_ci_passed等参数配置

内容的提问来源于stack exchange，提问作者devops-db