JB的测试之旅-使用gitlab ci获取提交记录

前言

这篇文章，好久好久以前就想写了，但实际在写的过程，发现涉及到2个玩意：

• git命令，好比git log
• gitlab ci的配置以及gitlab-ci.yml的基本使用

因而花费了很多时间来学习这些知识
若是你对上面这两块没了解，建议你先看下下面三篇文章，先扫盲吧：
JB的git之旅--.gitlab-ci.yml介绍
JB的git之旅-git命令行
JB的git之旅-gitlab ci介绍

继续往下读，默认是对git log跟gitlab ci都了解了，而且相关环境已经配置好了；

开篇

作为一个久经沙场的测试同窗，确定会遇到下面这种场景：

项目经理/领导：JB，这BUG怎么回事啊？（此时反馈BUG描述）
JB：我看看(同时赶忙确认BUG)
（几分钟后）
JB：这真的是有BUG，我看看怎么回事（内心描述，我去，昨天都没问题的，怎么就忽然又有BUG了）
（一段时间过去了）
研发：这个BUG是由于昨晚JB2同窗提交的代码致使的，如今已经修复了；
JB：？？？昨晚提交的代码？怎么没通知测试验收？测试都不知道这回事啊~
复制代码

上面这种只是平常生活的冰山一角。。

研发：JB啊，我这有个优化，你来验证一下；
JB：这个优化作了什么，改动了什么，有什么影响面？
研发：这个就优化网页响应速度，你能够对比下响应速度是否是更快了；没什么影响的，就若是真有问题，只会影响到打开速度而已；
JB：那行，我验证下速度是否有优化跟打开网页功能是否正常；
（一段时间后）
JB:OK，没问题了，能够上线吧；
（上线后一段时间）
领导：JB，怎么这里会显示不出东西？早上仍是正常的啊；
后来确认，就是早上研发说的网页速度优化致使的，可是这二者没有关系啊！尼玛！
复制代码

生活中，研发偷偷上代码或者研发修改后给出的影响面不足致使出现线上问题的状况是很是比较常见的，尤为在小公司里面，常见的不得了；

那这类问题有没有解决方案？
这个缘由归根究竟是，我的认为是测试知道的太少了；
人都是不自觉的，若是一味依赖研发提供的信息，假如某天研发说不清楚，又或者压根没有说，而后就直接上线了，怎么破？

有同窗可能会跳出来讲，经过流程约束，这个方案是可行的，可是本次想介绍是利用工具来解决这问题；

所以就有了这么一个想法：

获取研发每一次提交的记录，经过钉钉/邮箱通知对应的同窗~
复制代码

这种作法能杜绝上面说的场景吗？

答案确定是否认的，但作了这个，至少测试同窗有更多的信息输入，而再也不是一问三不知，怎么利用这些信息，就要看具体的同窗了~

效果图

先贴一个效果图，样式就是：
XX推进到了项目名的XX分支
XX-提交记录sha值+提交内容信息

样式为：
jb推进到了项目名的XX分支
jb-提交记录sha值+提交内容信息

功能介绍:
点击项目名能够跳转到仓库地址，点击分支名能够跳转到仓库的分支地址;
点击sha值，能够跳转到对应提交记录

任务拆解下，分红2块：

1.获取数据
2.钉钉通知
复制代码

钉钉通知

接入钉钉这块，官网有文档,点击查看便可；

连接里面有交怎么在钉钉上新建机器人，这里不介绍了；
能够看到，钉钉支持如下类型：

文本类型
link类型
markdown类型
总体跳转ActionCard类型
独立跳转ActionCard类型
FeedCard类型
复制代码

根据须要的结果，选择不一样类型吧，好比本文，选择的是markdown类型
根据文档，直接上代码：

import requests
import json
dingdingurl = "你的钉钉机器人webhook"
#钉钉机器人的webhook
headers = {'Content-Type': 'application/json'}
String_textMsg = {
    "msgtype": "markdown",
    "markdown": {
        "title" : "jbtest",
        "text":    "jb is here"
    }
}
requests.packages.urllib3.disable_warnings()
String_textMsg = json.dumps(String_textMsg)
requests.post(dingdingurl, data=String_textMsg, headers=headers, verify=False)
复制代码

这里的dingdingurl须要修改为你的机器人webhook，至于webhook怎么获取，看下上面的官网文档，都有介绍的，这里不细说了；

上面的代码，运行后的效果就是这样的了：

title对应的就是图1钉钉显示的标题，text就是点击进去后的内容，ok，钉钉接入就是如此的简单~
代码的话，应该不须要说明了，就是根据钉钉的要求，构建请求头，而后把对应信息填入，发起post请求便可;
不过这里可能有个疑问，下面这代码是干吗的？

requests.packages.urllib3.disable_warnings()
复制代码

以前的文档有介绍过，能够试试，注释掉会怎样：

InsecureRequestWarning: Unverified HTTPS request is being made. 
Adding certificate verification is strongly advised.
复制代码

会报错，可是不影响结果运行，这是一个安全警告提示，缘由是咱们在请求的时候，设置了, verify=False，意思是不校验https;
在这个例子吧，把这个去掉依然是能够正常运行的，可是大部分涉及到https，都会进行校验，为了调试，就会加上verify=False；
这就是这么一个由来~

git log获取提交记录

顶部git log的文章有说起到，git log里面有一个pretty能够进行定制化，最终得出这么一个命令：

git log --pretty=format:\"%an-%h-%s-%H\" -1
-1是表示最近一次提交，就是最新的提交记录
复制代码

关于%an %h %s %H的含义，能够看下面，还有更多的字段信息，请移步到git log介绍吧~

选项	说明
%an	做者（author）的名字
%h	提交对象的简短哈希字串
%s	提交说明
%H	提交对象（commit）的完整哈希字串

最终的执行结果以下：

可能会有人问，为何咱们要用这些参数？由于咱们显示的结果就是想要这些字段；

根据上图，咱们须要如下信息：

做者名
仓库名称以及url
分支名称以及url
提交对象的简短的哈希子串及url
提交说明
复制代码

上面git log已经得到了3个参数了，那还剩下5个参数，经过其余方式获取

.gitlab-ci.yml

来到这里，默认是配置了runner，若是仍是弄，从顶部的gitlab ci文章进去看看，里面有介绍怎么配置runner

按照要求，在项目首页建立一个文件：

.gitlab-ci.yml
复制代码

新建后，编辑这文件，不难写出下面的代码：

stages:
  - test

job_test:
  stage: test
  variables: 
      branch_url: $CI_PROJECT_URL/tree/$CI_COMMIT_REF_NAME
      commit_url: $CI_PROJECT_URL/commit/$CI_COMMIT_SHA
  script:
    - python getcommitlog.py $CI_PROJECT_URL $branch_url $CI_PROJECT_NAME $commit_url $CI_COMMIT_REF_NAME
  only:
    - master
复制代码

上面的代码，是根据JB的git之旅--.gitlab-ci.yml介绍这里面的要求写出的；

这里再说明下：

定义一个stage，里面包含一个叫test的阶段；
 而后定义个job_test任务，这个任务对应的就是一个叫test阶段的stage；
 而后建立两个变量，分别是：branch_url跟commit_url,具体的值，就是不一样变量的拼接；
 建立完变量，就执行getcommitlog.py脚本，而且传一堆参数过去，最后设置只容许master分支执行；
复制代码

定义变量以及执行脚本传参时，涉及到几个系统变量，含义以下：

变量	描述
CI_PROJECT_URL	访问项目的HTTP地址
CI_COMMIT_REF_NAME	构建项目的 branch 或 tag 名称
CI_COMMIT_SHA	构建项目的 commit SHA 值
CI_PROJECT_NAME	当前正在构建的项目名称（其实是项目文件夹名）

更多的系统变量，请看移步到JB的git之旅--.gitlab-ci.yml介绍查看;

那自定义变量最终的含义是：

• branch_url：固然分支地址，好比http://xxxx/jb/jbtest/tree/master
• commit_url:提交记录地址，好比http://xxxx/jb/jbtest/commit/对应的SHA

其余4个传参的解释以下，简单说就是项目地址，项目名称，提交分支名称，commit 的SHA值

getcommitlog.py

介绍完.gitlab-ci.yml，那来介绍下里面调用的getcommitlog.py脚本
该脚本逻辑很简单，
1）获取git log信息以及处理传参信息，
2）钉钉post，代码以下：

import re
import os
import requests
import json
import sys


def getContent():
    #获取提交记录信息
    content = (os.popen("git log --pretty=format:\"%an-&%h-&%s\" -1 ").read()).split("-&")
    return content


def postDingDing(content):
    print(sys.argv)
    project_url = sys.argv[1]
    branch_url = sys.argv[2]
    project_name = sys.argv[3]
    commit_url = sys.argv[4]
    branch_name = sys.argv[5]
    name,shortcodenum,explain = content
    dingdingurl = ["https://oapi.dingtalk.com/robot/send?access_token=你的机器人access_token"]
headers = {'Content-Type': 'application/json'}
String_textMsg = {
    "msgtype": "markdown",
    "markdown": {
        "title" : "jbtest",
        "text":   "#### "+name+" 推送到了  ["+project_name+"]("+project_url+")"+"  的["+branch_name+"]("+branch_url+")  分支\n>"
        +name+" -["+shortcodenum+"]("+commit_url+")"+"  "+explain
    }
}
requests.packages.urllib3.disable_warnings()
String_textMsg = json.dumps(String_textMsg)
for i in dingdingurl:
    requests.post(i, data=String_textMsg, headers=headers, verify=False)
print(name,shortcodenum,explain,project_url,branch_url,project_name,commit_url,branch_name)

if __name__ == "__main__":
    content = getContent()
    postDingDing(content)
复制代码

脚本很简单，
1)就是获取git log所须要的值，
2)就是获取传过来的参数，
3）字符串拼接，
4）钉钉post通知，
这部分不打算介绍了，很简单的代码；

至此，整个功能介绍完毕了，把.gitlab-ci.yml放到仓库根目录，getcommitlog.py自定义目录，只不过.gitlab-ci.yml上也要跟着改下路径，而后提交两个文件，在master分支改下代码提交，就钉钉就能够收到信息了，若是不想指定master分支，就把only master去掉；

除了钉钉能够收到通知，gitlab ci上也能够看到运行状况，在仓库-CI/CD-jobs，就能看到全部.gitlab-ci的运行状况

题外话

有同窗可能会问，若是有一个脚本，好比上面这个，想全部仓库低使用，那岂不是每一个仓库都要上传这两个文件？
答对一部分，.gitlab-ci.yml是每一个仓库都须要，可是执行的脚本，能够共用，怎么公用？
经过.gitlab-ci.yml里面的指定执行路径便可；

好比仓库A有脚本A，若是想让仓库B也使用脚本A，那能够在仓库B的.gitlab-ci.yml文件里面执行执行仓库A的脚本A，使用绝对路径，若是没有权限，给权限便可；

好比一开始gitrunner安装目录在/home上，那执行仓库A的时候，就会在runner服务器有一个目录：

这个文件只要不删除，都会存在，可是须要注意的，不建议直接hardcode路径，由于builds后面的 13c1a0f2感受是个编号，会变化的，经过正则判断仓库便可；

今后在钉钉上就知道研发提交了什么，点击仓库地址还能看到研发写了什么（前提是你得有仓库权限），给研发review代码再也不话下，想一想带心动了~

介绍就到这里，代码上面有，这里不重复贴了，就是须要2个文件而已；

小结

本文主要介绍经过gitlab ci获取提交记录，涉及到git log已经gitlab ci.yml的语法以及钉钉接口推送的使用，都是基础知识点，在配置gitlab ci会容易出现问题，无过高难度的事情；

谢谢你们~