Parent-child pipelines · Gitlab 中文文檔

# Parent-child pipelines > 原文：[https://docs.gitlab.com/ee/ci/parent_child_pipelines.html](https://docs.gitlab.com/ee/ci/parent_child_pipelines.html) * [Examples](#examples) * [Merge Request child pipelines](#merge-request-child-pipelines) * [Dynamic child pipelines](#dynamic-child-pipelines) * [Limitations](#limitations) # Parent-child pipelines[](#parent-child-pipelines "Permalink") 在 GitLab 12.7 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/16094) . 隨著管道變得越來越復雜，一些相關的問題開始出現： * 分階段的結構（其中一個階段的所有步驟必須在下一階段的第一個作業開始之前完成）會導致任意等待，從而使事情變慢. * 單個全局管道的配置變得非常漫長和復雜，使其難以管理. * 使用[`include`](yaml/README.html#include)導入會增加配置的復雜性，并可能在無意間復制作業的情況下發生名稱空間沖突. * 如此多的工作和階段可以使流水線用戶體驗變得笨拙. 此外，有時管道的行為需要更動態. 選擇啟動（或不啟動）子管道的功能是一項強大的功能，尤其是在動態生成 YAML 的情況下. [![Parent pipeline graph expanded](https://img.kancloud.cn/3f/ea/3fea4f92fadb380bff42355a2b58dfd6_2500x882.png)](img/parent_pipeline_graph_expanded_v12_6.png) 與[多項目管道](multi_project_pipelines.html)類似，管道可以觸發一組同時運行的子管道，但是在同一項目中： * 子管道仍按階段順序執行其每個作業，但可以自由地繼續執行各個階段，而不必等待父管道中無關的作業完成. * 該配置分為較小的子管道配置，這些子管道配置更易于理解. 這減少了理解整體配置的認知負擔. * 導入在子管道級別進行，從而減少了發生沖突的可能性. * 每個管道只有相關的步驟，因此更容易理解正在發生的事情. 子管道可與其他 GitLab CI / CD 功能配合使用： * [`only: changes`](yaml/README.html#onlychangesexceptchanges)僅在某些文件更改時才觸發管道. 例如，這對于 monorepos 很有用. * 由于`.gitlab-ci.yml`的父管道和子管道都像普通管道一樣運行，因此它們可以具有自己的行為和與觸發器相關的順序. 所有這些都將與[`include:`](yaml/README.html#include)功能一起使用，因此您可以組成子管道配置. 有關概述，請參見[父子管道功能演示](https://youtu.be/n8KpBSqZNbk) . ## Examples[](#examples "Permalink") 最簡單的情況是使用本地 YAML 文件定義管道配置來[觸發子管道](yaml/README.html#trigger) . 在這種情況下，父管道將觸發子管道，并繼續運行而無需等待： ``` microservice_a: trigger: include: path/to/microservice_a.yml ``` 組成子管道時可以包含多個文件： ``` microservice_a: trigger: include: - local: path/to/microservice_a.yml - template: SAST.gitlab-ci.yml ``` **注意：** `trigger:include:`可接受的最大條目數為三. 類似于[多項目管道](multi_project_pipelines.html#mirroring-status-from-triggered-pipeline) ，我們可以在完成時將父管道設置為依賴于子管道的狀??態： ``` microservice_a: trigger: include: - local: path/to/microservice_a.yml - template: SAST.gitlab-ci.yml strategy: depend ``` ## Merge Request child pipelines[](#merge-request-child-pipelines "Permalink") 要將子管道觸發為[合并請求管道，](merge_request_pipelines/index.html)我們需要： * 將觸發器作業設置為在合并請求上運行： ``` # parent .gitlab-ci.yml microservice_a: trigger: include: path/to/microservice_a.yml rules: - if: $CI_MERGE_REQUEST_ID ``` * 通過以下任一方式配置子管道： * 設置子管道中的所有作業以在合并請求的上下文中進行評估： ``` # child path/to/microservice_a.yml workflow: rules: - if: $CI_MERGE_REQUEST_ID job1: script: ... job2: script: ... ``` * Alternatively, setting the rule per job. For example, to create only `job1` in the context of merge request pipelines: ``` # child path/to/microservice_a.yml job1: script: ... rules: - if: $CI_MERGE_REQUEST_ID job2: script: ... ``` ## Dynamic child pipelines[](#dynamic-child-pipelines "Permalink") 在 GitLab 12.9 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/35632) . 您可以定義一個作業，該作業運行您自己的腳本來生成 YAML 文件，而不是從靜態 YAML 文件運行子管道，然后將其[用于觸發子管道](yaml/README.html#trigger-child-pipeline-with-generated-configuration-file) . 該技術在生成針對更改內容的流水線或構建目標和體系結構矩陣方面可能非常強大. 有關概述，請參閱[使用動態生成的配置創建子管道](https://youtu.be/nMdfus2JWHM) . 在 GitLab 12.9 中，在某些情況下可能無法創建子管道，從而導致父管道失敗. 這[在 GitLab 12.10 中](https://gitlab.com/gitlab-org/gitlab/-/issues/209070)已[解決](https://gitlab.com/gitlab-org/gitlab/-/issues/209070) . ## Limitations[](#limitations "Permalink") 父管道可以觸發許多子管道，但是子管道不能觸發其他子管道. 請參閱[相關問題，](https://gitlab.com/gitlab-org/gitlab/-/issues/29651)以獲取有關未來可能改進的討論.