YAML 管線中的資源

2025-04-01

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

管道工件版本評估

資源管線的工件版本依據管線觸發的方式決定。

手動或排程的觸發

如果管線執行是手動觸發或排程的，則 version、 branch 和 tags 屬性的值會定義產出物版本。輸入 branch 不能有通配符。 tags 屬性使用 AND 運算符。

指定的屬性	工件版本
`version`	指定執行編號的組建工件
`branch`	指定分支上最新完成組建的成品
`tags` 清單	最新構建中具有所有指定標籤的工件
`branch` 和 `tags` 清單	在具有所有指定標籤之指定分支上完成之最新組建的成品
`version` 和 `branch`	指定執行編號和分支的組建產物。
無	來自所有分支的最新建置工件

下列 pipeline 資源定義會使用 branch 和 tags 屬性，在管線被手動觸發或排程運行時評估預設版本。當您手動觸發管線執行時，MyCIAlias管線成品版本是在具有 main 和 Production 標籤的PrepProduction分支上完成的最新組建。

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    branch: main
    tags:
    - Production
    - PreProduction

資源流程完成觸發器

當管線因其中一個資源管線完成而觸發時，該工件版本是觸發管線的版本。會忽略 version、branch 和 tags 屬性的值。

指定的觸發程式	結果
`branches`	每當資源管線在其中 `include` 一個分支上順利完成執行時，就會觸發新的管線執行。
`tags`	每當資源管線順利執行完畢且標有所有指定標籤時，就會觸發新的管線執行程序。
`stages`	每當資源管線成功執行指定的 `stages`時，就會觸發新的管線執行。
`branches`、`tags` 和 `stages`	當資源管線執行滿足所有分支、標記和階段條件時，就會啟動新的管線執行。
`trigger: true`	每當資源管線順利完成一個執行序時，就會觸發新的管線執行序。
無事	當資源管線成功完成一次執行時，不會有任何新的管線執行被觸發。

當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 會下載與目前執行或其他管線資源相關聯的工件。

目前管線及其所有資源的工件都會自動下載，並在每個部署作業開始時可供使用。您可以設定 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 的觸發程式。

下載構建工作

資源工件build不會在jobs/deploy-jobs中自動下載。若要作業中使用來自 build 資源的成品，您必須明確地加入 downloadBuild 任務。您可以自訂每個部署或作業的下載行為。

此任務會自動解析為運行時所定義資源類型的 build 對應下載任務。資源的build工件會下載至$(PIPELINE.WORKSPACE)/<build-identifier>/資料夾。

在 downloadBuild 的定義中，您會指定要從中下載工件的資源。可選的 artifact 屬性指定要下載的工件。如果未指定，則會下載與資源相關聯的所有工件。

選擇性 patterns 屬性會定義要下載的 minimatch 路徑或 minimatch 路徑清單。如果空白，則會下載整個成品。例如，下列代碼段只會 下載 *.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)"

存放庫的簽出關鍵詞

資源中的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。您可以使用此資源型態作為作業的一部分，並啟用自動管道觸發程式。

您需要 Contributor 或 Owner 權限來使用 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 資源管理員服務連線。如需詳細資訊，請參閱 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)

套件資源定義

您可以在 YAML 管線中使用 NuGet 和 npm GitHub 套件作為資源。若要在發行新的套件版本時啟用自動化管線觸發程式，請將屬性設定 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 服務連線。您也可以根據 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 服務連線的螢幕快照。

若要使用 Webhook 觸發管線，請向 POSThttps://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 執行完成，也不需要因為不相關的階段失敗而重新執行 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 關聯管線資訊

若要提供端對端的可追蹤性，您可以藉由pipelines資源來追蹤哪些 CD 管線正在使用某個特定的 CI 管線。如果其他管線取用您的 CI 管線，您會在執行檢視中看到 相關聯的管線 標籤。此檢視會顯示在使用作為您 CI 管線的 CD YAML 管線執行時所取用的所有執行結果及其所產生的成品。

顯示 CI 管線中 CD 管線資訊的螢幕快照。

資源引發問題

資源觸發程式無法執行，因為：

所提供的服務連線來源無效、觸發程式中有語法錯誤，或未設定觸發程式。
觸發條件不相符。

若要查看管線觸發程式為何無法執行，請選取 管線定義頁面上的 [觸發問題] 功能表項。 觸發問題 僅適用於非存放庫資源。

在 [ 觸發程序問題] 頁面上，錯誤和警告訊息會描述觸發程序失敗的原因。

顯示觸發程式問題支援性的螢幕快照。

常見問題集

何時應該使用管線資源、下載捷徑或下載管線工件？

使用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>]。

如何驗證和排除 Webhook 問題？

建立服務連線。

查閱您的服務連線，並在區段 webhooks 中命名您的 Webhook。

resources:
  webhooks:
    - webhook: MyWebhookTriggerAlias
      connection: MyServiceConnection

執行您的流程。 Webhook 被建立在 Azure 中，作為您組織的分散式任務。
在 https://dev.azure.com/<organization>/_apis/public/distributedtask/webhooks/<webhook-name>?api-version=<apiversion> 中，對 POST 執行 API 呼叫，並在主體中提供有效的 JSON。如果您收到 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>進行 API 呼叫，並在POST中提供有效的 JSON。您現在應該會收到 200 狀態代碼回應。