CI/CD pipelines · Gitlab 中文文檔

# CI/CD pipelines > 原文：[https://docs.gitlab.com/ee/ci/pipelines/](https://docs.gitlab.com/ee/ci/pipelines/) * [Types of pipelines](#types-of-pipelines) * [Configure a pipeline](#configure-a-pipeline) * [View pipelines](#view-pipelines) * [Run a pipeline manually](#run-a-pipeline-manually) * [Run a pipeline by using a URL query string](#run-a-pipeline-by-using-a-url-query-string) * [Add manual interaction to your pipeline](#add-manual-interaction-to-your-pipeline) * [Start multiple manual actions in a stage](#start-multiple-manual-actions-in-a-stage) * [Delete a pipeline](#delete-a-pipeline) * [Pipeline quotas](#pipeline-quotas) * [How pipeline duration is calculated](#how-pipeline-duration-is-calculated) * [Pipeline security on protected branches](#pipeline-security-on-protected-branches) * [View jobs in a pipeline](#view-jobs-in-a-pipeline) * [See why a job failed](#see-why-a-job-failed) * [The order of jobs in a pipeline](#the-order-of-jobs-in-a-pipeline) * [Group jobs in a pipeline](#group-jobs-in-a-pipeline) * [Specifying variables when running manual jobs](#specifying-variables-when-running-manual-jobs) * [Delay a job](#delay-a-job) * [Expand and collapse job log sections](#expand-and-collapse-job-log-sections) * [Custom collapsible sections](#custom-collapsible-sections) * [Visualize pipelines](#visualize-pipelines) * [Regular pipeline graphs](#regular-pipeline-graphs) * [Pipeline mini graphs](#pipeline-mini-graphs) * [Pipeline success and duration charts](#pipeline-success-and-duration-charts) * [Pipeline badges](#pipeline-badges) * [Pipelines API](#pipelines-api) * [Troubleshooting `fatal: reference is not a tree:`](#troubleshooting-fatal-reference-is-not-a-tree) # CI/CD pipelines[](#cicd-pipelines "Permalink") 在 GitLab 8.8 中引入. **提示：**觀看["精通持續軟件開發"](https://about.gitlab.com/webcast/mastering-ci-cd/)網絡廣播，以觀看 GitLab CI / CD 管道的全面演示. 管道是持續集成，交付和部署的頂級組件. Pipelines comprise: * 作業，定義*要做*什么. 例如，編譯或測試代碼的作業. * 階段，定義*何時*運行作業. 例如，在編譯代碼的階段之后運行測試的階段. 作業由[Runners](../runners/README.html)執行. 如果有足夠的并發運行程序，則可以并行執行同一階段中的多個作業. 如果一個階段中的*所有*作業*都*成功，則管道將繼續進行下一個階段. If *any* job in a stage fails, the next stage is not (usually) executed and the pipeline ends early. 通常，管道是自動執行的，創建后就無需干預. 但是，有時您還可以手動與管道進行交互. 典型的管道可能包含四個階段，按以下順序執行： * 一個`build`階段，其工作稱為`compile` . * 一個`test`階段，具有兩個作業，分別稱為`test1`和`test2` . * `staging`階段，其工作稱為`deploy-to-stage` . * `production`階段，其工作稱為`deploy-to-prod` . **注意：**如果您有[從 GitLab 提取鏡像的存儲庫，則](../../user/project/repository/repository_mirroring.html#pulling-from-a-remote-repository-starter)可能需要在項目的**"設置">"存儲庫">"從遠程存儲庫中提取">"觸發管道更新鏡像"中**啟用管道觸發. ## Types of pipelines[](#types-of-pipelines "Permalink") 管道可以通過許多不同的方式進行配置： * [基本管道](pipeline_architectures.html#basic-pipelines)在每個階段同時運行所有內容，隨后是下一階段. * [定向非循環圖管線（DAG）管線](../directed_acyclic_graph/index.html)基于作業之間的關系，并且比基本管線運行得更快. * [多項目管道](../multi_project_pipelines.html)將不同項目的[管道](../multi_project_pipelines.html)組合在一起. * [父子管道](../parent_child_pipelines.html)將復雜的管道分解為一個父管道，該管道可以觸發多個子管道，這些子管道都在同一項目中并以相同的 SHA 運行. * [合并請求的管道僅針對合并請求](../merge_request_pipelines/index.html)運行（而不是針對每次提交）. * [合并結果管道](../merge_request_pipelines/pipelines_for_merged_results/index.html)是合并請求管道，其作用就像源分支的更改已被合并到目標分支一樣. * [合并列車](../merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.html)使用管道獲取合并結果，以使合并一個接一個地排隊. ## Configure a pipeline[](#configure-a-pipeline "Permalink") 在 CI / CD 管道配置文件中為每個項目定義了管道及其組件作業和階段. * 作業是[基本的配置](../yaml/README.html#introduction)組件. * 階段是通過使用[`stages`](../yaml/README.html#stages)關鍵字定義的. 有關 CI 管道文件中配置選項的列表，請參見《 [GitLab CI / CD 管道配置參考》](../yaml/README.html) . 您還可以通過 GitLab UI 配置管道的特定方面. 例如： * 每個項目的[管道設置](settings.html) . * [Pipeline schedules](schedules.html). * [Custom CI/CD variables](../variables/README.html#custom-environment-variables). ### View pipelines[](#view-pipelines "Permalink") 您可以在項目的**CI / CD>管道**頁面下找到當前和歷史管道運行. 您還可以通過導航到" **管道"**選項卡來訪問合并請求的**管道** . [![Pipelines index page](https://img.kancloud.cn/5a/4d/5a4ddf2bcb4501c16fd6d29797912167_1269x506.png)](img/pipelines_index_v13_0.png) 單擊管道將帶您進入" **管道詳細信息"**頁面，并顯示為該管道運行的作業. 在這里，您可以取消正在運行的管道，在發生故障的管道上重試作業或[刪除管道](#delete-a-pipeline) . [從 GitLab 12.3 開始，](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/50499)可以在`/project/pipelines/[branch]/latest`找到指向給定分支的最后提交的最新管道的鏈接. 另外， `/project/pipelines/latest`會將您重定向到項目默認分支上最后一次提交的最新管道. [從 GitLab 13.0 開始](https://gitlab.com/gitlab-org/gitlab/-/issues/215367) ，您可以通過以下方式過濾管道列表： * 觸發作者 * 分店名稱 * 狀態（ [自 GitLab 13.1 起](https://gitlab.com/gitlab-org/gitlab/-/issues/217617) ） * 標簽（ [自 GitLab 13.1 起](https://gitlab.com/gitlab-org/gitlab/-/issues/217617) ） ### Run a pipeline manually[](#run-a-pipeline-manually "Permalink") 可以使用預定義或手動指定的[變量](../variables/README.html)手動執行管道. 如果在管道的正常操作之外需要管道的結果（例如，代碼生成），則可以執行此操作. 要手動執行管道： 1. 導航到項目的**CI / CD>管道** . 2. 單擊**運行管道**按鈕. 3. 在" **運行管道"**頁面上： 1. 在" **創建位置"**字段中選擇要為其運行管道的分支. 2. 輸入管道運行所需的任何[環境變量](../variables/README.html) . 3. 單擊**創建管道**按鈕. 管道將按照配置執行作業. ### Run a pipeline by using a URL query string[](#run-a-pipeline-by-using-a-url-query-string "Permalink") 在 GitLab 12.5 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/24146) . 您可以使用查詢字符串來預填充" **運行管道"**頁面. 例如，查詢字符串`.../pipelines/new?ref=my_branch&var[foo]=bar&file_var[file_foo]=file_bar`將使用以下內容預填充" **運行管道"**頁面： * **競選** field: `my_branch`. * **Variables** section: * Variable: * Key: `foo` * Value: `bar` * File: * Key: `file_foo` * Value: `file_bar` `pipelines/new` URL 的格式為： ``` .../pipelines/new?ref=<branch>&var[<variable_key>]=<value>&file_var[<file_key>]=<value> ``` 支持以下參數： * `ref` ：指定用于填充" **運行為"**字段的分支. * `var` ：指定一個`Variable`變量. * `file_var` ：指定一個`File`變量. 對于每個`var`或`file_var` ，都需要一個鍵和一個值. ### Add manual interaction to your pipeline[](#add-manual-interaction-to-your-pipeline "Permalink") 在 GitLab 8.15 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/7931) . 使用[`when:manual`](../yaml/README.html#whenmanual)參數配置的手動操作使您可以要求手動交互，然后才能在管道中繼續前進. 您可以直接從管道圖執行此操作. 只需單擊播放按鈕即可執行該特定作業. 例如，您的管道可能會自動啟動，但是需要手動操作才能[部署到生產中](../environments/index.html#configuring-manual-deployments) . 在下面的示例中， `production`階段有一個需要手動操作的工作. [![Pipelines example](https://img.kancloud.cn/91/f0/91f0f61186f54d29097f6625d03c37d7_931x153.png)](img/pipelines.png) #### Start multiple manual actions in a stage[](#start-multiple-manual-actions-in-a-stage "Permalink") 在 GitLab 11.11 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/27188) . 可以使用"全部播放手動"按鈕同時啟動一個階段中的多個手動動作. 用戶單擊此按鈕后，將觸發每個單獨的手動操作并將其刷新為更新狀態. 此功能僅可用： * 至少具有開發者訪問權限的用戶. * 如果階段包含[手動操作](#add-manual-interaction-to-your-pipeline) . ### Delete a pipeline[](#delete-a-pipeline "Permalink") 在 GitLab 12.7 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/24851) . 在項目中具有[所有者權限的](../../user/permissions.html)用戶可以通過以下方式刪除管道：單擊**CI / CD>管道中的管道**以轉到" **管道詳細信息"**頁面，然后使用" **刪除"**按鈕. [![Pipeline Delete Button](https://img.kancloud.cn/fa/f8/faf816bdcdcd0cda925a2a5f381e707f_2284x134.png)](img/pipeline-delete.png) **警告：**刪除管道將使所有管道緩存失效，并刪除所有相關對象，例如構建，日志，工件和觸發器. **此操作無法撤消.** ### Pipeline quotas[](#pipeline-quotas "Permalink") 每個用戶都有一個個人管道配額，該配額跟蹤所有個人項目中共享運行者的使用情況. 每個組都有一個[使用配額](../../subscriptions/index.html#ci-pipeline-minutes) ，該[配額](../../subscriptions/index.html#ci-pipeline-minutes)跟蹤該組內創建的所有項目的共享運行器的使用. 觸發管道時，無論是誰觸發的，都會使用項目所有者的[名稱空間](../../user/group/index.html#namespaces)的管道配額. 在這種情況下，名稱空間可以是擁有項目的用戶或組. #### How pipeline duration is calculated[](#how-pipeline-duration-is-calculated "Permalink") 給定管道的總運行時間不包括重試和掛起（排隊）時間. 每個作業都表示為一個`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 ``` ### Pipeline security on protected branches[](#pipeline-security-on-protected-branches "Permalink") 在[受保護的分支](../../user/project/protected_branches.html)上執行管道時，將強制執行嚴格的安全模型. 僅當[允許](../../user/project/protected_branches.html#using-the-allowed-to-merge-and-allowed-to-push-settings)用戶[合并或推送到](../../user/project/protected_branches.html#using-the-allowed-to-merge-and-allowed-to-push-settings)該特定分支時，才可以在受保護的分支上執行以下操作： * 運行手動管道（使用[Web UI](#run-a-pipeline-manually)或[管道 API](#pipelines-api) ）. * 運行預定的管道. * 使用觸發器運行管道. * 在現有管道上觸發手動操作. * 重試或取消現有作業（使用 Web UI 或管道 API）. 標記為**受保護的** **變量**只能由在受保護的分支上運行的作業訪問，從而防止不受信任的用戶意外訪問敏感信息，如部署憑據和令牌. **運動員**標記為**保護**只能保護分支機構運行的作業，防止不可信代碼在受保護亞軍執行和不小心被訪問保護部署密鑰和其它憑證. 為了確保打算在受保護的運行程序上執行的作業不會使用常規運行程序，必須對它們進行相應標記. ## View jobs in a pipeline[](#view-jobs-in-a-pipeline "Permalink") 訪問管道時，可以看到該管道的相關作業. 單擊單個作業將向您顯示其作業日志，并允許您： * 取消作業. * 重試該作業. * 刪除作業日志. ### See why a job failed[](#see-why-a-job-failed "Permalink") 在 GitLab 10.7 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17782) . 當管道發生故障或被允許失敗時，可以在幾個地方找到原因： * 在[管道圖中](#visualize-pipelines) ，在管道詳細信息視圖上. * 在管道小部件中，在合并請求和提交頁面中. * 在工作視圖中，在工作的全局視圖和詳細視圖中. 在每個地方，如果將鼠標懸停在失敗的作業上，都可以看到失敗的原因. [![Pipeline detail](https://img.kancloud.cn/f0/f9/f0f95f09bd36d9180bd27be76a677a5d_237x139.png)](img/job_failure_reason.png) 在[GitLab 10.8](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17814)及更高版本中，您還可以在"作業詳細信息"頁面上查看其失敗的原因. ### The order of jobs in a pipeline[](#the-order-of-jobs-in-a-pipeline "Permalink") 管道中作業的順序取決于管道圖的類型. * 對于[常規管道圖](#regular-pipeline-graphs) ，按名稱對作業進行排序. * 對于[管道微型圖](#pipeline-mini-graphs) ，將按嚴重性然后按名稱對作業進行排序. 嚴重性順序為： * failed * warning * pending * running * manual * scheduled * canceled * success * skipped * created 例如： [![Pipeline mini graph sorting](https://img.kancloud.cn/1e/f9/1ef908aa27d34db6da01d746b8ea26f7_478x270.png)](img/pipelines_mini_graph_sorting.png) ### Group jobs in a pipeline[](#group-jobs-in-a-pipeline "Permalink") 在 GitLab 8.12 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/6242) . 如果您有許多類似的工作，則[管道圖](#visualize-pipelines)將變得很長且難以閱讀. 您可以自動將相似的作業分組在一起. 如果以某種方式格式化作業名稱，它們將在常規管道圖（而不是迷你圖）中折疊為一組. 如果看不到管道中的重試或取消按鈕，您將知道管道何時將其分組. 將鼠標懸停在它們上面將顯示分組的作業數. 單擊以展開它們. [![Grouped pipelines](https://img.kancloud.cn/29/49/2949b3134ff396642c9acbb8f737c518_910x294.png)](img/pipelines_grouped.png) 要創建一組作業，請在[CI / CD 管道配置文件中](../yaml/README.html) ，用數字和以下其中一個分隔每個作業名稱： * 斜線（ `/` ），例如`test 1/3` ， `test 2/3` ， `test 3/3` . * 冒號（ `:` ）中，例如， `test 1:3` ， `test 2:3` ， `test 3:3` . * 一個空格，例如`test 0 3` ， `test 1 3` ， `test 2 3` . 您可以互換使用這些符號. 例如，這三個作業將在一個名為`build ruby`的組中： ``` build ruby 1/3: stage: build script: - echo "ruby1" build ruby 2/3: stage: build script: - echo "ruby2" build ruby 3/3: stage: build script: - echo "ruby3" ``` 在管道中，結果是一個名為`build ruby`的組，具有三個作業： [![Job group](https://img.kancloud.cn/5b/75/5b750ec5bc4875797c40fdb2e4b6743e_406x244.png)](img/job_group_v12_10.png) 作業將通過從左到右比較數字進行排序. 通常，您希望第一個數字為索引，第二個數字為總數. [此正則表達式](https://gitlab.com/gitlab-org/gitlab/blob/2f3dc314f42dbd79813e6251792853bc231e69dd/app/models/commit_status.rb#L99)計算作業名稱： `\d+[\s:\/\\]+\d+\s*` . ### Specifying variables when running manual jobs[](#specifying-variables-when-running-manual-jobs "Permalink") 在 GitLab 12.2 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/30485) . 運行手動作業時，您可以提供其他特定于作業的變量. 您可以從要運行其他變量的手動作業的作業頁面執行此操作. 要訪問此頁面，請在管道視圖中單擊手動作業的**名稱** ， *而不是*播放（）按鈕. 當您想要更改使用[自定義環境變量](../variables/README.html#custom-environment-variables)的作業的執行時，這很有用. 在此處添加變量名稱（鍵）和值將覆蓋[UI 或`.gitlab-ci.yml`](../variables/README.html#custom-environment-variables)定義的值，以供手動運行一次. [![Manual job variables](https://img.kancloud.cn/19/49/194990abbaa86d139731707d693efc05_3354x1588.png)](img/manual_job_variables.png) ### Delay a job[](#delay-a-job "Permalink") 在 GitLab 11.4 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/21767) . 當您不想立即運行作業時，可以使用[`when:delayed`](../yaml/README.html#whendelayed)參數將作業的執行延遲一定時間. 這對于定時增量式部署特別有用，在這種情況下，新代碼將逐步推出. 例如，如果您開始推出新代碼并執行以下操作： * 用戶不會遇到麻煩，GitLab 可以從 0％到 100％自動完成部署. * 用戶在使用新代碼時會遇到麻煩，您可以通過取消管道并[回滾](../environments/index.html#retrying-and-rolling-back)到最后一個穩定版本來停止定時增量推出. [![Pipelines example](https://img.kancloud.cn/70/03/70037c61935f36f9d8e391e0f1199616_973x99.png)](img/pipeline_incremental_rollout.png) ### Expand and collapse job log sections[](#expand-and-collapse-job-log-sections "Permalink") 在 GitLab 12.0 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/14664) . 作業日志分為可折疊或擴展的部分. 每個部分將顯示持續時間. 在以下示例中： * 兩個部分已折疊并且可以展開. * 三個部分被展開并且可以折疊. [![Collapsible sections](https://img.kancloud.cn/f6/1a/f61a49122484a9a57165cb4ccbcb8550_1771x933.png)](img/collapsible_log_v12_6.png) #### Custom collapsible sections[](#custom-collapsible-sections "Permalink") 您可以通過手動輸出特殊代碼來在作業日志中創建可折疊部分，GitLab 將使用這些特殊代碼來確定要折疊的部分： * 節開始標記： `section_start:UNIX_TIMESTAMP:SECTION_NAME\r\e[0K` + `TEXT_OF_SECTION_HEADER` * 節結束標記： `section_end:UNIX_TIMESTAMP:SECTION_NAME\r\e[0K` 您必須將這些代碼添加到 CI 配置的腳本部分. 例如，使用`echo` ： ``` job1: script: - echo -e "section_start:`date +%s`:my_first_section\r\e[0KHeader of the 1st collapsible section" - echo 'this line should be hidden when collapsed' - echo -e "section_end:`date +%s`:my_first_section\r\e[0K" ``` 在上面的示例中： * `date +%s` ：Unix 時間戳（例如`1560896352` ）. * `my_first_section` ：為節指定的名稱. * `\r\e[0K` ：阻止區域標記顯示在渲染的（彩色）作業日志中，但它們顯示在原始作業日志中. 要查看它們，請在作業日志的右上方，單擊（ **顯示完整的原始文件** ）. * `\r` ：回車. * `\e[0K` ：清除 ANSI 轉義代碼. 原始作業日志樣本： ``` section_start:1560896352:my_first_section\r\e[0KHeader of the 1st collapsible section this line should be hidden when collapsed section_end:1560896353:my_first_section\r\e[0K ``` ## Visualize pipelines[](#visualize-pipelines "Permalink") 在 GitLab 8.11 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/5742) . 管道可以是具有許多順序和并行作業的復雜結構. 為了更容易理解管道的流程，GitLab 提供了管道圖來查看管道及其狀態. 管道圖可以兩種不同的方式顯示，具體取決于您從中訪問該圖的頁面. **注意：** GitLab 在管線圖中將各階段的名稱大寫. ### Regular pipeline graphs[](#regular-pipeline-graphs "Permalink") 常規管道圖顯示每個階段的作業名稱. 當您在[單個管道頁面](#view-pipelines)上時，可以找到常規管道圖. 例如： [![Pipelines example](https://img.kancloud.cn/91/f0/91f0f61186f54d29097f6625d03c37d7_931x153.png)](img/pipelines.png) [多項目管道圖可](../multi_project_pipelines.html#multi-project-pipeline-visualization-premium)幫助您可視化整個管道，包括所有跨項目的相互依存關系. ### Pipeline mini graphs[](#pipeline-mini-graphs "Permalink") 管道微型圖占用的空間更少，并且可以一眼告訴您所有作業都通過還是失敗. 當您導航到以下位置時，可以找到管道迷你圖： * 管道索引頁面. * 單個提交頁面. * 合并請求頁面. 管道微型圖使您可以查看一次提交的所有相關作業以及管道每個階段的最終結果. 這使您可以快速查看失敗的原因并進行修復. 管道微型圖中的階段是可折疊的. 將鼠標懸停在他們上方，然后單擊以展開他們的工作. | 迷你圖 | 迷你圖展開 | | --- | --- | | [![Pipelines mini graph](https://img.kancloud.cn/00/73/007321185461f71945d16e0edde8392f_135x67.png)](img/pipelines_mini_graph_simple.png) | [![Pipelines mini graph extended](https://img.kancloud.cn/b8/9c/b89cfe82bc51934833668e936a6e6426_299x187.png)](img/pipelines_mini_graph.png) | ### Pipeline success and duration charts[](#pipeline-success-and-duration-charts "Permalink") 版本歷史 * 在 GitLab 3.1.1 中作為"提交統計信息"引入，后來更名為"管線圖". * 在 GitLab 12.8 中[重命名](https://gitlab.com/gitlab-org/gitlab/-/issues/38318)為 CI / CD Analytics. GitLab 跟蹤您的管道成功與失敗的歷史記錄，以及每個管道的運行時間. 要查看此信息，請轉到**分析> CI / CD 分析** . 查看成功的管道： [![Successful pipelines](https://img.kancloud.cn/ca/39/ca392cd0051108ab1413be688fbbd74c_1226x368.png)](img/pipelines_success_chart.png) 查看管道持續時間歷史記錄： [![Pipeline duration](https://img.kancloud.cn/0a/2f/0a2f7aa04a22bc903cb58fda4fd37c41_589x316.png)](img/pipelines_duration_chart.png) ### Pipeline badges[](#pipeline-badges "Permalink") 管道狀態和測試覆蓋率報告標記可用于每個項目，并可對其進行配置. 有關將管道標記添加到項目的信息，請參見[管道標記](settings.html#pipeline-badges) . ## Pipelines API[](#pipelines-api "Permalink") GitLab 提供 API 端點以： * 執行基本功能. 有關更多信息，請參見[Pipelines API](../../api/pipelines.html) . * 維護管道時間表. 有關更多信息，請參見[管道時間表 API](../../api/pipeline_schedules.html) . * 觸發管道運行. 有關更多信息，請參見： * [通過 API 觸發管道](../triggers/README.html) . * [管道觸發器 API](../../api/pipeline_triggers.html) . ## Troubleshooting `fatal: reference is not a tree:`[](#troubleshooting-fatal-reference-is-not-a-tree "Permalink") 在 GitLab 12.4 中[引入](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/17043) . 以前，當您強制將分支推入其遠程存儲庫時，會遇到意外的管道故障. 為了說明問題，假設您已經擁有當前的工作流程： 1. 用戶創建一個名為`example`的功能分支并將其推送到遠程存儲庫. 2. 新的管道開始在`example`分支上運行. 3. 用戶將`example`分支基于最新的`master`分支，然后將其強制推送到其遠程存儲庫. 4. 新的管道再次在`example`分支上運行，但是，先前的管道（2）由于`fatal: reference is not a tree:`錯誤`fatal: reference is not a tree:`失敗. 這是因為先前的管道無法從`example`分支中找到校驗歷史 SHA（與管道記錄相關聯），該歷史歷史已被強制推送覆蓋. 同樣，由于[相同的原因](../merge_request_pipelines/pipelines_for_merged_results/index.html#intermittently-pipelines-fail-by-fatal-reference-is-not-a-tree-error) [，合并結果的管道](../merge_request_pipelines/pipelines_for_merged_results/index.html)可能會間歇性地失敗. 從 GitLab 12.4 開始，我們通過專門保留管道引用來改善了這種行為. 為了說明其生命周期： 1. 在名為`example`的功能分支上創建了管道. 2. 在`refs/pipelines/<pipeline-id>`創建一個持久的管道 ref，該`refs/pipelines/<pipeline-id>`保留相關管道記錄的 checkout-SHA. 即使在`example`分支的提交歷史記錄已被強制推送覆蓋的情況下，該持久引用在管道執行期間也保持不變. 3. GitLab Runner fetches the persistent pipeline ref and gets source code from the checkout-SHA. 4. 管道完成后，將在后臺進程中清除其持久引用.