在平常的开发过程中,GitLab 和 Jira 是开发人员和项目管理人员使用频率非常高的代码管理系统和项目管理系统。但是在没有集成的情况下,两个系统是独立的,信息不能互通。开发人员需要反复登录两个不同的系统,并执行一些重复的操作来保证功能流的正常流转。这不仅效率低下,浪费时间和人力。其实,打通这两个系统有一个最基本的诉求,就是保证所有的git commit 都有一个jira issue进行track。那么下面就介绍一下如何集成 GitLab 和 Jira,保证每一次 git commit都可以关联到 Jira的issue上,并且可以直接通过jira查看对应 git commit,或者通过git直接查看对应的jira issue。

集成Gitlab 和Jira

集成Gitlab和Jira,首先需要创建一个专属的 JIRA 账号,并且拥有相应的权限,用于在 JIRA issues 添加注释和操作系统。

然后再Gitlab中,配置集成Jira,可以单独项目配置,也可以配置全局的Jira集成。下图以配置全局的Jira集成为例

  • 路径:Admin→ Settings → Intergrations
  • Enable intergration: Action – 勾选表示激活集成
  • Trigger
    • Commit: 勾选表示进行git commit时触发
    • Merge Request: 勾选表示进行 git merge request时触发
  • Common setting
    • Enable comments:勾选表示激活 jira 的注释功能
  • Transition Jira issues to Their final state:
    • Enable Jira transitions: 勾选后需要设置转换的jira 状态,如下图(不在本次介绍范围内):
  • Web URL: 输入Jira 地址即可
  • Jira API URL: 和Jira地址相同时,不需要输入
  • Username or Email: Jira 的账号
  • Enter new Password or API token: Jira账号的密码

保存成功后就配置完成了。

然后只需要遵循一条简单的 commit 规范,即在项目配置 JIRA active 的情况下,在 commit 中代码 JIRA issue 编号即可,而且 commit 信息一旦被推送到 GitLab 远端分支,就会马上被在对应 JIRA issue 下面增加 commit. 注释,可以说使用起来非常的方便,示例的 commit 如下:

git commit -am 'TEST-220 new feature done!'

jira中的issue会自动关联git的commit记录,如下图:

其中,高亮的内容都是可点击跳转的:

  • jira:这是配置的jira中分配给gitlab的账号,点击跳转jira中的用户信息
  • a commit: git 的commit内容,点击跳转git的commit内容
  • jira-api:gitlab 项目名称,点击跳转gitlab的项目页面
  • master: git的分支名称,点击跳转gitlab的分支页面
  • RDM-42:关联的issue id。

同样,Gitlab中也会超链接jira 的issue地址,如下图:

有了这个集成能力,只要保证每次git commit 或者 merger request保证有JIRA issue 编号即可。那么如何保证commit message按照这个规范执行呢?这也是我们在团队中要求规范执行的一个推进难点。实际工作中,很难要求一个团队靠自觉完成规范,最佳方案一定是通过服务端进行控制的方式实现。下面就是基于这一点,调研的如何实现git commit 规范的方法。

如何保证git commit message 的规范

方案

目前调研,有3种实现方式

  • 调整本地 git client 的hook,实现msg不满足要求时禁止提交
  • 调整git server端的hook,实现push时检查msg不满足要求禁止推送
  • 调整CI流程,实现msg不满足要求时不能完成CI流程

本地git client 的hook变更方式

  • hook 路径:/.git/hooks
  • 复制 [commit-msg.sample] 文件,并重命名为 [commit-msg]
  • 编辑 commit-msg内容如下:
#!/bin/sh
 
commit_msg_file=$1
 
commit_msg=$(cat "$commit_msg_file")
 
# 定义提交消息的规范,这里以示例为准
commit_regex='^[A-Z]+-[0-9]+'
 
if ! echo "$commit_msg" | grep -iqE "$commit_regex"; then
echo "提交消息格式不符合规范,请遵循规范格式进行提交。"
echo "commit msg必须包括JIRA issue.格式如下:"
echo "TOB-8721:summary message"
exit 1
fi

启用git server端的git hook

路径:/opt/gitlab/embedded/service/gitlab-shell/hooks

添加 pre-receive的hook文件,并保证有执行权限,内容如下:

#!/bin/bash
 
echo "开始提交信息检查..."
 
# 从标准输入获取本次提交的commit id及分支的信息
read normalInput
ARR=($normalInput)
parentCommitId=${ARR[0]}
currentCommitId=${ARR[1]}
branch=${ARR[2]}
 
echo "您提交的分支为:$branch"
 
# 获取coomit的信息,用户,邮箱,msg等
user=$(git log --pretty=format:"%an" $currentCommitId -1)
echo "提交者为:$user"
 
commitDate=$(git log --pretty=format:"%cd" $currentCommitId -1)
echo "提交日期为:$commitDate"
 
msg=$(git log --pretty=format:"%s" $currentCommitId -1)
echo "提交的注释为:$msg"
# 定义提交消息的规范,这里以示例为准
commit_regex='^[A-Z]+-[0-9]+'
if ! echo "$commit_msg" | grep -iqE "$commit_regex"; then
echo "提交消息格式不符合规范,请遵循规范格式进行提交。"
echo "commit msg必须包括JIRA issue.格式如下:"
echo "TOB-8721:summary message"
exit 1
fi

Git hook是在Git版本控制系统中的特定事件发生时触发执行的脚本。它们允许您在Git操作的不同阶段执行自定义操作。以下是一些常见的Git hook:

  1. pre-commit:在提交前执行的钩子,用于在代码提交到版本库之前运行一些检查和测试。
  2. prepare-commit-msg:在创建提交消息之前执行的钩子,用于在提交消息被编辑之前自动修改或添加内容。
  3. commit-msg:在提交消息被创建后执行的钩子,用于对提交消息进行进一步的验证或处理。
  4. post-commit:在提交完成后执行的钩子,用于触发一些后续操作或通知。
  5. pre-receive:在接收远程引用更新前执行的钩子,用于在服务器端接收新的引用或推送操作之前运行一些自定义逻辑。
  6. update:在更新引用时执行的钩子,用于在服务器端接收新的引用或推送操作时进行验证或控制。
  7. post-receive:在接收远程引用更新后执行的钩子,用于触发一些后续操作或通知。

这些Git hook可以分为服务器端和客户端两类:

  • 服务器端钩子:pre-receive、update、post-receive等钩子在Git服务器上执行,它们用于验证和控制远程引用的更新。
  • 客户端钩子:pre-commit、prepare-commit-msg、commit-msg和post-commit等钩子在本地客户端执行,它们用于在提交代码之前或之后执行一些自定义操作。

需要注意的是,Git钩子是作为脚本存在于.git/hooks目录下。在使用Git hook之前,您需要确保脚本具有执行权限。


CI集成stage

这个是在CI过程中如何实现git commit message的规范检查(以下示例是通过gitlab ci实现的)

.commit_format_check:
stage: test_jira
script:
- |
commit_message=$(git log --format=%B -n 1 $CI_COMMIT_SHA)
echo $commit_message
commit_regex="^[A-Z]+-[0-9]+"
if echo "$commit_message"|grep -iqE "$commit_regex"; then
echo "提交信息符合规则"
else
echo “提交信息不符gitlab继承jira规则,请修改!”
exit 1
fi
tags:
- ${runner_tags}

目前我们选择的方式如下:

  • 启用git server端的git hook:保证服务端的同一控制能力
  • 同时和团队宣讲本地git client 的hook变更方式,保证本地提交的准确性,减少push才发现错误的问题
最后修改日期: 2023年9月16日

留言

撰写回覆或留言

发布留言必须填写的电子邮件地址不会公开。