GitLab Open API 代碼量統計，讓你的努力被老闆看到

本文首發於政採雲前端團隊博客： GitLab Open API 代碼量統計，讓你的努力被老闆看到

前言

敦煌系統 是咱們政採雲前端團隊自研的項目開發全流程管理系統，目標是將項目開發的各流程所有管理起來。從項目建立，代碼初始，到代碼的本地開發，提測交付，測後發佈，版本回滾，數據統計等。本文即是該系統中遠程項目建立及數據統計部分的實現原理。後續陸續會有敦煌系統其他部分技術文章發佈。歡迎你們先關注微信公衆號 「政採雲前端團隊」，或者掘金上關注 「政採雲前端團隊」，以便第一時間獲取最新信息。

簡介

本文主要介紹如何經過 GitLab Open API 進行項目建立、初始化代碼及團隊代碼量統計。前端工程化建設過程當中，須要經過 Node 服務端進行 Git 倉庫建立、項目初始化和代碼量統計。通過一段時間開發探索，初步實現了需求。這裏作個記錄總結。

1、需求

• 建立倉庫並進行代碼初始化

  • 目的：統一項目新建入口、項目開發模板，項目開發流程。節省新成員上手成本。
  • 具體功能：團隊成員能夠經過輸入項目名、GitLab 組、項目模板等字段直接建立 GitLab 倉庫，並根據選擇的模板及名稱等信息在已建立的 GitLab 倉庫裏進行項目初始化。

• 代碼量統計

  • 目的

    • 量化團隊代碼質量，統計團隊工做量，監測業務吞吐量變化等。
    • 在團隊中推行 Commit 提交規範。

  • 具體功能

    • 獲取團隊成員的 Git Commit 信息，並存入數據庫，以 Commit 信息數據爲基礎作數據統計分析。
    • 提交信息不以 fix、feat、style、refactor 等開頭的 Commit 可繪製餅圖進行統計對比。以此推進 Commit 提交規範的施行。
    • 單個 Commit 行數超出必定數量則在統計圖中作出提示。

2、建立項目

​看過 GitLab Open API 文檔的人很容易就能找到建立接口，不過在建立以外咱們還須要導入項目模板，修改相應的項目名稱，描述，做者等信息。這涉及到多個接口的組合調用。

一、API 前綴 https://GitLabHost/api/v4 ，全部 GitLab Open API 都以此爲前綴，舉個建立項目接口的例子： https://GitLabHost/api/v4/projects 。

二、每一個請求都須要帶上建立者的 Private Token 做爲參數。且要求該建立者有對應的權限。我這裏使用了統一的用戶 Front 作爲建立人。這樣一來建立項目就不須要獲取每一個用戶的 Private Token 了。這樣作還有個好處：統計代碼量時，這部分複製代碼的代碼量會被算在 Front 這個虛擬用戶上，減小統計偏差。

• 建立項目

  POST /projects （此處只列中關鍵參數，更多參數請查看 GitLab 文檔）
  參數：
  name: 項目名（不傳 path 參數的話必填）
  path: 項目路徑（不傳 name 參數的話必填）
  namespace_id: 建立項目所在 Git 組的 id
  description: 項目描述
  import_url: 初始化項目的代碼路徑，格式： https://user:password@host/path.git

  經過調用以上接口就能夠在目標 Git 組中建立出一個帶有初始化模板的項目了。

  

  建立項目須要注意的是：

  • Front 要擁有目標 Git 組的 Master 權限才能夠建立。這裏就要求提早把 Front 加入到目標組中並賦予 Master 權限。以 front-test 組爲例：

    

  • 當前用戶也須要作權限判斷，這裏須要開發者在建立以前調用 GET /groups/:id/members 接口獲取組別用戶並對比當前人是否有權限建立了。好比：

    

    access_level 就是權限值，分別對應爲

    10 => Guest 權限
    20 => Reporter 權限
    30 => Developer 權限
    40 => Master 權限
    50 => Owner 權限

• 初始化項目信息

  建立完項目以後要初始化項目信息，細心的同窗能夠發現上面建立好的項目中的 README.md 裏面的 name ，desc 尚未被替換掉，接下來咱們就要替換包括 README.md 和 Package.json 兩個文件中的一些關鍵信息了。

  • 讀取對應的文件，這裏直接在瀏覽器中訪問對應文件而後把路徑中的 blob 改爲 raw 就能夠直接讀取到對應的文件信息了。

    舉個例子：https://GitLabHost/f2e-cube/template/leo-middle-react-pc-project/blob/master/README.md 這個連接能夠直接訪問到項目文件頁面，但獲得卻不是單純的文件信息。

    

    把 blob 改爲 raw 即直接訪問 https://GitLabHost/f2e-cube/template/leo-front-vue-pc-component/raw/master/README.md 就能夠直接獲取到文件內容了。

    

  • 讀取到文件信息以後，使用 Node 模板引擎把對應的數據注入到獲取的文件信息中就能夠了。這裏服務端使用的是 EggJs 框架。模板引擎選用 Ejs 。

    關鍵代碼：

    const result = await this.ctx.renderString(readMeStr, {
      author: userInfo.userName,
      name: gitProjectInfo.name,
      description: project.desc,
      ...others,
    });

  • 將渲染完成的字符串提交到已經建立的項目中。使用到建立 Commit 接口。

    POST /projects/:id/repository/commits （此處只列中關鍵參數，更多參數請查看 GitLab 文檔）
    參數：
    id: 項目 id (剛剛建立好項目時有返回項目信息，裏面包含項目 id)
    branch: 分支（這裏通常是 Master ）
    commit_message: commit 信息
    actions: [] 修改項

    action: 變動類型 create, delete, move, update （這裏是 update）
    file_path: 變動文件的路徑
    content: 變動後的內容即上面代碼中的 result

    至此，項目建立並初始化完成！

    

    能夠看到 name 和 desc 已經被替換成相應的項目名及中文描述了。

3、代碼量統計

​代碼量統計，在百度，谷歌搜索一下能搜出來一大把，可是基本上都是代碼拉到本地後，執行命令獲取項目的代碼量或者項目代碼的貢獻者的代碼量。比較廣泛的方案是給項目加 Git Hook 。在項目提交以前調用請求把當前提交的代碼量傳給後端進行儲存統計。這樣作的弊端有

• 須要全部的項目都加上 Git Hook 。對於幾十上百個歷史項目的團隊而言是個不小問題。
• 歷史數據統計不到。

​ GitLab API 中有個實體叫作 Event ，用戶每一個操做都會有對應的 Event 產生並儲存。咱們這裏即是經過 Event 進行代碼量統計。

• 基本信息

  • API 前綴 https://GitLabHost/api/v4
  • 每一個請求都須要帶上查詢用戶的 Private Token 做爲參數。且要求該查詢用戶有對應的權限。我這裏使用了統一的用戶 Front 作爲查詢用戶。全部被統計項目中都須要加入 Front ，並賦予 Developer 及以上權限。（能夠直接經過組賦權）

• 獲取全部須要統計代碼量的用戶的用戶名

  首先經過釘釘接口獲取團隊全部用戶的用戶名（團隊釘釘用戶名和 Git 用戶名相同）。這一步對於不是太大的團隊能夠經過手動獲取。

• 獲取對應用戶的 Git Id （若是團隊人員少，可手動收集）

  經過 GET /users?username=:username 接口獲取用戶對應的 Git User 的 Id 。

  

• 查詢用戶的 Event

  獲取到全部用戶 Id 以後就能夠調用 GET /users/:id/events 這個接口查詢到當前用戶的全部 Event 。這裏會包括有 Push 的 Event 。Event 中會有對應 Commit 信息和項目信息。不過這裏的 Commit 信息不全，不包含添加多少行代碼，刪除多少行代碼，總共多少行代碼的信息。

  

• 獲取 Commit 的詳細信息

  經過上一步獲取的 Commit 信息中的 Id 和項目 Id 再查詢 Commit 的詳細信息: GET /projects/:id/repository/commits/:sha 。這裏這裏就能夠獲取到 Commit 的 Stats 信息了。裏面包含 additions, deletions, total 信息。

  

• 存數據庫並設定定時任務

  將獲取到的數據存入數據庫就能夠作代碼量統計了。而後設置定時任務，每週跑一次或兩次進行代碼量統計。

• 須要注意的有

  • 有些操做或致使 Commit 重複，因此對於同一我的的 Commit 須要作去重。
  • GitLab Events 只會存近一年的數據。因此運行當天也只能統計近一年的代碼。
  • 必定要按人進行 Push 時間劃分，這樣第一次運行以後，後面就能夠只取上次取的最後一次 Push 的時間以後的 Commit 了。請求數能夠減小不少。
  • 執行過代碼以後發現了一些問題，好比：團隊成員誤操做將 node_modules 文件夾上傳等。這形成了統計代碼行數過多，解決辦法是過濾掉大於 10000 行（這個能夠自由指定）的 commit 。

• 問題

  • 由於接口限制，請求數太多了，因此第一次跑任務會有點慢，大概須要咱們團隊 40 多人大概須要跑2、三十分鐘。

• 後續

  • 最新版本的 GitLab Open API 使用了 GraphQL 技術。能夠解決以上問題。

後記

其實最開始的文章，咱們沒有表述清楚，是咱們寫稿和審稿沒注意到「代碼量審覈」會對一些看官帶來困擾。你們所處公司不同，可能確實會有部分公司，會以代碼量的多少來簡單粗暴的計算員工的 KPI，這點咱們一樣以爲是不妥的。文中說起的代碼及代碼量的目的，在於便於接入團隊的代碼合規檢測（如兼容性 api 檢測、lint 檢測）服務，也在於便於從數據維度進行量化，驗證架構的升級和基礎設施的完善，對同窗工做量的下降，能夠有數據指標進行說明。咱們但願基於技術、架構的升級，基礎設施和工具鏈路的完善，幫咱們作到接近 less code 的目標，幫咱們的同窗變得更「懶」，能騰出更多時間去去關注和研究對業務的將來、我的的將來更有價值的事。也但願你能一塊兒加入，幫咱們更快接近、達到這一目標。

招賢納士

招人，前端，隸屬政採雲前端大團隊（ZooTeam），50 餘個小夥伴正等你加入一塊兒浪～ 若是你想改變一直被事折騰，但願開始能折騰事；若是你想改變一直被告誡須要多些想法，卻無從破局；若是你想改變你有能力去作成那個結果，卻不須要你；若是你想改變你想作成的事須要一個團隊去支撐，但沒你帶人的位置；若是你想改變既定的節奏，將會是「5年工做時間3年工做經驗」；若是你想改變原本悟性不錯，但老是有那一層窗戶紙的模糊… 若是你相信相信的力量，相信平凡人能成就非凡事，相信能遇到更好的本身。若是你但願參與到隨着業務騰飛的過程，親手參與一個有着深刻的業務理解、完善的技術體系、技術創造價值、影響力外溢的前端團隊的成長曆程，我以爲咱們該聊聊。任什麼時候間，等着你寫點什麼，發給 ZooTeam@cai-inc.com