在 YAML 中定義資源

Azure DevOps Services |Azure DevOps Server 2022 - Azure DevOps Server 2019

YAML 中的資源代表管線、組建、存放庫、容器、套件和 Webhook 的來源。 資源也可讓您完整追蹤管線中使用的服務,包括版本、成品、相關聯的認可和工作專案。 當您定義資源時,可以在管線中的任何位置取用該資源。 而且,您可以訂閱以在資源上觸發事件,以完全自動化 DevOps 工作流程。

如需詳細資訊,請參閱 關於資源 和資源 YAML 架構定義

結構描述

resources:
  pipelines: [ pipeline ]  
  builds: [ build ]
  repositories: [ repository ]
  containers: [ container ]
  packages: [ package ]
  webhooks: [ webhook ]

變數

當資源觸發管線時,會設定下列變數:

resources.triggeringAlias
resources.triggeringCategory

如果資源未觸發管線執行,這些值會是空的。 變數 Build.Reason 必須 ResourceTrigger 供這些值設定。

pipelines定義資源

如果您有產生成品的管線,您可以藉由定義 pipelines 資源來取用成品。 pipelines 是僅適用於 Azure Pipelines 的專用資源。 您也可以在CD工作流程的管線資源上設定觸發程式。

在您的資源定義中,是一個唯一值, pipeline 您可以稍後用來參考管線資源。 source 是產生成品的管線名稱。 使用 所 pipeline 定義的標籤,從管線的其他部分參考管線資源,例如使用管線資源變數或下載成品時。

如需下載管線的替代方式,請參閱管線成品的工作。

resources:        # types: pipelines | builds | repositories | containers | packages
  pipelines:
  - pipeline: string  # identifier for the resource used in pipeline resource variables
    project: string # project for the source; optional for current project
    source: string  # name of the pipeline that produces an artifact
    version: string  # the pipeline run number to pick the artifact, defaults to latest pipeline successful across all stages; Used only for manual or scheduled triggers
    branch: string  # branch to pick the artifact, optional; defaults to all branches; Used only for manual or scheduled triggers
    tags: [ string ] # list of tags required on the pipeline to pickup default artifacts, optional; Used only for manual or scheduled triggers
    trigger:     # triggers aren't enabled by default unless you add trigger section to the resource
      branches:  # branch conditions to filter the events, optional; Defaults to all branches.
        include: [ string ]  # branches to consider the trigger events, optional; Defaults to all branches.
        exclude: [ string ]  # branches to discard the trigger events, optional; Defaults to none.
      tags: [ string ]  # list of tags to evaluate for trigger event, optional
      stages: [ string ] # list of stages to evaluate for trigger event, optional

重要

當您定義資源觸發程式時,如果其管線資源來自與目前管線相同的存放庫(例如 self),則觸發程式會遵循引發事件的相同分支並認可。 但是,如果管線資源來自不同的存放庫,則目前的管線會在自我存放庫的預設分支上觸發。

成品版本的評估

資源管線成品的版本取決於管線的觸發方式。

如果您的管線因為您手動觸發或因為排程的執行而執行,成品的版本是由、 branchtags 屬性的值version所定義。

指定的屬性 成品版本
version 來自組建的成品具有指定的執行編號
branch 在指定分支上執行的最新組建成品
tags 清單 具有所有指定標籤之最新組建的成品
branchtags 清單 在指定分支 上執行之最新組建中的成品,且 具有所有指定的標籤
來自所有分支之最新組建的成品

讓我們看看下列範例。 假設您的管線包含下列資源定義。

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    branch: main      ### This branch input cannot have wild cards. It is used for evaluating default version when pipeline is triggered manually or scheduled.
    tags:               ### These tags are used for resolving default version when the pipeline is triggered manually or scheduled
    - Production        ### Tags are AND'ed
    - PreProduction

當您手動觸發管線來執行時,管線的成品 MyCIAlias 版本是分支上 main 完成且具有 ProductionPrepProduction 標記的最新組建之一。

當管線因為其中一個資源管線完成而觸發時,成品的版本就是其中一個觸發管線。 會忽略、 branchtags 屬性的值version

指定的觸發程式 結果
branches 每當資源管線成功完成分支上的 include 執行時,就會觸發目前管線的新執行
tags 每當資源管線順利完成以 所有 指定標籤的執行時,就會觸發目前管線的新執行
stages 每當資源管線成功執行指定的時,就會觸發目前管線的新執行 stages
branchestagsstages 每當資源管線執行符合 所有 分支、標記和階段條件時,就會觸發目前管線的新執行
trigger: true 每當資源管線順利完成執行時,就會觸發目前管線的新執行
Nothing 當資源管線順利完成執行時,不會觸發目前管線的新執行

讓我們看看下列範例。 假設您的管線包含下列資源定義。

resources:
  pipelines:
  - pipeline: SmartHotel
    project: DevOpsProject
    source: SmartHotel-CI
    trigger:
      branches:
        include:
        - releases/*
        - main
        exclude:
        - topic/*
      tags: 
      - Verified
      - Signed
      stages:
      - Production
      - PreProduction
      

每當SmartHotel-CI管線在其中releases一個分支或分支上main執行時,管線就會執行,並同時標記 Verified 和 ,且已完成 ProductionSignedPreProduction 階段。

download 適用於管線

從目前管線和所有 pipeline 資源的所有成品都會自動下載,並在每個 deployment 作業開始時提供使用。 您可以覆寫此行為。 如需詳細資訊,請參閱 管線成品。 不會自動下載一般「作業」成品。 視需要明確使用 download

steps:
- download: [ current | pipeline resource identifier | none ] # disable automatic download if "none"
  artifact: string ## artifact name, optional; downloads all the available artifacts if not specified
  patterns: string # patterns representing files to include; optional

資源中的 pipeline 成品會下載至 $(PIPELINE.WORKSPACE)/<pipeline-identifier>/<artifact-identifier> 資料夾。

管線資源變數

在每次執行中,管線資源的元數據都可供所有作業以預先定義的變數形式使用。 <Alias>是您為管線資源提供的識別碼。 管線資源變數只能在運行時間使用。

resources.pipeline.<Alias>.projectID
resources.pipeline.<Alias>.pipelineName
resources.pipeline.<Alias>.pipelineID
resources.pipeline.<Alias>.runName
resources.pipeline.<Alias>.runID
resources.pipeline.<Alias>.runURI
resources.pipeline.<Alias>.sourceBranch
resources.pipeline.<Alias>.sourceCommit
resources.pipeline.<Alias>.sourceProvider
resources.pipeline.<Alias>.requestedFor
resources.pipeline.<Alias>.requestedForID

如需詳細資訊,請參閱 管線資源元數據作為預先定義的變數

builds定義資源

如果您有產生成品的外部 CI 組建系統,您可以使用資源來取用 builds 成品。 資源 builds 可以是任何外部 CI 系統,例如 Jenkins、TeamCity、CircleCI 等等。

resources:        # types: pipelines | builds | repositories | containers | packages
  builds:
  - build: string   # identifier for the build resource
    type: string   # the type of your build service like Jenkins, circleCI etc.
    connection: string   # service connection for your build service.
    source: string   # source definition of the build
    version: string   # the build number to pick the artifact, defaults to Latest successful build
    trigger: boolean    # Triggers aren't enabled by default and should be explicitly set

builds 是可延伸類別。 您可以撰寫擴充功能來取用組建服務的成品,並在 中引進新類型的服務 builds。 Jenkins 是 中的 builds資源類型。

重要

只有裝載的 Jenkins 支援觸發程式,其中 Azure DevOps 具有 Jenkins 伺服器的視線。

downloadBuild 建置工作

您可以使用 工作,從 build 資源取用成品作為作業 downloadBuild 的一部分。 根據定義的資源類型 build ,此工作會在運行時間自動解析為服務的對應下載工作。

資源中的 build 成品會下載至 $(PIPELINE.WORKSPACE)/<build-identifier>/ 資料夾。

重要

build 資源成品不會在作業/deploy-jobs 中自動下載。 您必須明確新增 downloadBuild 工作以取用成品。

- downloadBuild: string # identifier for the resource from which to download artifacts
  artifact: string # artifact to download; if left blank, downloads all artifacts associated with the resource provided
  patterns: string | [ string ] # a minimatch path or list of [minimatch paths](tasks/file-matching-patterns.md) to download; if blank, the entire artifact is downloaded

repositories定義資源

如果您的管線在另一個存放庫中範本,或您想要搭配需要服務連線的存放庫使用多重存放庫簽出,則必須讓系統知道該存放庫。 關鍵詞 repository 可讓您指定外部存放庫。

resources:
    repositories:
    - repository: string # Required as first property. Alias for the repository.
      endpoint: string # ID of the service endpoint connecting to this repository.
      trigger: none | trigger | [ string ] # CI trigger for this repository, no CI trigger if skipped (only works for Azure Repos).
      name: string # repository name (format depends on 'type'; does not accept variables).
      ref: string # ref name to checkout; defaults to 'refs/heads/main'. The branch checked out by default whenever the resource trigger fires.
      type: string # Type of repository: git, github, githubenterprise, and bitbucket.

類型

管線支援下列存放庫類型的值: gitgithubgithubenterprisebitbucket。 此 git 類型是指 Azure Repos Git 存放庫。

指定的類型 結果 範例
type: git name 是指相同專案中的另一個存放庫。 name: otherRepo 若要參考相同組織內另一個專案中的存放庫,請在名稱前面加上該專案的名稱。 例如 name: OtherProject/otherRepo
type: github 此值 name 是 GitHub 存放庫的完整名稱,並包含使用者或組織。 name: Microsoft/vscode
type: githubenterprise 此值 name 是 GitHub Enterprise 存放庫的完整名稱,並包含使用者或組織。 name: Microsoft/vscode
type: bitbucket 此值 name 是 Bitbucket Cloud 存放庫的完整名稱,並包含使用者或組織。 name: MyBitbucket/vscode

GitHub Enterprise 存放庫需要 GitHub Enterprise 服務連線 以進行授權。

Bitbucket Cloud 存放庫需要 Bitbucket 雲端服務連線 以進行授權。

變數

在每次執行中,存放庫資源的元數據都可供運行時間變數形式的所有作業使用。 <Alias>是您為存放庫資源提供識別碼。

resources.repositories.<Alias>.name
resources.repositories.<Alias>.ref
resources.repositories.<Alias>.type
resources.repositories.<Alias>.id
resources.repositories.<Alias>.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

使用 checkout 來取用存放庫

使用 checkout 關鍵詞來取用定義為資源的一部分的 repository 存放庫。

結構描述

steps:
- checkout: string # Required as first property. Configures checkout for the specified repository.
  clean: string # If true, run git clean -ffdx followed by git reset --hard HEAD before fetching.
  fetchDepth: string # Depth of Git graph to fetch.
  fetchTags: string # Set to 'true' to sync tags when fetching the repo, or 'false' to not sync tags. See remarks for the default behavior.
  lfs: string # Set to 'true' to download Git-LFS files. Default is not to download them.
  persistCredentials: string # Set to 'true' to leave the OAuth token in the Git config after the initial fetch. The default is not to leave it.
  submodules: string # Set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules. Default is not to fetch submodules.
  path: string # Where to put the repository. The default is $(Build.SourcesDirectory).
  condition: string # Evaluate this condition expression to determine whether to run this task.
  continueOnError: boolean # Continue running even on failure?
  displayName: string # Human-readable name for the task.
  target: string | target # Environment in which to run this task.
  enabled: boolean # Run this task when the job runs?
  env: # Variables to map into the process's environment.
    string: string # Name/value pairs
  name: string # ID of the step.
  timeoutInMinutes: string # Time to wait for this task to complete before the server kills it.
  retryCountOnTaskFailure: string # Number of retries if the task fails.

資源中的 repository 存放庫不會在作業中自動同步處理。 使用 checkout 來擷取您的存放庫作為作業的一部分。

如需詳細資訊,請參閱 查看管線中的多個存放庫。

containers定義資源

如果您需要使用容器映像作為持續整合/持續傳遞 (CI/CD) 管線的一部分,您可以使用 來達成。containers 容器資源可以是公用或私人 Docker 登錄,或 Azure Container Registry。

如果您需要從 Docker 登錄取用映像作為管線的一部分,您可以定義泛型容器資源(不需要 type 關鍵詞)。

resources:
  containers:
  - container: string  # identifier (A-Z, a-z, 0-9, and underscore)
    image: string  # container image name
    options: string  # arguments to pass to container at startup
    endpoint: string  # reference to a service connection for the private registry
    env: { string: string }  # list of environment variables to add
    ports: [ string ] # ports to expose on the container
    volumes: [ string ] # volumes to mount on the container
    mapDockerSocket: bool # whether to map in the Docker daemon socket; defaults to true
    mountReadOnly:  # volumes to mount read-only - all default to false
      externals: boolean  # components required to talk to the agent
      tasks: boolean  # tasks required by the job
      tools: boolean  # installable tools like Python and Ruby
      work: boolean # the work directory

您可以使用泛型容器資源做為作業的一部分取用的映像,也可以用於 容器作業。 如果您的管線需要一或多個服務的支援,您會想要建立並連線到 服務容器。 您可以使用磁碟區在服務之間共享數據。

您可以使用 Azure Container Registry (ACR) 的第一類容器資源類型來取用您的 ACR 映像。 此資源類型可用來作為作業的一部分,也可用來啟用自動管線觸發程式。 您必須擁有 ACR 的參與者擁有者 許可權,才能使用自動管線觸發程式。 如需詳細資訊,請參閱 Azure Container Registry 角色和許可權

resources:          # types: pipelines | repositories | containers | builds | packages
  containers:
  - container: string # identifier for the container resource      
    type: string # type of the registry like ACR, GCR etc. 
    azureSubscription: string # Azure subscription (ARM service connection) for container registry;
    resourceGroup: string # resource group for your ACR
    registry: string # registry for container images
    repository: string # name of the container image repository in ACR
    trigger: # Triggers aren't enabled by default and need to be set explicitly
      enabled: boolean # set to 'true' to trigger on all image tags if 'tags' is unset.
      tags:
        include: [ string ]  # image tags to consider the trigger events, optional; defaults to any new tag
        exclude: [ string ]  # image tags on discard the trigger events, optional; defaults to none

注意

用來啟用所有映像標記之容器觸發程式的語法與enabled: 'true'用於其他資源觸發程式的語法不同。 請特別注意針對特定資源使用正確的語法。

注意

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

容器資源變數

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

容器資源變數可與 Docker 和 Azure Container Registry 搭配使用。 您無法針對本機映像容器使用容器資源變數。

resources.container.<Alias>.type
resources.container.<Alias>.registry
resources.container.<Alias>.repository
resources.container.<Alias>.tag 
resources.container.<Alias>.digest
resources.container.<Alias>.URI
resources.container.<Alias>.location

位置變數僅適用於 ACR 容器資源類型。

packages定義資源

您可以使用 NuGet 和 npm GitHub 套件作為 YAML 管線中的資源。

當您指定 package 資源時,請將套件設定為 NuGet 或 npm。 您也可以在發行新的套件版本時啟用自動化管線觸發程式。

若要使用 GitHub 套件,請使用個人存取令牌 (PAT) 型驗證,並建立使用 PAT 的 GitHub 服務連線。

根據預設,套件不會自動下載到作業中。 若要下載,請使用 getPackage

resources:
  packages:
    - package: myPackageAlias # alias for the package resource
      type: Npm # type of the package NuGet/npm
      connection: GitHubConnectionName # GitHub service connection with the PAT type
      name: nugetTest/nodeapp # <Repository>/<Name of the package>
      version: 1.0.1 # Version of the package to consume; Optional; Defaults to latest
      trigger: true # To enable automated triggers (true/false); Optional; Defaults to no triggers

webhooks定義資源

注意

Webhook 已在 Azure DevOps Server 2020.1 中發行。

透過其他資源 (例如管線、容器、組建和套件),您可以取用成品,並啟用自動化 觸發程序。 但您無法根據其他外部事件或服務,將部署程序自動化。 資源 webhooks 可讓您整合管線與任何外部服務,並將工作流程自動化。 您可以透過其 Webhook (GitHub、GitHub Enterprise、Nexus、Artifactory 等) 訂閱任何外部事件,並觸發管線。

請執行下列步驟來設定 Webhook 觸發程式。

  1. 在您的外部服務上設定 Webhook。 當您建立 Webhook 時,必須提供下列資訊:

    • 要求 URL

      https://dev.azure.com/<ADO Organization>/_apis/public/distributedtask/webhooks/<WebHook Name>?api-version=6.0-preview
      
    • 秘密 - 選擇性。 如果您需要保護您的 JSON 承載,請提供 秘密 值。

  2. 建立新的「傳入 Webhook」服務連線。 此連線是新導入的服務連線類型,可讓您定義下列重要資訊:

    • Webhook 名稱:Webhook 的名稱應符合在外部服務中建立的 Webhook。
    • HTTP 標頭 - 要求中包含承載 HMAC-SHA1 哈希值的要求中 HTTP 標頭的名稱,以進行要求驗證。 例如,針對 GitHub,要求標頭為 「X-Hub-Signature」。。
    • 秘密 - 秘密是用來驗證傳入要求的承載 HMAC-SHA1 哈希(選擇性)。 如果您在建立 Webhook 時使用了秘密,則必須提供相同的秘密金鑰。

    Incoming Webhook Service connection

  3. YAML 管線中引進名為 webhooks 的新資源類型。 若要訂閱 Webhook 事件,請在管線中定義 Webhook 資源,並將其指向傳入 Webhook 服務連線。 您也可以根據 JSON 承載數據,在 Webhook 資源上定義更多篩選,以自定義每個管線的觸發程式。 以作業中的變數形式取用承載數據。

  4. 每當傳入 Webhook 服務連線收到 Webhook 事件時,就會針對訂閱 Webhook 事件的所有管線觸發新的執行。 您可以使用 格式取用作業中的 JSON 承載資料 ${{ parameters.<WebhookAlias>.<JSONPath>}}

resources:
  webhooks:
    - webhook: MyWebhookTriggerAlias           ### Webhook alias
      connection: IncomingWebhookConnection    ### Incoming webhook service connection
      filters:                                 ### List of JSON parameters to filter; Parameters are AND'ed
        - path: JSONParameterPath              ### JSON path in the payload
          value: JSONParameterExpectedValue    ### Expected value in the path provided

Webhook 會根據一流資源不支援的任何外部 Webhook 事件,例如管線、組建、容器和套件,將工作流程自動化。 此外,對於 Azure DevOps 無法查看程式的內部部署服務,您可以在服務上設定 Webhook,並自動觸發管線。

在 [建立執行] 對話框中手動選擇資源的版本選擇器

當您手動觸發CD YAML管線時,我們會根據提供的輸入,自動評估管線中定義之資源的預設版本。 不過,當您建立執行時,您可以選擇從資源版本選擇器挑選不同的版本。

  1. 在 [ 建立執行] 窗格中,選取 [ 資源]。 您會看到此管線中耗用的資源清單。

  2. 選取資源,並從可用的版本清單中挑選特定版本。 管線、組建、存放庫、容器和套件資源支援資源版本選擇器。

    Pipeline Version Picker

針對管線資源,您可以看到所有分支上所有可用的執行。 根據管線編號或分支來搜尋它們。 而且,挑選成功、失敗或進行中的執行。 如果您確定CD管線已產生您需要的所有成品,此彈性可確保您可以執行CD管線。 您不需要等候 CI 執行完成或重新執行,因為 CI 執行中的不相關階段失敗。 不過,只有在評估排程觸發程式的預設版本時,或您不使用手動版本選擇器時,才會考慮成功完成 CI 執行。

對於您無法擷取可用版本的資源,例如 GitHub 套件,我們會在版本選擇器中顯示文字框,以便提供執行挑選的版本。

授權 YAML 管線

資源必須先獲得授權,才能使用資源。 資源擁有者會控制可存取該資源的使用者和管線。 管線必須經過授權,才能使用資源。 請參閱下列您可以授權 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 範本延伸。 設定必要的範本核准可增強安全性。 請確定您的資源只會在範本的特定條件下使用。 深入瞭解如何使用 範本和資源增強管線安全性

可追蹤性

我們提供管線或部署作業層級所取用之任何資源的完整可追蹤性。

管線可追蹤性

對於每個管線執行,我們都會顯示下列資訊。

  • 如果已由資源觸發,則觸發管線的資源。

    Resource trigger in a pipeline

  • 資源的版本和取用的成品。

    Consumed artifacts in pipeline run

  • 與每個資源相關聯的認可。

    Commits in pipeline run

  • 與每個資源相關聯的工作專案。

環境可追蹤性

每當管線部署到環境時,您可以看到已取用的資源清單。 下列檢視包含作為部署作業一部分所耗用的資源,以及其相關聯的認可和工作專案。

Commits in environment

在 CI 管線中顯示相關聯的 CD 管線資訊

若要提供端對端可追蹤性,您可以追蹤哪些 CD 管線正在取用提供 CI 管線。 您可以看到 CD YAML 管線執行的清單,其中 CI 管線執行是透過 pipeline 資源取用的。 如果其他管線取用 CI 管線,您會在執行檢視中看到 [相關聯的管線] 索引標籤。 您可以在這裡找到取用管線和成品的所有管線執行。

CD pipelines information in CI pipeline

YAML 資源觸發程式問題支援和可追蹤性

當管線觸發程式無法執行時,可能會造成混淆。 我們已在管線定義頁面中新增名為 [觸發程序問題] 的新功能表項,您可以在其中了解觸發程式未執行的原因。 若要存取此頁面,請開啟您的管線歷程記錄。 觸發程式問題 僅適用於非存放庫資源。

Select Trigger Issues from the navigation.

資源觸發程式可能因為下列原因而無法執行。

  • 如果所提供的服務連線來源無效,或觸發程式中有任何語法錯誤,則不會設定觸發程式,而導致錯誤。

  • 如果觸發條件不相符,則不會執行觸發程式。 系統會顯示警告,讓您了解條件不相符的原因。

    Trigger issues supportability

下一步

常見問題集

為什麼應該使用管線 resources 而不是 download 快捷方式?

pipelines使用資源是取用 CI 管線中的成品,以及設定自動化觸發程式的方式。 資源可讓您完整查看程式,方法是顯示已取用的版本、成品、認可和工作專案。 當您定義管線資源時,相關聯的成品會自動在部署作業中下載。

您可以選擇下載組建作業中的成品,或使用 覆寫部署作業 download中的下載行為。 如需詳細資訊,請參閱 steps.download

為何應該使用 resources 而不是下載管線成品工作?

當您直接使用 下載管線成品工作 時,會遺漏可追蹤性和觸發程式。 有時候直接使用下載管線成品工作很合理。 例如,您可能將腳本工作儲存在不同的範本中,而腳本工作需要從組建下載成品。 或者,您可能不知道使用範本的人員是否想要新增管線資源。 若要避免相依性,您可以使用下載管線成品工作,將所有建置資訊傳遞至工作。

如何在 Docker Hub 映射更新時觸發管線執行?

您必須設定傳統發行管線因為容器資源觸發程式不適用於適用於 YAML 管線的 Docker Hub。

  1. 建立新的 Docker Hub 服務連線

  2. 建立傳統發行管線並新增 Docker Hub 成品。 設定您的服務連線。 選取命名空間、存放庫、版本和來源別名。

    Add a Docker Hub artifact.

  3. 選取觸發程式,並將持續部署觸發程式切換為 [啟用]。 每次 Docker 推送至選取的存放庫時,您都會建立發行。

  4. 建立新的階段和作業。 新增兩個工作:Docker 登入和 Bash:

  • Docker 工作具有動作, login 並將您記錄到 Docker Hub。

  • Bash 工作會執行 docker pull <hub-user>/<repo-name>[:<tag>]。 以您的值取代 hub-userrepo-nametag

    Add Docker login and Bash tasks.

如何驗證和疑難解答 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. 選取 [更多動作] 選單 Select more actions menu
    4. 選取 [觸發程式>YAML>取得來源]。
    5. 移至 [預設分支] 以取得手動和排程的組建 ,以更新您的功能分支。
    6. 選取 [ 儲存和佇列]。
    7. 成功執行此管線之後,請在主體https://dev.azure.com/{organization}/_apis/public/distributedtask/webhooks/{webhook-name}?api-version={apiversion}中對 執行POST具有有效 JSON 的 API 呼叫。 您現在應該會收到 200 狀態代碼回應。