Multi-project pipelines · Gitlab 中文文檔

# Multi-project pipelines > 原文：[https://docs.gitlab.com/ee/ci/multi_project_pipelines.html](https://docs.gitlab.com/ee/ci/multi_project_pipelines.html) * [Use cases](#use-cases) * [Multi-project pipeline visualization](#multi-project-pipeline-visualization-premium) * [Triggering multi-project pipelines through API](#triggering-multi-project-pipelines-through-api) * [Creating multi-project pipelines from `.gitlab-ci.yml`](#creating-multi-project-pipelines-from-gitlab-ciyml) * [Triggering a downstream pipeline using a bridge job](#triggering-a-downstream-pipeline-using-a-bridge-job) * [Specifying a downstream pipeline branch](#specifying-a-downstream-pipeline-branch) * [Passing variables to a downstream pipeline](#passing-variables-to-a-downstream-pipeline) * [Mirroring status from triggered pipeline](#mirroring-status-from-triggered-pipeline) * [Mirroring status from upstream pipeline](#mirroring-status-from-upstream-pipeline) * [Limitations](#limitations) * [Trigger a pipeline when an upstream project is rebuilt](#trigger-a-pipeline-when-an-upstream-project-is-rebuilt) # Multi-project pipelines[](#multi-project-pipelines "Permalink") 版本歷史 * 在 GitLab 7.14 中作為構建觸發器[引入](https://about.gitlab.com/releases/2015/08/22/gitlab-7-14-released/#build-triggers-api-gitlab-ci) . * 在 GitLab 12.8 中的所有層中[均可](https://gitlab.com/gitlab-org/gitlab/-/issues/199224)用. 您可以跨多個項目設置[GitLab CI / CD](README.html) ，以便一個項目中的管道可以觸發另一個項目中的管道. GitLab CI / CD 是一個功能強大的持續集成工具，不僅適用于每個項目，而且適用于具有多項目管道的項目. 多項目管道對于需要跨項目相互依賴的較大產品很有用，例如采用[微服務架構的產品](https://about.gitlab.com/blog/2016/08/16/trends-in-version-control-land-microservices/) . 有關跨功能開發團隊如何使用跨管道觸發來為不同的微服務項目觸發多個管道的演示，請參閱[跨項目管道觸發和可視化](https://about.gitlab.com/handbook/marketing/product-marketing/demo/#cross-project-pipeline-triggering-and-visualization-may-2019---1110) . 此外，還可以可視化整個管道，包括所有跨項目的相互依存關系. ## Use cases[](#use-cases "Permalink") Let’s assume you deploy your web app from different projects in GitLab: * 一個免費版本，它有自己的管道來構建和測試您的應用 * 一個用于付費版本的附加組件，還可以通過構建和測試 * 一個用于文檔的文檔，該文檔還使用 SSG 進行構建，測試和部署使用多項目管道，您可以可視化整個管道，包括三個項目的所有構建和測試階段. ## Multi-project pipeline visualization[](#multi-project-pipeline-visualization-premium "Permalink") [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/2121) in [GitLab Premium 9.3](https://about.gitlab.com/releases/2017/06/22/gitlab-9-3-released/#multi-project-pipeline-graphs). 為項目配置 GitLab CI / CD 時，可以在[管道圖](pipelines/index.html#visualize-pipelines)上可視化[作業](pipelines/index.html#configure-a-pipeline)的階段. [![Multi-project pipeline graph](https://img.kancloud.cn/8f/5d/8f5d72545035b93968cdd0e909bffa23_1049x322.png)](img/multi_project_pipeline_graph.png) 在"合并請求"小組件中，將顯示多項目管道微型圖，并且當懸停或輕擊（在觸摸屏設備上）時，它們將展開并顯示為彼此相鄰. [![Multi-project mini graph](https://img.kancloud.cn/8d/23/8d2322f50c898b9b527ee820e7cce538_259x115.png)](img/multi_pipeline_mini_graph.gif) ## Triggering multi-project pipelines through API[](#triggering-multi-project-pipelines-through-api "Permalink") 版本歷史 * 在[GitLab Premium](https://about.gitlab.com/pricing/) 9.3 中[引入](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/2017)了`CI_JOB_TOKEN`在多項目管道中的使用. * 在 GitLab 12.4 的所有層中都[可以](https://gitlab.com/gitlab-org/gitlab/-/issues/31573)將`CI_JOB_TOKEN`用于多項目管道. 當您使用[`CI_JOB_TOKEN`觸發管道時](triggers/README.html#ci-job-token) ，GitLab 會識別作業令牌的來源，因此在內部將這些管道[`CI_JOB_TOKEN`](triggers/README.html#ci-job-token)在一起，從而可以在管道圖上可視化它們的關系. 通過顯示上游和下游管道依存關系的入站和出站連接，可以在管道圖中顯示這些關系. ## Creating multi-project pipelines from `.gitlab-ci.yml`[](#creating-multi-project-pipelines-from-gitlab-ciyml "Permalink") 版本歷史 * 在[GitLab Premium](https://about.gitlab.com/pricing/) 11.8 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/8997) . * 在 12.8 中[可](https://gitlab.com/gitlab-org/gitlab/-/issues/199224)用于所有層. ### Triggering a downstream pipeline using a bridge job[](#triggering-a-downstream-pipeline-using-a-bridge-job "Permalink") 在 GitLab 11.8 之前，有必要實現一個管道作業，該作業負責發出 API 請求[以觸??發](#triggering-multi-project-pipelines-through-api)另一個項目中[的管道](#triggering-multi-project-pipelines-through-api) . 在 GitLab 11.8 中，GitLab 提供了新的 CI / CD 配置語法，使此任務更容易，并且避免需要 GitLab Runner 來觸發跨項目管道. 下圖說明了配置橋接作業： ``` rspec: stage: test script: bundle exec rspec staging: variables: ENVIRONMENT: staging stage: deploy trigger: my/deployment ``` 在上面的示例中，一旦`rspec`作業在`test`階段成功完成，則將啟動`staging`橋作業. 該作業的初始狀態將`pending` . manbetx 客戶端打不開將在`my/deployment`項目中創建一個下游管道，并且，一旦創建管道， `staging`作業將成功. `my/deployment`是該項目的完整路徑. 創建上游管道的用戶需要具有對下游項目的訪問權限（在本例中為`my/deployment` ）. 如果找不到下游項目，或者用戶沒有訪問權限以在其中創建管道，則`staging`作業將被標記為*failed* . **警告：**在該示例中，一旦創建了下游管道，該`staging`將被標記為成功. 如果要顯示下游管道的狀態，請參閱[從觸發的管道鏡像狀態](#mirroring-status-from-triggered-pipeline) .**注意：**對于常規作業，網橋作業不支持用戶可以使用的每個配置條目. Runner 不會選擇 Bridge 作業，因此添加對`script`支持毫無意義. 如果用戶嘗試使用不受支持的配置語法，則在創建管道時，YAML 驗證將失敗. ### Specifying a downstream pipeline branch[](#specifying-a-downstream-pipeline-branch "Permalink") 可以指定下游管道將使用的分支名稱： ``` rspec: stage: test script: bundle exec rspec staging: stage: deploy trigger: project: my/deployment branch: stable-11-2 ``` Use: * `project`關鍵字，用于指定下游項目的完整路徑. * 該`branch`關鍵字指定由指定的項目分支的名稱`project` . [從 GitLab 12.4 開始](https://gitlab.com/gitlab-org/gitlab/-/issues/10126) ，支持變量擴展. 在創建下游管道時，GitLab 將使用當前在分支的 HEAD 上的提交. ### Passing variables to a downstream pipeline[](#passing-variables-to-a-downstream-pipeline "Permalink") 有時您可能想將變量傳遞到下游管道. 您可以使用`variables`關鍵字來執行此操作，就像定義常規作業時一樣. ``` rspec: stage: test script: bundle exec rspec staging: variables: ENVIRONMENT: staging stage: deploy trigger: my/deployment ``` `ENVIRONMENT`變量將傳遞到下游管道中定義的每個作業. 當 GitLab Runner 選擇工作時，它將作為環境變量使用. 在以下配置中， `MY_VARIABLE`變量將傳遞到在`trigger-downstream`作業排隊時創建的下游管道. 這是因為`trigger-downstream`作業繼承了在全局變量塊中聲明的變量，然后將這些變量傳遞到下游管道. ``` variables: MY_VARIABLE: my-value trigger-downstream: variables: ENVIRONMENT: something trigger: my/project ``` 您可能想使用例如預定義的變量傳遞有關上游管道的一些信息. 為此，您可以使用插值傳遞任何變量. 例如： ``` downstream-job: variables: UPSTREAM_BRANCH: $CI_COMMIT_REF_NAME trigger: my/project ``` 在這種情況下，具有與上游管道相關的值的`UPSTREAM_BRANCH`變量將傳遞到`downstream-job`作業，并在所有下游構建的上下文中可用. **提示：**上游管道優先于下游管道. 如果在上游和下游項目中定義了兩個具有相同名稱的變量，則在上游項目中定義的變量將優先. ### Mirroring status from triggered pipeline[](#mirroring-status-from-triggered-pipeline "Permalink") 版本歷史 * 在[GitLab Premium](https://about.gitlab.com/pricing/) 12.3 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/11238) . * 在 12.8 中[移至](https://gitlab.com/gitlab-org/gitlab/-/issues/199224) GitLab Core. 您可以使用`strategy: depend`將鏡像狀態從觸發的管道鏡像到源網橋作業. 例如： ``` trigger_job: trigger: project: my/project strategy: depend ``` ### Mirroring status from upstream pipeline[](#mirroring-status-from-upstream-pipeline "Permalink") 您可以使用`needs:pipeline`關鍵字將管道狀態從上游管道鏡像到橋作業. 來自主服務器的最新管道狀態將復制到橋接作業. Example: ``` upstream_bridge: stage: test needs: pipeline: other/project ``` ### Limitations[](#limitations "Permalink") 由于網橋作業與常規作業略有不同，因此此處無法使用完全相同的配置語法，就像在定義要由跑步者選擇的常規作業時通常使用的配置語法一樣. 某些功能尚未實現. 例如，對環境的支持. 可用于網橋作業的[配置關鍵字](yaml/README.html)是： * `trigger` （定義下游管道觸發器） * `stage` * `allow_failure` * [`rules`](yaml/README.html#rules) * `only` and `except` * `when` （僅適用于`on_success` ， `on_failure`和`always`值為） * `extends` ## Trigger a pipeline when an upstream project is rebuilt[](#trigger-a-pipeline-when-an-upstream-project-is-rebuilt "Permalink") [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/9045) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.8. You can trigger a pipeline in your project whenever a pipeline finishes for a new tag in a different project: 1. 轉到項目的**"設置">" CI / CD"**頁面，然后展開" **管道訂閱"**部分. 2. 輸入您要訂閱的項目的路徑. 3. 單擊訂閱. 現在，成功完成已訂閱項目中新標簽的任何管道都將在當前項目的默認分支上觸發管道. 對于上游和下游項目，上游管道訂閱的最大數量為 2.