跳轉至

GitLab 整合

位元組內部外掛功能有差異，請移步閱讀：https://meego-hc.larkoffice.com/b/helpcenter/1ykiuvvj/9wbmuc14

影片

介紹

外掛功能：透過簡單的安裝和配置，研發同學可以將GitLab的Branch、commit、MR和Meegle的工作項進行關聯，並可透過merge 事件自動流轉節點/狀態。

功能新增

在 GitLab 1.0 （對應版本號為0.0.#）外掛版本上，2.0 版本（對應版本號為0.1.#）新增了以下功能：

  • 從關聯 + 流轉，變成關聯不依賴流轉，支援只關聯的場景（安裝外掛即可關聯）；
  • 在 commit 關聯的基礎上，新增分支、MR的關聯方式，且 MR 在任何狀態下皆可關聯；
  • 可關聯的Meegle工作項型別，從需求、缺陷擴充套件到所有工作項型別；
  • 流轉方式，從固定策略，變為系統識別流轉標識，更加靈活且實用；
  • 推出非必填模式，同時支援手動流轉與自動流轉；
  • 推出等待機制，從僅限進行中的節點可流轉，更新為未到達、進行中的節點都可流轉
  • 位元組內網配套 codebase 使用，無需配置 webhook，可透過介面關聯並流轉；

功能亮點：

  • 全新的關聯方式：“m-工作項ID” 或 “f-工作項ID”
  • 全新的流轉方式：關聯語法前加“resolve”字首可實現流轉，如“resolve m-工作項ID”

名詞解釋

  • 關聯：指將 GitLab 資訊與Meegle資訊進行關聯，關聯成功後，可在需求/缺陷等工作項中看到關聯的 branch/commit/MR；
  • 流轉：在關聯的基礎上，透過MR的狀態變化自動流轉工作項的節點/狀態，無需人工點選；
  • 分端流轉：各端（前端/後端...）只流轉各自端對應的節點/狀態。

安裝/升級

操作人：Meegle空間管理員

安裝新外掛

在【Meegle】中，前往空間配置 → 外掛管理 → 右上角新增外掛；

rGU3F26osd

選擇對應的外掛「新增外掛」；

JQZ7WETJAf

配置 Webhook

位元組租戶無複製 URL 操作，安裝即可關聯內網程式碼倉庫｜非位元組租戶請參考以下步驟進行配置。 支援配置某個倉庫的Webhook，配置好後，該倉庫可正常使用本外掛，與Meegle聯動； 支援配置某個倉庫組的System Webhook，配置好後，該倉庫組下的所有倉庫可正常使用本外掛，與Meegle聯動；

  1. 【Meegle】在外掛中選擇「複製 URL」；

NMSUqaPyTo

  1. 【GitLab】登入 GitLab 後，點選進入對應的倉庫，頂級側邊的 Setting → Webhooks 選項；

YHdeKuAU5L

  1. 將1複製的 URL 貼上到 GitLab 的 Webhook 中的 URL 選項中，勾選「Push events」、「Merge request events」後點選下方的「Add webhook」完成 webhook 關聯。

x4HFtCs8AC

升級已有外掛

如果已經安裝外掛，點選「更新」升級舊外掛即可。

VUso8gHAiI

外掛配置

操作人：【Meegle】空間管理員

訴求一：只關聯不流轉

無需再做任何配置，安裝外掛（注意非位元組租戶還需配置 Webhook ）即可參照【只關聯不流轉】去做關聯。

訴求二：關聯且流轉

新建規則

前往「空間配置 → 外掛 → GitLab 外掛」，點選「新增流轉規則」按鈕進入新建規則彈窗。

CBxpUOPvxq

選擇工作項型別

選擇需要流轉的工作項型別，如需求 > 業務需求模板；

xj74zGJMy0

配置一條倉庫&節點對映關係

鎖定流轉訊號來源，多端分別流轉看這裡：

  1. 點選「選擇倉庫」，選擇本條驅動規則的需要從哪個 GitLab 倉庫觸發：

YWEVuEj5ui

  1. 任意倉庫，無需分端流轉：選擇「任意倉庫」，代表在關聯的基礎上，任意倉庫的MR訊號，都可流轉工作項需求；
  2. 安全考慮，統一用特定倉庫：輸入特定倉庫的名稱（含namespace），按回車，並選中；配置好後，只有特定倉庫來的流轉訊號，才會驅動流轉節點/狀態。
  3. 多端節點/狀態，分別驅動流轉：首先，確定各端（前端/後端/...）倉庫相互獨立，不共用；然後，每條對映關係中，只配置某個端的倉庫名稱（含namespace），一個端有多個倉庫的，可注意新增；
  4. 配置好後，不同的倉庫訊號將會驅動流轉不同的節點/狀態；

注意倉庫名稱要帶 namespace，如下圖 linmi/project

gPfHGLjqzH

選擇 GitLab 事件

僅有「Merge Request 完成」這一種事件，選擇即可；

uMAsNAzzNl

選擇流轉的節點/狀態

配合上述3.1完成對應節點/狀態的配置，如XXX 倉庫 的Merge Request完成時，服務端MR 節點完成

如需要一次性流轉多個連續序列的節點，可在此處多選 注意：缺陷型別的工作項，建議不要多選，因為狀態流轉存在環路，流轉結果會不穩定

YNXF57pyN5

在需要流轉的節點, 節點流轉的完成方式只支援單人確認完成

a96f18467-f61e-4e35-a7c1-39665531c9a4

選擇必填模式

僅限節點流使用，如需求，是否卡點看這裡下方。

d7lxZy4Ze7

關聯 MR 才能流轉工作項
  • 開關開啟，將為對應流轉的節點新增必填欄位，僅當關聯的 MR merged 後，該欄位才能變成「已透過」，節點才可流轉透過；
  • 使用場景：使開發流程規範化等；
  • 缺點：較為生硬，如果沒有關聯 MR merged 訊號流入，該欄位值將阻塞節點流轉，e.g.某些需求/缺陷不涉及研發倉庫修改；

Y7EChdXzZG

自動流轉 + 手動流轉

開關關閉，代表模板中不會生成欄位，外掛將在滿足條件時驅動節點/狀態流轉透過，同時使用者也可手動點選流轉透過，不會阻塞流轉；同時因為沒有生成欄位，例項無需升級模板也可生效； 使用場景：提高研發/測試同學流轉節點的效率，在支援手動流轉的基礎上，外掛幫助自動流轉； 缺點：無法透過必填來形成開發規範。

自定義規則

a4b637cdf-fdb6-4b39-b795-b325fcbf46a3

自定義字首
  • 主要用於MR 關聯、commit 關聯、Branch 關聯
  • 使用方式參考：【訴求一：只關聯不流轉】-【在GitLab中透過以下方式關聯】
驅動關鍵字
  • 主要用於MR - merged 事件自動流轉節點/狀態
  • 使用方式參考：【訴求二：自動流轉】

儲存規則

點選「建立」儲存規則，規則預設啟用，後續可參照【自動流轉方式】進行關聯+自動流轉；

刪除規則

如果修改過程中發現模板已刪除的，代表規則已不再生效，建議點選刪除按鈕，刪掉這條規則；

KyTVGLKwDL

如果修改過程中發現節點/狀態已刪除的，可能還有存量資料使用這些節點/狀態，如果想對存量資料保持作用，則無需修改。

禁用規則

規則建立時預設為啟用，如不需要規則繼續生效，可切換開關使其被禁用； 禁用期間，流轉規則將不再生效，如有必填欄位的，請對存量資料升級模板，以免受禁用規則影響；

PBsxmrh8ih

刪除外掛

如需刪除外掛，可以點選「刪除」按鈕，刪除後，外掛將不再展現，同時相關資料會全部清空，需重新新增並進行重新配置，請謹慎操作。 如果之前開啟了必填模式，注意存量工作項中的還會有必填欄位，可以透過在詳情頁升級版本去除。

iEwTE6Fm7k

外掛使用

操作人：【Meegle】使用者

訴求一：只關聯不流轉

外掛安裝後（非位元組租戶還需 ），研發同學即可透過commit、branch、MR 關聯需求/缺陷等工作項，具體操作如下：

工作項詳情頁，快捷鍵複製ID

  • Windows: Ctrl + Shift + C
  • IOS：Cmd + Shift + C 也可透過介面點選獲取，如下圖：

lQkhrw2WdP

在GitLab中透過以下方式關聯（任選其一）

MR 關聯

新建/編輯MR時，在MR的標題、描述中用關聯語法進行關聯；

  • 任何狀態都可關聯（opened、merged）；
  • 可在標題、描述中關聯；
  • 支援編輯、修改。

ckJsczqub2

commit 關聯

commit message 中，用關聯語法進行關聯；注意這裡是一次性設定，無法修改。

WvxTvv3NiW

命令列關聯，單個需求、缺陷等工作項例項進行關聯時： 選擇多個需求、缺陷等工作項例項進行關聯時：

Branch 關聯

新建branch時，用關聯語法進行關聯；注意這裡的關聯屬於一次性關聯，無法修改，同樣一個開發分支可能對映多個需求、缺陷，不方便管理。 介面關聯：

CTRjkAM5Z1

sDPpw1XFsa

命令列關聯： 選擇多個需求、缺陷等工作項例項進行關聯時：

關聯語法

m-/M-/f-/F-workitemID ，如 m-439945

  • 大小寫不限
  • 位置不限
  • 一次性關聯多個時，用‘,’分隔即可

mMb2T3lXxB

關聯效果

完成關聯後，Meegle會收到相應的訊號，在對應的需求、缺陷等工作項例項的「GitLab程式碼分支」標籤頁展示對應資訊；

qxXZKcqNV1

訴求二：自動流轉

配置對應流轉規則後，可透過 merged 事件自動流轉節點/狀態。

使用方式

新建/編輯MR時，在 MR 的標題、描述中填寫下方流轉語法，即可在該 MR 完成 merged 時，自動流轉對應工作項或節點。

resolve m-/M-/f-/F-workitemID ，如 resolve m-439945

  • 後續當 MR 狀態變更為 merged 時，關聯的工作項將根據配置規則自動流轉；
  • 若關聯時 MR 狀態已為 merged，則在關聯成功的瞬間觸發流轉；

  • 如果測試訊號沒有變綠，可以先流轉節點為進行中狀態。 除 resolve 之外，還支援以下詞：

  • Close：Close, Closes, Closed, Closing, close, closes, closed, closing

  • Fix：Fix, Fixes, Fixed, Fixing, fix, fixes, fixed, fixing
  • Resolve：Resolve, Resolves, Resolved, Resolving, resolve, resolves, resolved, resolving
  • 整個流轉結構體，在標題、描述中的位置不限，即resolve m-439945可放在標題/描述中的任意位置
  • 一次性流轉多個時，用‘,’分隔即可，如resolve m-439945, m-439946，即可實現 merged 後自動流轉兩個工作項

位元組租戶📢

  • 位元組租戶使用codebase進行關聯時，merge request 合併後如有規則會自動進行驅動流轉，不支援使用關鍵字控制是否驅動。

FAQ

是否支援私有化部署的 GitLab？

支援，只要保證私有化版本GitLab可以訪問通外掛配置頁提供的webhook url即可。

ab3e56b58-a5eb-4372-b042-7f25ec17135b

為什麼配置之後沒有生效？

如果是私有化部署，考慮網路環境沒有互通，請檢查內網環境問題。如果非私有部署，考慮相關服務阻斷了連結，請等待相關服務恢復。

為什麼 MR 已 merged, 但訊號沒有被設定為透過

Check list ：

  • 規則配置是否完整；
  • 關聯規則中是否設定為必填；
  • 模板中的節點是否存在（有可能被其他管理員修改過）；
  • 是否升級了模板（若關聯配置是後新增的話，需要在前端升級模板，才能生效）；
  • MR 中是否使用流轉語法；
  • 流轉規則是否設定了倉庫條件。如有，檢查倉庫名稱是否匹配。注意：倉庫名稱嚴格區分大小寫。

是否可以配置分端（前端/後端/...）流轉？

可以配置多端分別驅動節點/狀態流轉：

  1. 確定各端（前端/後端/...）倉庫相互獨立，不共用；
  2. 每條對映關係中，只配置某個端的倉庫名稱（含namespace），一個端有多個倉庫的，可逐一新增。

關聯 Gtilab Tab 何時展示？

  1. 配置了流轉規則的工作項一定會展示 GitLab tab (0.2.1 版本及以上支援該策略)；
  2. 未配置流轉規則的工作項，如果在倉庫端透過命令進行了關聯，被關聯的工作項例項會展示 GitLab tab。

點選解綁未報錯但是重新整理還在？

解綁操作必須是當前工作項的建立人、角色人員、或當前負責人才可以。

開源版

如有定製訴求，可基於開源版本進行二次開發，獨立部署 https://github.com/larksuite/lark-project-template/tree/v2/project/plugin-source-code/gitlab-plugin git commit -m "m-需求ID" git commit -m "m-需求ID,f-缺陷ID" git branch m-需求ID git branch m-需求ID,f-缺陷ID