依次觸發管線
Azure DevOps Services |Azure DevOps Server 2022 |Azure DevOps Server 2020
大型產品有數個彼此相依的元件。 這些元件通常會獨立建置。 當上游元件(例如連結庫)變更時,必須重建和重新驗證下游相依性。
在這些情況下,在順利完成 觸發管線時,新增管線觸發程式以執行管線。
註記
先前,您可能已流覽至 YAML 管線的經典編輯器,並在 UI 中設定 建置完成觸發條件。 雖然該模型仍可運作,但已不再建議使用。 建議的方法是直接在 YAML 檔案內指定 管線觸發。 在傳統編輯器中定義的建置完成觸發程式有各種缺點,這些缺點現在已在管線觸發程式中解決。 例如,沒有任何方法可以使用建置完成觸發器在與觸發管線相同的分支上觸發一條管道。
使用管線設定 UI 定義的觸發程式優先於 YAML 觸發程式。 若要從 YAML 管線刪除 UI 排程觸發程式,請參閱 UI 設定覆寫 YAML 排程的觸發程式。
設定管線資源觸發程式
若要在另一個管線完成時觸發管線,請設定 管線資源 啟動機制。
下例設定管線資源觸發條件,使名為 app-ci
的管線在 security-lib-ci
管線的每次執行完成後執行。
此範例有下列兩個管線。
security-lib-ci
- 此流程會先執行。# security-lib-ci YAML pipeline steps: - bash: echo "The security-lib-ci pipeline runs first"
app-ci
- 此管線具有管線資源觸發程式,可在每次執行security-lib-ci
管線完成時,將app-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 範本不支援配置管線完成觸發器。 您仍然可以在範本中定義管線資源。
分支篩選
您可以選擇性地指定要在設定觸發程式時包含或排除的分支。 如果您指定分支篩選,每當來源管線執行順利完成且符合分支篩選條件時,就會觸發新的管線。 在下列範例中,如果 security-lib-ci
在任何 releases/*
分支上完成,app-ci
管線就會執行,但 releases/old*
除外。
# app-ci YAML pipeline
resources:
pipelines:
- pipeline: securitylib
source: security-lib-ci
trigger:
branches:
include:
- releases/*
exclude:
- releases/old*
若要針對觸發父系的不同分支觸發子管線,請包含觸發父系的所有分支篩選。 在以下範例中,如果 security-lib-ci
在任何 releases/*
分支或主分支上完成時,app-ci
管線就會執行,但不包括 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*
。
標籤篩選
注意
trigger
的 tags
屬性會篩選管線完成事件可以觸發管線。 如果觸發管線滿足 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
階段篩選
注意
當觸發管線的其中一個或多個階段完成並使用 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
)。