大型產品有數個彼此相依的元件。 這些元件通常會獨立建置。 當上游元件（例如連結庫）變更時，必須重建和重新驗證下游相依性。

在這些情況下，當 觸發管線 順利完成時，新增一個管線觸發器以執行你的管線。

先前，您可能已流覽至 YAML 管線的經典編輯器，並在 UI 中設定 建置完成觸發條件 。 雖然該模型仍可運作，但已不再建議使用。 建議的方法是直接在 YAML 檔案內指定 管線觸發 。 在傳統編輯器中定義的建置完成觸發程式有各種缺點，這些缺點現在已在管線觸發程式中解決。 例如，沒有任何方法可以使用建置完成觸發器在與觸發管線相同的分支上觸發一條管道。

使用管線設定 UI 定義的觸發程式優先於 YAML 觸發程式。 若要從 YAML 管線刪除 UI 排程觸發器，請參閱 UI 設定覆寫 YAML 排程觸發器 。

設定管道資源觸發器

若要在另一個管線完成時觸發管線，請設定 管線資源 啟動機制。

下例設定管線資源觸發條件，使名為 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 登陸頁面。 根據預設，管線會以包含管線的存放庫命名。 若要更新管線的名稱，請參閱管線設定。 如果管線包含在資料夾中，請包含資料夾名稱，包括前置 \，例如 \security pipelines\security-lib-ci。
              project: FabrikamProject - 如果觸發管線位於另一個 Azure DevOps 專案中，您必須指定項目名稱。 如果來源管線和觸發的管線都位於相同的專案中，這個屬性是選擇性的。 如果您指定此值，且管線未觸發，請參閱本節結尾的附注。
              trigger: true - 使用此語法以在源管線的任一版本完成後觸發管線。 請參閱本文中的下列各節，以瞭解如何篩選哪些完成的來源管線版本將觸發執行。 指定篩選條件時，來源管線執行必須符合所有篩選條件，才能觸發執行。
如果觸發管線與被觸發的管線使用相同的存放庫，當其中一個觸發另一個時，兩個管線都會使用相同的提交版本來執行。 這會很有幫助，如果您的第一個管線會建置程式碼，而第二個管線會加以測試。 不過，如果兩個管線使用不同的存放庫，觸發的管線將會使用 Default branch for manual and scheduled builds 設定所指定分支中的程式碼版本，詳情請參閱管線完成觸發的分支考量。
在某些情況下，手動建置和排程建置的預設分支不包含 refs/heads 作為前綴。 例如，預設分支可能會設定為 main，而不是設定為 refs/heads/main。 在此案例中，來自不同專案的觸發器無法運作。 如果您在將 project 設定為目標管線以外的值時遇到問題，您可以將預設分支的值變更為不同的分支，然後將它變更回您想要使用的預設分支，以包含 refs/heads。
YAML 範本不支援配置管線完成觸發器。 您仍然可以在範本中定義管線資源。
您可以選擇性地指定要在設定觸發程式時包含或排除的分支。 如果您指定分支篩選，每當來源管線執行順利完成且符合分支篩選條件時，就會觸發新的管線。 在下列範例中，如果 app-ci 在任何 security-lib-ci 分支上完成，releases/* 管線就會執行，但 releases/old*除外。
# app-ci YAML pipeline
resources:
  pipelines:
  - pipeline: securitylib
    source: security-lib-ci
    trigger: 
      branches:
        include: 
        - releases/*
        exclude:
        - releases/old*
若要針對觸發父系的不同分支觸發子管線，請包含觸發父系的所有分支篩選。 在以下範例中，如果 app-ci 在任何 security-lib-ci 分支或主分支上完成時，releases/* 管線就會執行，但不包括 releases/old*。
# app-ci YAML pipeline
resources:
  pipelines:
  - pipeline: securitylib
    source: security-lib-ci
    trigger: 
      branches:
        include: 
        - releases/*
        - main
        exclude:
        - releases/old*
如果您的分支篩選無法運作，請嘗試使用前綴 refs/heads/。 例如，使用 refs/heads/releases/old*，而不是使用 releases/old*。
              標籤篩選對管線資源的支援 需要 Azure DevOps Server 2020 Update 1 或更新版本。

              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 屬性用於判斷要從哪一次管線執行中擷取工件。 如需詳細資訊，請參閱 資源：管線 和 成品版本的評估。
              用於管線資源觸發的階段篩選器 需要 Azure DevOps Server 2020 Update 1 或更新版本。

根據預設，只有在來源管線完成時，才會觸發目標管線。 如果您的來源管線中有不同階段，您可以透過設定包含一或多個階段的 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 觸發程式的篩選條件，就會啟動新的執行。此外，當來源管線的執行完成且符合管線完成觸發程式的篩選條件時，也會啟動新的執行。
例如，假設兩個名為 A 和 B 的管線位於相同存放庫中，兩者都有 CI 觸發程式，而且 B 已設定管線完成觸發程式，以完成管線 A。 在您將內容推送至存放庫時：
會根據其 CI 觸發程序啟動新的 A 回合。
同時，會根據其 CI 觸發程序啟動新的 B 回合。 此運行會從先前的管線運行 A中取用產物。
當 A 完成時，它會根據 B中的管道完成觸發機制，啟動 B的新執行。
若要防止在此範例中觸發兩次執行 B，您必須停用其 CI 觸發器（trigger: none）或管線觸發器（pr: none）。
              已排程的觸發程序

              傳統管道觸發程序

              傳統發行觸發機制