觸發另一個管線

Azure DevOps Services |Azure DevOps Server 2020

大型產品有幾個彼此相依的元件。 這些元件通常會獨立建立。 當上游元件 (程式庫(例如) 變更)時,必須重建和重新驗證下游相依性。

在這類情況下,請新增管線觸發程式,以在成功完成 觸發管線時執行您的管線。

注意

先前,您可能已流覽至 YAML 管線的傳統編輯器,並在 UI 中設定 組建完成觸發 程式。 雖然該模型仍可運作,但不再建議使用。 建議的方法是直接在 YAML 檔中指定 管線觸發 程式。 如傳統編輯器中所定義的組建完成觸發程式有各種缺點,現在已在管線觸發程式中解決。 比方說,您無法在與使用組建完成觸發程式的觸發管線相同的分支上觸發管線。

設定管線資源觸發程式

若要在另一個管線完成時觸發管線,請設定 管線資源 觸發程式。

下列範例會設定管線資源觸發程式,以便在管線執行 security-lib-ci 之後,將會執行的管線 app-ci 完成。

此範例包含下列兩個管線。

  • security-lib-ci -此管線會先執行。

    # security-lib-ci YAML pipeline
    steps:
    - bash: echo "The security-lib-ci pipeline runs first"
    
  • app-ci -此管線有管線資源觸發程式,可將管線設定為在 app-ci 每次管線執行 security-lib-ci 完成時自動執行。

    # app-ci YAML pipeline
    # We are setting up a pipeline resource that references the security-lib-ci
    # pipeline and setting up a pipeline completion trigger so that our app-ci
    # pipeline runs when a run of the security-lib-ci pipeline completes
    resources:
      pipelines:
      - pipeline: securitylib # Name of the pipeline resource.
        source: security-lib-ci # The name of the pipeline referenced by this pipeline resource.
        project: FabrikamProject # Required only if the source pipeline is in another project
        trigger: true # Run app-ci pipeline when any run of security-lib-ci completes
    
    steps:
    - bash: echo "app-ci runs after security-lib-ci completes"
    
  • - pipeline: securitylib 指定管線資源的名稱。 從管線的其他部分參考管線資源時(例如,使用管線資源變數或下載成品時),請使用此處定義的標籤。
  • source: security-lib-ci 指定此管線資源所參考之管線的名稱。 您可以從 Azure DevOps 入口網站的數個位置(例如Pipelines 登陸頁面)取得管線的名稱。 根據預設,管線會在包含管線的存放庫之後命名。 若要更新管線的名稱,請參閱 管線設定
  • project: FabrikamProject-如果觸發管線是在另一個 Azure DevOps 專案中,您必須指定專案名稱。 如果來源管線和觸發的管線都在相同的專案中,則這個屬性是選擇性的。 如果您指定此值,但您的管線未觸發,請參閱本節結尾處的附注。
  • trigger: true -使用此語法,可在任何版本的來源管線完成時觸發管線。 請參閱本文中的下列各節,以瞭解如何篩選完成的來源管線版本將會觸發執行。 當指定篩選準則時,來源管線執行必須符合所有篩選準則,以觸發執行。

如果觸發管線和觸發的管線使用相同的存放庫,則這兩個管線會在觸發另一個管線時使用相同的認可來執行。 如果您的第一個管線會建立程式碼,而第二個管線進行測試,這會很有説明。 但是,如果這兩個管線使用不同的存放庫,則觸發的管線會使用設定所指定 Default branch for manual and scheduled builds 分支中的程式碼版本,如 管線完成觸發程式的分支考慮中所述。

注意

在某些情況下,手動組建和已排程組建的預設分支不包含 refs/heads 前置詞。 例如,預設分支可能會設定為 main ,而不是設定為 refs/heads/main 。 在此案例中, 來自不同專案的觸發程式無法運作。 如果您在設定 project 為目標管線以外的值時遇到問題,您可以將預設分支變更為不同的分支,然後將其變更回您要使用的預設分支,以將其包含在內 refs/heads

分支篩選

設定觸發程式時,您可以選擇性地指定要包含或排除的分支。 如果您指定分支篩選器,每當成功完成符合分支篩選的來源管線執行時,就會觸發新的管線。 在下列範例中, app-ci 如果在任何 releases/* 分支上完成,管線就會執行,但除外 releases/old*security-lib-ci

# app-ci YAML pipeline
resources:
  pipelines:
  - pipeline: securitylib
    source: security-lib-ci
    trigger: 
      branches:
        include: 
        - releases/*
        exclude:
        - releases/old*

注意

如果您的分支篩選器無法運作,請嘗試使用前置 refs/heads/ 詞。 例如,使用 refs/heads/releases/old* 取代 releases/old*

標記篩選

tags的屬性 trigger 會篩選哪些管線完成事件可以觸發您的管線。 如果觸發管線符合清單中 tags 的所有標記,管線就會執行。

resources:
  pipelines:
  - pipeline: MyCIAlias
    source: Farbrikam-CI
    trigger:
      tags:        # This filter is used for triggering the pipeline run
      - Production # Tags are AND'ed
      - Signed

注意

管線資源也有 tags 屬性。 tags當您以手動方式或由排程的觸發程式來觸發管線時,管線資源的屬性會用來判斷要從中取出成品的管線執行。 如需詳細資訊,請參閱 資源: 成品 版本的管線和評估。

階段篩選

您可以使用 stages 篩選器,在觸發管線的一或多個階段完成時觸發管線。 如果您提供多個階段,觸發的管線會在所有列出的階段完成時執行。

resources:
  pipelines:
  - pipeline: MyCIAlias  
    source: Farbrikam-CI  
    trigger:    
      stages:         # This stage filter is used when evaluating conditions for 
      - PreProduction # triggering your pipeline. On successful completion of all the stages
      - Production    # provided, your pipeline will be triggered. 

分支考慮

管線完成觸發程式會使用 [ 手動] 和 [排程的組建 ] 設定的預設分支,來決定要在判斷是否要在其他管線完成時執行管線時,所要評估的 YAML 管線分支篩選版本。 依預設,此設定會指向存放庫的預設分支。

當管線完成時,Azure DevOps 執行時間會使用參考已完成管線的管線完成觸發程式,評估任何管線的管線資源觸發程式分支篩選。 管線在不同的分支中可以有多個版本,因此執行時間會評估設定所指定 Default branch for manual and scheduled builds 分支中管線版本的分支篩選。 如果有相符的管線,管線就會執行,但執行的管線版本可能會在不同的分支中,取決於觸發的管線是否與已完成的管線位於相同的存放庫中。

  • 如果這兩個管線位於不同的存放庫中,則會執行指定 Default branch for manual and scheduled builds 之分支中的觸發管線版本。
  • 如果這兩個管線位於相同的存放庫中,則會執行與觸發管線相同之分支中的已觸發管線版本,即使該分支不同 Default branch for manual and scheduled builds ,也會執行,即使該版本沒有符合已完成管線之分支的分支篩選。 這是因為分支中的分支篩選準則 Default branch for manual and scheduled builds 是用來判斷是否應該執行管線,而不是已完成之管線分支中版本的分支篩選。

如果您的管線完成觸發程式似乎未引發,請針對觸發的管線檢查 [手動] 和 [排程的組建] 設定的 預設分支 的值。 該分支的管線版本中的分支篩選準則是用來判斷管線完成觸發程式是否會起始管線的執行。 依預設, Default branch for manual and scheduled builds 會設定為存放庫的預設分支,但您可以在建立管線之後變更它。

「管線完成」觸發程式不會引發的一般案例是在建立新分支時,會修改管線完成觸發程式分支篩選以包含這個新分支,但當第一個管線在符合新分支篩選準則的分支上完成時,第二個管線就不會觸發。 如果分支中 Default branch for manual and scheduled builds 的分支篩選準則與新分支不相符,就會發生這種情況。 若要解決此觸發程式問題,您有下列兩個選項。

  • 更新分支中管線內 Default branch for manual and scheduled builds 的分支篩選準則,使其符合新的分支。
  • 將 [ 手動] 和 [排程組建 ] 設定的預設分支,更新為具有與新分支相符之分支篩選的管線版本的分支。

合併觸發程式類型

當您在管線中同時指定 CI 觸發程式和管線觸發程式時,您可以預期每次進行推送時都必須啟動新的回合,使其符合 CI 觸發程式的篩選準則,並且完成來源管線的執行,以符合管線完成觸發程式的篩選準則。

例如,請考慮兩個名為 AB 的管線位於相同的存放庫中,兩者都有 CI 觸發程式,且 B 已針對完成管線 A 設定管線完成觸發程式。 如果您對存放庫進行推送:

  • 新的 A 執行會根據其 CI 觸發程式啟動。
  • 同時,也會根據其 CI 觸發程式來啟動新的 B 執行。 這項執行會從先前執行的管線 A 使用成品。
  • 完成時 A ,它會根據中 B 的管線完成觸發程式,觸發另一次執行 B

若要避免在此範例中觸發兩個執行 B ,您必須移除其 CI 觸發程式或管線觸發程式。