YAML 管線中的資源
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
本文討論 YAML 管線的資源。 資源是管線外部所使用的任何專案。 定義資源之後,您可以在管線中的任何位置取用資源。
資源可為管線所使用的服務提供完整的可追蹤性,包括版本、成品、相關聯的認可和工作專案。 您可以訂閱以在資源上觸發事件,以完全自動化DevOps工作流程。
資源架構
YAML 中的資源代表管線、組建、存放庫、容器、套件和 Webhook 的來源。 如需完整的架構資訊,請參閱 Azure Pipelines YAML 架構參考中的資源定義。
當資源觸發管線時,會設定下列變數:
resources.triggeringAlias
resources.triggeringCategory
變數 Build.Reason
必須 ResourceTrigger
供這些值設定。 如果資源未觸發管線執行,這些值會是空的。
管線資源定義
如果您有產生成品的管線,您可以藉由定義 pipelines
資源來取用成品。 只有 Azure Pipelines 可以使用 pipelines
資源。 您可以在管線資源上設定持續部署 (CD) 工作流程的觸發程式。
在您的資源定義中,是一個唯一值, pipeline
您可以在稍後的管線中參考管線資源。 source
是產生管線成品的管線名稱。 如需完整的架構資訊,請參閱 resources.pipelines.pipeline 定義。
您可以使用 所 pipeline
定義的標籤,從管線的其他部分參考管線資源,例如使用管線資源變數或下載成品時。 如需下載管線成品的替代方式,請參閱 下載成品。
重要
當您定義管線資源觸發程式時:
pipeline
如果資源來自與目前管線相同的存放庫,或self
,觸發會遵循引發事件的相同分支並認可。- 如果管線資源來自不同的存放庫,則目前的管線會在資源存放庫的預設分支
pipeline
上觸發。
範例管線資源定義
下列範例會從相同專案中的管線取用成品。
resources:
pipelines:
- pipeline: SmartHotel-resource # identifier to use in pipeline resource variables
source: SmartHotel-CI # name of the pipeline that produces the artifacts
若要從另一個專案取用管線,請包含專案名稱和來源名稱。 下列範例會使用 branch
,在手動或排程觸發管線時解析預設版本。 分支輸入不能有通配符。
resources:
pipelines:
- pipeline: SmartHotel
project: DevOpsProject
source: SmartHotel-CI
branch: releases/M142
下列範例顯示具有簡單觸發程式的管線資源。
resources:
pipelines:
- pipeline: SmartHotel
project: DevOpsProject
source: SmartHotel-CI
trigger: true
下列範例顯示具有分支條件的管線資源 trigger
。
resources:
pipelines:
- pipeline: SmartHotel
project: DevOpsProject
source: SmartHotel-CI
trigger:
branches:
- releases/*
- resources.triggeringAlias
下列範例會使用 stages
篩選條件來評估CD管線的觸發條件。 階段會使用 AND
運算符。 成功完成所有提供階段時,CD 管線會觸發。
resources:
pipelines:
- pipeline: MyCIAlias
project: Fabrikam
source: Farbrikam-CI
trigger:
stages:
- PreProduction
- Production
下列範例會針對預設版本評估及觸發程式使用 tags
篩選。 標記會 AND
使用運算符。
tags
會在持續整合 (CI) 或 CD 管線上設定 。 這些標籤與 Git 存放庫中分支上設定的標籤不同。
resources:
pipelines:
- pipeline: MyCIAlias
project: Fabrikam
source: Farbrikam-CI
tags:
- Production
trigger:
tags:
- Production
- Signed
管線成品版本評估
資源管線的成品版本取決於管線觸發方式。
手動或排程的觸發程式
如果管線執行是手動觸發或排程的,則、 branch
和 tags
屬性的值version
會定義成品版本。 輸入 branch
不能有通配符。 屬性會 tags
使用 AND
運算符。
指定的屬性 | 成品版本 |
---|---|
version |
具有指定執行編號之組建的成品 |
branch |
在指定分支上完成的最新組建成品 |
tags 清單 |
具有所有指定標籤之最新組建的成品 |
branch 和 tags 清單 |
在具有所有指定標籤之指定分支上完成之最新組建的成品 |
無 | 來自所有分支之最新組建的成品 |
下列 pipeline
資源定義會使用 branch
和 tags
屬性,在手動或排程管線時評估預設版本。 當您手動觸發管線執行時,MyCIAlias
管線成品版本是在具有 Production
和 PrepProduction
標籤的main
分支上完成的最新組建。
resources:
pipelines:
- pipeline: MyCIAlias
project: Fabrikam
source: Farbrikam-CI
branch: main
tags:
- Production
- PreProduction
資源管線完成觸發程式
當管線因為其中一個資源管線完成而觸發時,成品版本是觸發管線的版本。 會忽略、 branch
和 tags
屬性的值version
。
指定的觸發程式 | 結果 |
---|---|
branches |
每當資源管線在其中 include 一個分支上順利完成執行時,就會觸發新的管線執行。 |
tags |
每當資源管線順利完成以所有指定標籤的執行時,就會觸發新的管線執行。 |
stages |
每當資源管線成功執行指定的 stages 時,就會觸發新的管線執行。 |
branches 、tags 和 stages |
每當資源管線執行符合所有分支、標記和階段條件時,就會觸發新的管線執行。 |
trigger: true |
每當資源管線順利完成執行時,就會觸發新的管線執行。 |
Nothing | 當資源管線順利完成執行時,不會觸發任何新的管線執行。 |
每當資源管線時,下列管線就會 SmartHotel-CI
執行:
- 在其中
releases
一個分支或分支上執行main
- 使用和標記
Verified
Signed
- 完成
Production
和PreProduction
階段
resources:
pipelines:
- pipeline: SmartHotel
project: DevOpsProject
source: SmartHotel-CI
trigger:
branches:
include:
- releases/*
- main
exclude:
- topic/*
tags:
- Verified
- Signed
stages:
- Production
- PreProduction
管線成品下載
此步驟 download
會下載與目前執行或另一個管線資源相關聯的成品。
從目前管線及其所有資源的所有 pipeline
成品都會自動下載,並在每個部署作業開始時提供使用。 您可以將 設定 download
為 none
,或指定另一個管線資源識別符,以覆寫此行為。
一般作業成品不會自動下載。 視需要明確使用 download
。
資源的pipeline
成品會下載至 $(PIPELINE。WORKSPACE)/<pipeline-identifier>/<artifact-identifier> 資料夾。 如需詳細資訊,請參閱 發佈和下載管線成品。
選擇性 artifact
屬性會指定成品名稱。 如果未指定,則會下載所有可用的成品。 選擇性 patterns
屬性會定義代表要包含之檔案的模式。 如需完整的架構資訊,請參閱 steps.download 定義。
- job: deploy_windows_x86_agent
steps:
- download: SmartHotel
artifact: WebTier1
patterns: '**/*.zip'
管線資源變數
在每次執行中,管線資源的元數據都可供所有作業作為 預先定義的變數使用。 這些變數僅適用於運行時間的管線,因此無法在管線編譯時期評估的範本運算式中使用。
如需詳細資訊,請參閱 管線資源元數據作為預先定義的變數。 若要深入瞭解變數語法,請參閱 定義變數。
下列範例會傳 myresourcevars
回管線資源的預先定義變數值。
resources:
pipelines:
- pipeline: myresourcevars
source: mypipeline
trigger: true
steps:
- script: |
echo $(resources.pipeline.myresourcevars.pipelineID)
echo $(resources.pipeline.myresourcevars.runName)
echo $(resources.pipeline.myresourcevars.runID)
echo $(resources.pipeline.myresourcevars.runURI)
echo $(resources.pipeline.myresourcevars.sourceBranch)
echo $(resources.pipeline.myresourcevars.sourceCommit)
echo $(resources.pipeline.myresourcevars.sourceProvider)
echo $(resources.pipeline.myresourcevars.requestedFor)
echo $(resources.pipeline.myresourcevars.requestedForID)
建置資源定義
如果您有產生成品的外部 CI 建置系統,您可以使用資源來取用 builds
成品。 資源 build
可以來自任何外部 CI 系統,例如 Jenkins、TeamCity 或 CircleCI。
類別是可延伸的 builds
。 您可以撰寫擴充功能來取用組建服務的成品,並在 中引進新類型的服務 builds
。
在定義中 build
, version
預設為最新的成功組建。 trigger
默認不會啟用 ,而且必須明確設定。 如需完整的架構資訊,請參閱 resources.builds.build 定義。
在下列範例中,Jenkins 是資源 type
。
resources:
builds:
- build: Spaceworkz
type: Jenkins
connection: MyJenkinsServer
source: SpaceworkzProj # name of the Jenkins source project
trigger: true
重要
只有 Azure DevOps 具有 Jenkins 伺服器的視線,才能支援託管的 Jenkins 觸發程式。
downloadBuild 工作
資源build
成品不會在作業/deploy-jobs 中自動下載。 若要從 build
資源取用成品作為作業的一部分,您必須明確新增工作 downloadBuild
。 您可以自訂每個部署或作業的下載行為。
此工作會自動解析為運行時間所定義資源類型的 build
對應下載工作。 資源的 build
成品會下載至 $(PIPELINE。WORKSPACE)/<build-identifier>/ 資料夾。
在定義中 downloadBuild
,您會指定要從中下載成品的資源。 選擇性 artifact
屬性會指定要下載的成品。 如果未指定,則會下載與資源相關聯的所有成品。
選擇性 patterns
屬性會定義要下載的 迷你相符項目路徑或迷你組路徑 清單。 如果空白,則會下載整個成品。 例如,下列代碼段只會 下載 *.zip 檔案。
- job: deploy_windows_x86_agent
steps:
- downloadBuild: Spaceworkz
patterns: '**/*.zip'
如需完整的架構資訊,請參閱 steps.downloadBuild 定義。
存放庫資源定義
關鍵詞 repository
可讓您指定外部存放庫。 如果您的管線在另一個存放庫中有 範本,或是想要搭配需要服務連線的存放庫 使用 多重存放庫簽出 ,您可以使用此資源。 您必須讓系統知道這些存放庫。
例如:
resources:
repositories:
- repository: common
type: github
name: Contoso/CommonTools
endpoint: MyContosoServiceConnection
如需完整的架構資訊,請參閱 resources.repository.repository 定義。
存放庫資源類型
Azure Pipelines 支援下列存放庫類型的值: git
、 github
、 githubenterprise
和 bitbucket
。
- 此
git
類型是指 Azure Repos Git 存放庫。 - GitHub Enterprise 存放庫需要 GitHub Enterprise 服務連線 以進行授權。
- Bitbucket Cloud 存放庫需要 Bitbucket 雲端服務連線 以進行授權。
類型 | 名稱值 | 範例 |
---|---|---|
type: git |
相同專案或相同組織中的另一個存放庫。 | 相同的專案: name: otherRepo 相同組織中的另一個專案: name: otherProject/otherRepo 。 |
type: github |
GitHub 存放庫的完整名稱,包括用戶或組織。 | name: Microsoft/vscode |
type: githubenterprise |
GitHub Enterprise 存放庫的完整名稱,包括用戶或組織。 | name: Microsoft/vscode |
type: bitbucket |
Bitbucket Cloud 存放庫的完整名稱,包括用戶或組織。 | name: MyBitbucket/vscode |
存放庫資源變數
在每個回合中,存放庫資源的下列元數據可供運行時間變數形式的所有作業使用。 <Alias>
是您提供存放庫資源的識別碼。
resources.repositories.<Alias>.name
resources.repositories.<Alias>.ref
resources.repositories.<Alias>.type
resources.repositories.<Alias>.id
resources.repositories.<Alias>.url
下列範例具有別名為 的 common
存放庫資源,因此會使用 resources.repositories.common.*
存取存放庫資源變數。
resources:
repositories:
- repository: common
type: git
ref: main
name: Repo
variables:
ref: $[ resources.repositories.common.ref ]
name: $[ resources.repositories.common.name ]
id: $[ resources.repositories.common.id ]
type: $[ resources.repositories.common.type ]
url: $[ resources.repositories.common.url ]
steps:
- bash: |
echo "name = $(name)"
echo "ref = $(ref)"
echo "id = $(id)"
echo "type = $(type)"
echo "url = $(url)"
在每個回合中,存放庫資源的下列元數據可供運行時間變數形式的所有作業使用。 <Alias>
是您提供存放庫資源的識別碼。
resources.repositories.<Alias>.name
resources.repositories.<Alias>.ref
resources.repositories.<Alias>.type
resources.repositories.<Alias>.id
resources.repositories.<Alias>.url
resources.repositories.<Alias>.version
下列範例具有別名為 的 common
存放庫資源,因此會使用 resources.repositories.common.*
存取存放庫資源變數。
resources:
repositories:
- repository: common
type: git
ref: main
name: Repo
variables:
ref: $[ resources.repositories.common.ref ]
name: $[ resources.repositories.common.name ]
id: $[ resources.repositories.common.id ]
type: $[ resources.repositories.common.type ]
url: $[ resources.repositories.common.url ]
version: $[ resources.repositories.common.version ]
steps:
- bash: |
echo "name = $(name)"
echo "ref = $(ref)"
echo "id = $(id)"
echo "type = $(type)"
echo "url = $(url)"
echo "version = $(version)"
存放庫的 Checkout 關鍵詞
資源中的 repository
存放庫不會在作業中自動同步處理。 checkout
使用 關鍵詞來擷取定義為資源的一部分的repository
存放庫。 如需完整的架構資訊,請參閱 steps.checkout 定義。
如需詳細資訊,請參閱 查看管線中的多個存放庫。
容器資源定義
如果您需要使用容器映像作為 CI/CD 管線的一部分,您可以使用 containers
資源。 container
資源可以是公用或私人 Docker 登錄或 Azure Container Registry 實例。
您可以取用一般容器資源映像作為作業的一部分,或使用容器作業的資源。 如果您的管線需要一或多個服務的支援,您需要建立並連線到 服務容器。 您可以使用磁碟區在服務之間共享數據。
如果您需要從 Docker 登錄取用映像作為管線的一部分,您可以定義泛型容器資源。 不需要 type
關鍵詞。 例如:
resources:
containers:
- container: smartHotel
endpoint: myDockerRegistry
image: smartHotelApp
如需完整的架構資訊,請參閱 resources.containers.container 定義。
注意
enabled: 'true'
針對所有映像標記啟用容器觸發程式的語法與其他資源觸發程式的語法不同。 請務必針對特定資源使用正確的語法。
Azure Container Registry 資源類型
若要取用 Azure Container Registry 映射,您可以使用一流的容器資源類型 acr
。 您可以使用此資源類型作為作業的一部分,並啟用自動管線觸發程式。
您需要 Azure Container Registry 的參與者 或 擁有者 許可權,才能使用自動管線觸發程式。 如需詳細資訊,請參閱 Azure Container Registry 角色和權限。
若要使用 acr
資源類型,您必須指定 Azure 容器登錄的 azureSubscription
、 resourceGroup
和 repository
值。 例如:
resources:
containers:
- container: petStore
type: acr
azureSubscription: ContosoConnection
resourceGroup: ContosoGroup
registry: petStoreRegistry
repository: myPets
trigger:
tags:
include:
- production*
注意
觸發程式評估只會發生在預設分支上。 請務必設定正確的預設分支,或將 YAML 檔案合併至目前的預設分支。 如需如何變更管線預設分支的詳細資訊,請造訪 管線預設分支。
容器資源變數
將容器定義為資源之後,容器映射元數據會以變數的形式傳遞至管線。 映像、登錄和連線詳細數據等資訊可跨容器部署工作中使用的所有作業存取。
容器資源變數可與 Docker 和 Azure Container Registry 搭配使用。 您無法針對本機映像容器使用容器資源變數。 變數 location
僅適用於 acr
容器資源的類型。
下列範例具有名為 的 arm-connection
Azure Resource Manager 服務連線。 如需詳細資訊,請參閱 Azure 容器登錄、存放庫和映射。
resources:
containers:
- container: mycontainer
type: ACR
azureSubscription: arm-connection
resourceGroup: rg-storage-eastus
registry: mycontainerregistry
repository: hello-world
trigger:
tags:
- latest
steps:
- script: echo |
echo $(resources.container.mycontainer.type)
echo $(resources.container.mycontainer.registry)
echo $(resources.container.mycontainer.repository)
echo $(resources.container.mycontainer.tag)
echo $(resources.container.mycontainer.digest)
echo $(resources.container.mycontainer.URI)
echo $(resources.container.mycontainer.location)
封裝資源定義
您可以使用 NuGet 和 npm GitHub 套件作為 YAML 管線中的資源。 若要在發行新的套件版本時啟用自動化管線觸發程式,請將 屬性設定 trigger
為 true
。
當您定義package
資源時,請在屬性中name
指定套件<存放庫>/<名稱>,並將封裝type
設定為 NuGet
或 npm
。 若要使用 GitHub 套件,請使用個人存取令牌 (PAT) 型驗證,並建立使用 PAT 的 GitHub 服務連線。
如需完整的架構資訊,請參閱 resources.packages.package 定義。
根據預設,套件不會自動下載到作業中。 若要下載,請使用 getPackage。
下列範例具有名為 pat-contoso
的 GitHub 服務連線至名為的 contoso
GitHub npm 套件。 如需詳細資訊,請參閱 GitHub 套件。
resources:
packages:
- package: contoso
type: npm
connection: pat-contoso
name: myname/contoso
version: 7.130.88
trigger: true
pool:
vmImage: 'ubuntu-latest'
steps:
- getPackage: contoso
Webhook 資源定義
注意
Webhook 已在 Azure DevOps Server 2020.1 中發行。
您可以使用管線、容器、組建和套件資源來取用成品,並啟用自動化觸發程式。 不過,您無法使用這些資源,根據外部事件或服務將部署自動化。
webhooks
YAML 管線中的資源可讓您將管線與 GitHub、GitHub Enterprise、Nexus 和 Artifactory 等外部服務整合,以自動化工作流程。 您可以透過 Webhook 訂閱任何外部事件,並使用事件來觸發管線。
Webhook 會根據管線、組建、容器或套件等一流資源不支援的任何外部 Webhook 事件,將工作流程自動化。 此外,對於 Azure DevOps 無法查看程式的內部部署服務,您可以在服務上設定 Webhook,並自動觸發管線。
若要訂閱 Webhook 事件,您可以在管線中定義 Webhook 資源,並將它指向傳入的 Webhook 服務連線。 您也可以根據 JSON 承載數據,在 Webhook 資源上定義更多篩選,以自定義每個管線的觸發程式。
每當連入 Webhook 服務連線收到 Webhook 事件時,所有訂閱 Webhook 事件的管線都會產生新的執行觸發程式。 您可以使用 格式 ${{ parameters.<WebhookAlias>.<JSONPath>}}
,將作業中的 JSON 承載資料取用為變數。
如需完整的架構資訊,請參閱 resources.webhooks.webhook 定義。
下列範例會定義 Webhook 資源:
resources:
webhooks:
- webhook: WebHook
connection: IncomingWH
steps:
- script: echo ${{ parameters.WebHook.resource.message.title }}
Webhook 觸發程序
若要設定 Webhook 觸發程式,請先在外部服務上設定 Webhook,並提供下列資訊:
- 要求 URL:
https://dev.azure.com/<Azure DevOps organization>/_apis/public/distributedtask/webhooks/<webhook name>?api-version=6.0-preview
- 秘密 (選擇性):如果您需要保護 JSON 承載,請提供秘密值。
接下來,您會建立新的傳入 Webhook 服務連線。 針對此服務連線類型,您可以定義下列資訊:
- WebHook 名稱:與您外部服務中建立的 Webhook 相同。
- 秘密 (選擇性):用來驗證承載的 HMAC-SHA1 哈希,以驗證傳入要求。 如果您在建立 Webhook 時使用秘密,則必須提供相同的秘密。
- Http 標頭:要求中的 HTTP 標頭,其中包含承載的 HMAC-SHA1 哈希值以進行要求驗證。 例如,GitHub 要求標頭為
X-Hub-Signature
。
若要使用 Webhook 觸發管線,請向 POST
https://dev.azure.com/<org_name>/_apis/public/distributedtask/webhooks/<webhook_connection_name>?api-version=6.0-preview
提出要求。 此端點可供公開使用,且不需要授權。 要求應該有類似下列範例的主體:
{
"resource": {
"message": {
"title": "Hello, world!",
"subtitle": "I'm using WebHooks!"
}
}
}
注意
從 Webhook 的要求本文存取數據可能會導致不正確的 YAML。 例如,管線步驟 - script: echo ${{ parameters.WebHook.resource.message }}
會提取整個 JSON 訊息,這會產生無效的 YAML。 透過此 Webhook 觸發的任何管線都不會執行,因為產生的 YAML 變得無效。
下列代碼段顯示另一個使用 Webhook 篩選的範例。
resources:
webhooks:
- webhook: MyWebhookTrigger
connection: MyWebhookConnection
filters:
- path: repositoryName
value: maven-releases
- path: action
value: CREATED
steps:
- task: PowerShell@2
inputs:
targetType: 'inline'
script: |
Write-Host ${{ parameters.MyWebhookTrigger.repositoryName}}
Write-Host ${{ parameters.MyWebhookTrigger.component.group}}
資源的手動版本選擇器
當您手動觸發 CD YAML 管線時,Azure Pipelines 會根據提供的輸入,自動評估管線中所定義資源的預設版本。 不過,Azure Pipelines 只會在評估排程觸發程式的預設版本時,或您未手動選擇版本時,才會考慮成功完成 CI 執行。
您可以使用資源版本選擇器,在建立執行時手動選擇不同的版本。 管線、組建、存放庫、容器和套件資源支援資源版本選擇器。
針對管線資源,您可以看到所有分支中所有可用的執行、根據管線編號或分支進行搜尋,然後挑選成功、失敗或進行中的執行。 如果您確定執行產生了您需要的所有成品,此彈性可確保您可以執行 CD 管線。 您不需要等候 CI 執行完成,或因為不相關的階段失敗而重新執行。
若要使用資源版本選擇器,請在 [執行管線 ] 窗格中,選取 [資源],然後從可用版本清單中選取特定版本。
對於無法擷取可用版本的資源,例如 GitHub 套件,版本選擇器會提供文字欄位,讓您可以輸入要挑選的執行版本。
YAML 管線中的資源授權
資源必須先獲得授權,才能在管線中使用資源。 資源擁有者可控制可存取其資源的使用者和管線。 有數種方式可授權 YAML 管線使用資源。
使用資源管理體驗來授權 所有管線 存取資源。 例如,變數群組和安全檔案是在 [管線] 下的 [連結庫] 頁面中管理,而代理程式集區和服務連線是在 [項目設定] 中管理。 如果您不需要限制對資源的存取,例如測試資源,此授權就很方便。
當您建立管線時,如果您有這些資源的使用者角色,YAML 檔案中參考的所有資源都會自動獲得授權供管線使用。
如果您將資源新增至 YAML 檔案,而組建失敗,並出現類似
Could not find a <resource> with name <resource-name>. The <resource> does not exist or has not been authorized for use.
的錯誤,您會看到在失敗的組建上授權資源的選項。如果您是資源的使用者角色成員,您可以選取此選項,並在失敗的組建上授權資源。 一旦資源獲得授權,您就可以啟動新的組建。
確認 您專案的代理程式集區安全性角色 正確無誤。
資源的核准檢查
您可以使用核准檢查和範本,手動控制資源執行的時間。 透過必要的範本核准檢查,您可以要求任何使用資源或環境的管線從特定的 YAML 範本延伸。
設定必要的範本核准可確保您的資源只會在特定條件下使用,並增強安全性。 若要深入瞭解如何使用 範本增強管線安全性 ,請參閱 使用範本的安全性。
可追蹤性
Azure Pipelines 可為管線或部署作業層級取用的任何資源提供完整的可追蹤性。
管線可追蹤性
Azure Pipelines 會顯示每個管線執行的下列資訊:
- 如果資源觸發管線,則觸發管線的資源。
- 資源版本和已取用的成品。
- 與每個資源相關聯的認可。
- 與每個資源相關聯的工作專案。
環境可追蹤性
每當管線部署到環境時,您可以看到已取用的資源清單。 檢視包含作為部署作業一部分所耗用的資源,以及其相關聯的認可和工作專案。
CI 管線中相關聯的CD管線資訊
若要提供端對端可追蹤性,您可以透過資源追蹤哪些 CD 管線取用 pipelines
特定的 CI 管線。 如果其他管線取用 CI 管線,您會在 [執行] 檢視中看到 [相關聯的管線] 索引標籤。 此檢視會顯示取用 CI 管線及其成品的所有 CD YAML 管線執行。
資源觸發程序問題
資源觸發程式無法執行,因為:
- 所提供的服務連線來源無效、觸發程式中有語法錯誤,或未設定觸發程式。
- 觸發條件不相符。
若要查看管線觸發程式為何無法執行,請選取 管線定義頁面上的 [觸發問題] 功能表項。 觸發程式問題 僅適用於非存放庫資源。
在 [ 觸發程序問題] 頁面上,錯誤和警告訊息會描述觸發程序失敗的原因。
常見問題集
何時應該使用管線資源、下載快捷方式或下載管線成品工作?
pipelines
使用資源是取用 CI 管線中的成品,以及設定自動化觸發程式的方式。 資源可讓您完整查看程式,方法是顯示已取用的版本、成品、認可和工作專案。 當您定義管線資源時,相關聯的成品會自動在部署作業中下載。
您可以使用 download
快捷方式來下載組建作業中的成品,或覆寫部署作業中的下載行為。 如需詳細資訊,請參閱 steps.download 定義。
下載 管線成品工作 不提供可追蹤性或觸發程式,但有時直接使用此工作是合理的。 例如,您可能將腳本工作儲存在不同的範本中,而該範本需要從組建下載成品。 或者,您可能不想將管線資源新增至範本。 若要避免相依性,您可以使用下載管線成品工作,將所有建置資訊傳遞至工作。
如何在 Docker Hub 映射更新時觸發管線執行?
容器資源觸發程式不適用於適用於 YAML 管線的 Docker Hub,因此您必須設定 傳統發行管線。
- 建立新的 Docker Hub 服務連線。
- 建立傳統發行管線並新增 Docker Hub 成品。 設定您的服務連線,然後選取命名空間、存放庫、版本和來源別名。
- 選取觸發程式,並將持續部署觸發程式切換為 [啟用]。 每個發生在所選存放庫的 Docker 推送都會建立發行。
- 建立新的階段和作業。 新增兩個工作:Docker 登入和Bash。
- Docker 工作具有 動作,
login
並將您登入 Docker Hub。 - Bash 工作會執行
docker pull <hub-user>/<repo-name>[:<tag>]
。
- Docker 工作具有 動作,
如何驗證 Webhook 並進行疑難解答?
建立服務連線。
參考您的服務連線,並在區
webhooks
段中命名您的 Webhook。resources: webhooks: - webhook: MyWebhookTriggerAlias connection: MyServiceConnection
執行您的管線。 Webhook 會在 Azure 中建立為組織的分散式工作。
在
POST
主體中以有效的 JSON 執行 API 呼叫。https://dev.azure.com/<organization>/_apis/public/distributedtask/webhooks/<webhook-name>?api-version=<apiversion>
如果您收到 200 狀態代碼回應,您的 Webhook 已準備好供管線取用。
如果您收到具有錯誤的 Cannot find webhook for the given webHookId ...
500 狀態代碼回應,您的程式代碼可能位於不是預設分支的分支中。 若要解決此問題:
- 選取 管線頁面上的 [編輯 ]。
- 從 [ 更多動作] 功能表中,選取 [ 觸發程式]。
- 選取 [YAML] 索引標籤,然後選取 [取得來源]。
- 在 [手動和排程組建的預設分支] 下,更新您的功能分支。
- 選取 [ 儲存和佇列]。
- 成功執行此管線之後,請在主體
https://dev.azure.com/<organization>/_apis/public/distributedtask/webhooks/<webhook-name>?api-version=<apiversion>
中對 執行POST
具有有效 JSON 的 API 呼叫。 您現在應該會收到 200 狀態代碼回應。