[原创]升级Gerrit的commit-msg,检查git commit时必须填写开发任务编号TaskID

公司使用git+gerrit+jenkins进行持续集成实践,其中gerrit用来进行Code Review。另外我们自己研发了一套敏捷项目管理系统TPM(TeamPlus Management),用来管理开发任务和电子看板。此时有一个需求,希望开发人员提交的代码能够关联到TPM上的开发任务,这样就能实现需求与代码的关联,实现 需求->backlog->userstory->task->code->build->test->deploy->prod 的全流程数据关联。

目前的一个方式是在开发人员提交代码的同时,在comments中指定TaskID,其中TaskID是TPM系统中开发任务编号。但是很多时候开发人员提交代码是,忘记在comments log中指定TaskID,导致数据缺失,不能有效辅助研发过程改进。

为此,考虑参考Gerrit的commit-msg的方式,在commit代码同时,检查comments log中是否有指定合法的TaskID。(Gerrit的commit-msg,就是在commit代码的同事,给comments log增加一个Change-ID编号)

首先,修改commit-msg,增加TaskID的检查。


# Check for if missing a unique TaskID related with TPM

#

check_TaskID() {

COMMIT_FILE=$MSG

COMMIT_MSG=$(cat $MSG)

TASK_ID=$(echo "$COMMIT_MSG" | grep -Eo "#task[A-Za-z0-9]+")

if [ -z "$TASK_ID" ]; then

echo "[ERROR] Please add TPM TaskID comment logs with a format like ‘comment logs #task20180623001‘"

exit 1

else

echo "[INFO] StoryId=["$TASK_ID"]"

fi

}

# Check for, and add if missing, a unique Change-Id

#

add_ChangeId() {

...

...

...

check_TaskID

add_ChangeId

其次,是替换旧的commit-msg文件。

检索了一遍gerrit-site目录,没有发现commit-msg文件,怀疑是在gerrit.war中。解开gerrit.war,仍然没有发现commit-msg文件,怀疑实在某个依赖lib中。我们用的gerrit版本是2.12.8。翻了一下gerrit的源代码,commit-msg是在gerrit-server/src/main/resources/com/google/gerrit/server/tools/root/hooks/commit-msg,推测是在gerrit-server的依赖lib中。解开gerrit-server-server.jar后,果然发现commit-msg。

之后有两种办法替换:

1、重新编译gerrit源码。觉得太麻烦,放弃。

2、依次解压gerrit.war和gerrit-server-server.jar,修改commit-msg,再用jar命令依次打包gerrit-server-server.jar和gerrit.war。

注意打gerrit.war的时候,需要指定Manifest,指定gerrit.war的Main-Class: Main,否则java -jar gerrit.war启动的时候找不到MainClass。

最后,升级修改后的gerrit。

网上找一找gerrit版本升级的网页有一堆。务必注意,升级之前一定要备份gerrit-site。

1、停止gerrit。 cd gerrit-site/bin; sh gerrit.sh stop

2、备份gerrit-site

3、启动新的gerrit。  java -jar new-gerrit.war init -d gerrit-site

之后基本上一路回车就行。这个过程会替换gerrit-site/bin/gerrit.war,并会重新配置一遍gerrit。

验证效果

1、启动gerrit。 cd gerrit-site/bin; sh gerrit.sh start

2、打开 http://gerrit地址/tools/hooks/commit-msg,查看是否是修改以后的文件。

3、git clone项目测试。


:~/code>git clone ssh://[项目地址] && scp -p -P 29418 [gerrit地址]:hooks/commit-msg AgileMng/.git/hooks/

Cloning into ‘AgileMng‘...

remote: Counting objects: 1952, done

remote: Finding sources: 100% (1952/1952)

remote: Total 1952 (delta 918), reused 1870 (delta 918)

Receiving objects: 100% (1952/1952), 1.17 MiB, done.

Resolving deltas: 100% (918/918), done.

commit-msg                                                                                                                               100% 4946     4.8KB/s   00:00

:~/code/AgileMng>touch 1

:~/code/AgileMng>git add 1

:~/code/AgileMng>git status

# On branch master

# Changes to be committed:

#   (use "git reset HEAD <file>..." to unstage)

#

#       new file:   1

#

:~/code/AgileMng>git commit -m "add new file 1"

[ERROR] Please add TPM TaskID in comment logs with a format like ‘comment logs #task20180623001‘

:~/code/AgileMng>git commit -m "add new file 1 #task20180618 new file 1"

[INFO] TaskId=[#task20180618]

[master 48daaed] add new file 1 #task20180618 new file 1

1 file changed, 0 insertions(+), 0 deletions(-)

create mode 100644 1

原文地址:https://www.cnblogs.com/simplestupid/p/9195491.html

时间: 2024-10-17 07:45:29

[原创]升级Gerrit的commit-msg,检查git commit时必须填写开发任务编号TaskID的相关文章

git commit -m 与 git commit -am的区别

字面解释的话,git commit -m用于提交暂存区的文件:git commit -am用于提交跟踪过的文件 要理解它们的区别,首先要明白git的文件状态变化周期,如下图所示 工作目录下面的所有文件都不外乎这两种状态:已跟踪或未跟踪.已跟踪的文件是指本来就被纳入版本控制管理的文件,在上次快照中有它们的记录,工作一段时间后,它们的状态可能是未更新,已修改或者已放入暂存区 下面以一个实例说明 在项目文件夹中新增一个文件如'a.txt'时,该文件处于untracked未跟踪状态.未跟踪状态的文件是无

规范git commit提交记录和版本发布记录

在开发过程中我们一般都会用到git管理代码,在git commit提交代码时我们一般对git commit message随便写点简单的描述,可是随着项目参与人数的增多,发现提交的commit记录越来越杂乱,不便查阅,在网上找了下解决方案,总结一下方便在公司项目中运用. commit message 格式 目前大家比较认可的是Angular团队的提交规范,很多工具也是基于此规范开发的.该提交规范格式如下: <type>(<scope>): <subject> <B

Git中将git add 与 git commit合并

修改hello.php文件 vim hello.php <?php         echo "hello world!"; ?> 查看hello.php文件 cat hello.php 查看项目文件状态 git status -s add与commit合并操作 git commit -am "合并提交" 命令行输出

git commit

git commit git commit命令提交stage区的快照到项目历史中去(HEAD). 被提交的快照被认为是一个项目的安全版本. Git不会修改他们, 除非你显示的要求了. 和git add一样git commit是Git最重要的命令之一. 尽管名字相同git commit和svn commit完全不一样. 快照被提交到本地仓储,  不会和其他git仓储有任何的交互影响. 用法 git commit 提交stage区的快照. 上面的命令运行后会自动打开一个文本编辑器让你写一些关于这次c

git commit的--amend选项

git commit --amend常常用来修改某个branch上最顶端的commit,大多数情况下,这个命令给人的感觉是用新的commit替换了原来的commit.git commit --amend与下面的语句等价: git reset --soft HEAD^ //将branch的头指针向前移动一个commit,--soft选项使得index和workspace tree的内容保持移动之前不变 ...do something... git commit -c ORIG_HEAD //-c选

git commit -m与-am的区别

前面的话 使用git commit -am是不是就可以完全不使用git add命令呢?不是 理论 要了解git commit -m与git commit -am的区别,首先要明白它们的定义 字面解释的话,git commit -m用于提交暂存区的文件,git commit -am用于提交跟踪过的文件 [注意]git commit -am可以写成git commit -a -m,但不能写成git commit -m -a 定义中出现了暂存区.跟踪过的文件等术语,如果要理解它们,就需要了解Git的文

git add和git commit

git命令使用:提交前可指定要提交哪些文件,然后使用git commit来提交 样例: git status 输出: Changes to be committed: modified:   app/Library/Common.php Changes not staged for commit: modified:   .env modified:   index.php Untracked files: .idea/ 如果你想加入本次要提交的文件,使用命令:git add index.php

git第四节----git commit message

@git  commit message 什么是git commit message :git commit -m '每次提交时编辑的内容' git commit message的好处:      1.提供更多可查询的信息,用于排查问题      2.过滤重要的内容      3.生成changelog     commit message组成包括header,body,footer三个部分,一般只使用header    header 包含三个部分:type,scope,subject     

git commit进行代码检查

使用Ant Design Pro提交代码的时候进行代码检查报了很多错 git commit --no-verify -m "commit"   就可以跳过代码检查 或者在项目里新建个.eslintignore文件,用来忽略检测的文件夹.