前言
极狐GitLab 中使用 Epic、Issue、Merge Request 进行计划和管理,继而组织和追踪进度。尤其是在 GitLab 主库 gitlab-org/gitlab存在总计超过 10W+ 的 Issue 以及 4W+ 打开的 Issue,如果每个 Issue 都要手动分类管理,那将是一场噩梦。
极狐GitLab Triage
gitlab-triage是使用 gem 管理,旨在让项目经理和 maintainers 能够通过自定义策略自动处理极狐GitLab 项目或组中的 Issue 和 Merge Request。
01
安装
使用 gem 安装,以二进制可执行文件运行在本地或 CI Pipeline 中。
$ gem install gitlab-triage
02
本地运行
gitlab-triage 本质上是 CLI 工具,可以在本地与极狐GitLab CI 或是任何可以运行 CLI 的环境与平台运行。
- 在指定项目运行
$ gitlab-triage --dry-run --token $JH_GITLAB_API_TOKEN --source-id gitlab-org/triage
- 在指定群组运行
$ gitlab-triage --dry-run --token $JH_GITLAB_API_TOKEN --source-id gitlab-org --source groups
- 在整个实例运行
$ gitlab-triage --dry-run --token $JH_GITLAB_API_TOKEN --all-projects
💡 --all-projects 用于指定对于 $JH_GITLAB_API_TOKEN 所有可见的资源。
- 指定相应实例
$ gitlab-triage --dry-run --token $JH_GITLAB_API_TOKEN --host-url https://gitlab.cn --all-projects
💡 使用 --host-url 指定需要添加 https 或 http,也可以在策略文件中指定 host_url
host_url: https://gitlab.host.com
resource_rules:
...
03
在极狐GitLab CI Pipeline 中运行
💡 可以使用 —init-ci 选项生成示例 .gitlab-ci.yml 文件
推荐使用极狐GitLab CI 自动运行 gitlab-triage,配合极狐GitLab Scheduling Pipelines 进行定时执行,或者配合 Webhook 在 Issues events 和 Merge request events 时触发执行,不过这需要少量的编程。
run:triage:triage:
stage: triage
script:
- gem install gitlab-triage
- gitlab-triage --token $GITLAB_API_TOKEN --source-id $CI_PROJECT_PATH
only:
- schedules
策略
策略是极狐GitLab Triage 的核心概念,每个策略都可以声明许多条件(condition),在满足全部条件后会执行操作(action)。同时还提供了 Summary policies(摘要策略)功能,摘要策略是一个特殊的策略,它将多个策略整合在一起,创建一个带有所有子策略的摘要 Issue,详细内容请参考官方文档。
极狐GitLab Triage 使用 triage policy 策略文件 ./.triage-policies.yml 来保存所有策略。
💡 可以使用 --init 选项命令可以生成示例策略文件
支持的资源:
- epics
- issues
- merge_request
使用 rueles (array 类型)字段来定义所有策略,如:
resource_rules:
epics:
rules:
- name: epic policy A
- name: epic policy B
issues:
rules:
- name: issue policy A
- name: issue policy B
merge_requests:
rules:
- name: merge request policy A
- name: merge request policy B
01
策略字段
gitlab-triage 提供了非常丰富的策略字段,描述策略的主体部分由4个字段组成:
name:声明策略名称和用途
condition:声明策略的执行条件
limits:声明限制运行 action 的资源数量
action:声明对满足条件资源进行的操作
condition 字段提供了 14 种条件类型,同时 ruby 字段还可以执行 ruby 表达式来进行判断;action 也提供了多种操作,还可以在 comment 中配合 极狐GitLab quick actions 进行更多的操作,详细内容请参考官方文档。
02
插件系统
同时可以使用插件来定制策略。使用 -r 或 --request 在执行操作前加载一个 ruby 文件,在该文件中完成想要进行的操作。就如下面 my_plugin.rb 这个文件:
module MyPlugin
def has_severity_label?
labels.grep(/^S\d+$/).any?
end
def has_priority_label?
labels.grep(/^P\d+$/).any?
end
def labels
resource[:labels]
end
end
Gitlab::Triage::Resource::Context.include MyPlugin
执行命令
$ gitlab-triage -r ./my_plugin.rb --token $JH_GITLAB_API_TOKEN --source-id gitlab-org/triage
现在就可以在 ruby 中判断 has_severity_label 了
resource_rules:
issues:
rules:
- name: Apply default severity or priority labels
conditions:
ruby: |
!has_severity_label? || !has_priority_label?
actions:
comment: |
#{'/label ~S3' unless has_severity_label?}
#{'/label ~P3' unless has_priority_label?}
场景推荐
💡 一般情况下,会新建一个 Bot 用户用来完成 Triage 的任务,这样可以做到很精细的管理
下面是一些比较常见的使用场景:
- 处理没有使用 Label 的 Epic、Issue 和 MR
- 处理无人反馈的 Issue 和 MR,指定 review
- 清理长时间不活跃的 Issue 和 MR
- 统计一周没有进行更新的 Issue 并生成统计 Issue
示例项目: https://jihulab.com/cloud-native/demo/triage-demo/-/snippets。
目前 gitlab-triage 已经是一个比较完备的工具,在极狐GitLab 内部基于该项目孵化了 triage-ops这样的原型来进行内部 dogfooding,并希望将其整合到极狐GitLab 产品当中。
演示视频
https://www.bilibili.com/video/BV1jb4y1n7tn/?aid=635926633&ci...
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。