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會容易出現問題，無過高難度的事情；

謝謝你們~