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
• 使用和標記VerifiedSigned
• 完成 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
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* 

注意

不支援使用工作負載身分識別同盟azureSubscription的服務連線。

容器資源變數

將容器定義為資源之後，容器映射元數據會以變數的形式傳遞至管線。 映像、登錄和連線詳細數據等資訊可跨容器部署工作中使用的所有作業存取。

容器資源變數可與 Docker 和 Azure Container Registry 搭配使用。 您無法針對本機映像容器使用容器資源變數。 變數 location 僅適用於 acr 容器資源的類型。

下列範例具有名為 的 arm-connectionAzure 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 服務連線至名為的 contosoGitHub 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，因此您必須設定 傳統發行管線。

1. 建立新的 Docker Hub 服務連線。
2. 建立傳統發行管線並新增 Docker Hub 成品。 設定您的服務連線，然後選取命名空間、存放庫、版本和來源別名。
3. 選取觸發程式，並將持續部署觸發程式切換為 [啟用]。 每個發生在所選存放庫的 Docker 推送都會建立發行。
4. 建立新的階段和作業。 新增兩個工作：Docker 登入和Bash。
   • Docker 工作具有 動作， login 並將您登入 Docker Hub。
   • Bash 工作會執行 docker pull <hub-user>/<repo-name>[:<tag>]。

如何驗證 Webhook 並進行疑難解答？

1. 建立服務連線。

2. 參考您的服務連線，並在區 webhooks 段中命名您的 Webhook。

   resources:
     webhooks:
       - webhook: MyWebhookTriggerAlias
         connection: MyServiceConnection
   

3. 執行您的管線。 Webhook 會在 Azure 中建立為組織的分散式工作。

4. 在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 狀態代碼回應，您的程式代碼可能位於不是預設分支的分支中。 若要解決此問題：

1. 選取 管線頁面上的 [編輯 ]。
2. 從 [ 更多動作] 功能表中，選取 [ 觸發程式]。
3. 選取 [YAML] 索引標籤，然後選取 [取得來源]。
4. 在 [手動和排程組建的預設分支] 下，更新您的功能分支。
5. 選取 [ 儲存和佇列]。
6. 成功執行此管線之後，請在主體https://dev.azure.com/<organization>/_apis/public/distributedtask/webhooks/<webhook-name>?api-version=<apiversion>中對 執行POST具有有效 JSON 的 API 呼叫。 您現在應該會收到 200 狀態代碼回應。

相關內容

• 關於 Azure Pipelines 的資源
• 定義變數
• 新增和使用變數群組
• 建立環境並將其設為目標
• 使用 YAML 管線編輯器
• YAML 結構描述參考