【翻譯】GitLab CI 管道和做業介紹

管道和做業介紹

官方文檔：https://docs.gitlab.com/ee/ci...

在GitLab 8.8中引入的。

注意：若是你的項目是從GitLab中拉取的鏡像倉庫，須要在項目中開啓觸動開關

Settings > Repository > Pull from a remote repository > Trigger pipelines for mirror updates.

管道

管道是一組分階段（批處理）執行的工做。同一個階段中的全部工做都是並行執行的（若是有足夠的併發Runners），若是它們所有成功，管道就進入下一個階段。若是其中一個jobs失敗，則下一個階段不（一般）執行。您能夠訪問項目的Pipeline選項卡中的管道頁面。

在下圖中，您能夠看到管道由4個階段組成（build(構建), test(測試), staging(分級), production(生產)），每一個階段都有一個或多個工做。

注意：在GitLab pipeline圖上顯示時，應當大寫顯示stats的名稱。

管道類型

管道分三種，可是一般都使用單一的「管道」來代替全部。人們常常談論他們，就好像每一個都是「管道」同樣，但實際上，他們只是綜合管道的一部分。

1. CI Pipeline： 在gitlab-ci.yml中定義的構建和測試階段。
2. Deploy Pipeline： 在.gitlab-ci.yml中定義的部署階段，用來經過各類各樣的方式將代碼部署到服務器：

   例如，將代碼發佈到生成環境

3. Project Pipeline：經過API觸發跨項目CI依賴關係，尤爲是針對微服務，但也適用於複雜的構建依賴關係：

   例如，api-> front-end，ce / ee-> omnibus。

開發工做流程

管道適應多種開發工做流程：

1. Branch Flow（例如，dev，qa，分期，生產等不一樣分支）
2. Trunk-based Flow （例如，功能分支、單一的主分支和可能帶有標籤的發佈）
3. 基於分叉的流程（例如，來自fork的合併請求）

連續交付流程示例：

工做

工做能夠在.gitlab-ci.yml文件中定義。不要與build工做或build 階段混淆。

定義管道

在.gitlab-ci.yml中經過指定階段運行的做業來定義管道。

有關做業，請參閱參考文檔。

查看管道狀態

您能夠在項目的 Pipeline選項卡下找到當前和歷史運行的管道 。點擊管道將顯示爲該管道運行的做業。

查看工做狀態

當您訪問單個管道時，您能夠看到該管道的相關做業。點擊單個做業會顯示該做業運行歷史，並容許您取消做業，重試做業或清除做業運行日誌。

查看工做失敗的緣由

在GitLab 10.7中 引入。

當管道發生故障或容許失敗時，有幾個地方能夠快速檢查失敗的緣由：

• 在管道圖中 出如今管道圖中。
• 在管道小部件中 出如今合併請求和提交頁面中。
• 在工做視圖中 出如今全局和詳細的工做視圖中。

不管任何方式中，你將鼠標懸停在失敗的做業上，你能夠看到失敗的緣由。

從GitLab 10.8中，您還能夠在工做詳情頁面上看到失敗的緣由。

管道圖

在GitLab 8.11中 引入。

管道能夠是複雜的結構，具備許多順序和平行的做業。爲了讓您更容易看到發生了什麼，它能夠查看單個管道及其狀態。

管道圖能夠經過兩種不一樣的方式顯示，具體取決於您所處的頁面。

---

當您在單個管道頁面上時，能夠找到顯示每一個階段做業名稱的常規管道圖。

其次，有管道迷你圖，佔用更少的空間，而且能夠快速瀏覽全部做業是成果仍是失敗。管道迷你圖能夠在您訪問如下頁面時找到：

• 管道索引頁面
• 提交頁面
• 合併請求頁面

經過這種方式，您能夠看到全部相關的做業以及每一個階段的最終結果。這使您能夠快速查看失敗的工做並修復它。管道迷你圖的階段是可摺疊的。將鼠標懸停在它們上面，而後單擊以展開其餘做業。

迷你圖	迷你圖展開

將類似的工做分組

在GitLab 8.12中 引入。

若是你有許多相似的工做，你的管道圖會變得很長，很難閱讀。出於這個緣由，相似的工做能夠自動組合在一塊兒。若是做業名稱以某種格式命名，則它們將在常規管線圖（非迷你圖）中摺疊爲一個組。若是您沒有看到重試或取消按鈕，您就知道管道將做業已經合併分組了。將鼠標懸停在上面會顯示分組做業的數量。能夠點擊展開它們。

基本要求是需使用如下方式的一種將兩個數字分隔開（能夠互換使用）（查看下面的示例）：

• 空間
• 斜線（/）
• 冒號（:）

注意： 更準確地說， 它使用這個正則表達式： \d+[\s:\/\\]+\d+\s*。

這些工做將經過從左到右比較這兩個數字來進行排序。一般第一個是索引，第二個是總數。

例如，如下做業將被分組在一個名爲的做業下test：

• test 0 3 => test
• test 1 3 => test
• test 2 3 => test

如下做業將被分組在下列做業中test ruby：

• test 1:2 ruby => test ruby
• test 2:2 ruby => test ruby

下列做業也將被歸類在一個做業中test ruby：

• 1/3 test ruby => test ruby
• 2/3 test ruby => test ruby
• 3/3 test ruby => test ruby

手動操做

在GitLab 8.15中 引入。

手動操做容許您在使用CI中的指定做業以前須要手動操做。整個管道能夠自動運行，但實際部署到生產須要點擊。

您能夠直接從管道圖中作到這一點。只需點擊播放按鈕便可執行指定做業。例如，在下面的圖片中，production 舞臺上有一項手動操做。

做業排序

常規管道圖

在單個管道頁面中，做業按名稱排序。

迷你管道圖

在GitLab 9.0中 引入。

在管道迷你圖中，做業首先按重要性排序，而後按名稱排序。重要性的順序是：

• 失敗
• 警告
• 有待
• 賽跑
• 手冊
• 取消
• 成功
• 跳過
• 建立

多項目管道圖

可在GitLab Premium 、GitLab Sliver或更高級版本中使用。

多項目管道，您能夠訪問跨項目管道。

如何計算管道持續時間

管道的總運行時間將排除重試和待處理（排隊）時間。咱們能夠將這個問題縮減爲尋找週期的聯合。

因此每一個工做都會被表示爲 Period，其中包括 Period#first工做開始Period#last時和工做完成時。一個簡單的例子是：

• A（1,3）
• B（2,4）
• C（6,7）

這裏A從1開始，到3結束。B從2開始，併到4結束。C從6開始，到7結束。視覺上它能夠被看做：

0  1  2  3  4  5  6  7
   AAAAAAA
      BBBBBBB
                  CCCC

A，B和C的聯合將是（1,4）和（6,7），所以總運行時間應該是：

(4 - 1) + (7 - 6) => 4

徽章

管道狀態和測試範圍內報告徽章可用。您能夠在管道設置頁面找到它們各自的連接。

受保護分行的安全

管道在受保護的分支上執行時，將執行嚴格的安全模型 。

只有在容許用戶合併或推送 特定分支時，才容許在受保護的分支上執行如下操做 ：

• 運行手動管道（使用Web UI或Pipelines API）
• 運行預約的管道
• 使用觸發器運行管道
• 在現有管線上觸發手動操做
• 重試/取消現有做業（使用Web UI或Pipelines API）

標記爲受保護的變量僅適用於在受保護分支上運行的做業，從而避免不受信任的用戶無心中訪問敏感信息，如部署憑證和令牌。

標記爲受保護的Runners只能保護分支機構運行的做業，避免不受信任的代碼要在保護runner和保存部署鍵被意外地觸發或其餘憑證執行。爲了確保打算在受保護的跑步者上執行的工做不會使用常規runner，必須對其進行相應標記。

幫助改進此翻譯