YAML 파이프라인의 리소스

아티클
07/02/2024

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

이 문서에서는 YAML 파이프라인에 대한 리소스에 대해 설명합니다. 리소스는 파이프라인 외부에 있는 파이프라인에서 사용하는 모든 항목입니다. 리소스를 정의한 후에는 파이프라인의 어디에서나 리소스를 사용할 수 있습니다.

리소스는 버전, 아티팩트, 연결된 커밋 및 작업 항목을 포함하여 파이프라인에서 사용하는 서비스에 대한 전체 추적 기능을 제공합니다. 리소스에서 이벤트를 트리거하도록 구독하여 DevOps 워크플로를 완전히 자동화할 수 있습니다.

리소스 스키마

YAML의 리소스는 파이프라인, 빌드, 리포지토리, 컨테이너, 패키지 및 웹후크의 원본을 나타냅니다. 전체 스키마 정보는 Azure Pipelines에 대한 YAML 스키마 참조의 리소스 정의를 참조하세요.

리소스가 파이프라인을 트리거하면 다음 변수가 설정됩니다.

resources.triggeringAlias
resources.triggeringCategory

이러한 값을 설정하려면 변수 Build.Reason 여야 ResourceTrigger 합니다. 리소스가 파이프라인 실행을 트리거하지 않은 경우 값은 비어 있습니다.

파이프라인 리소스 정의

아티팩트를 생성하는 파이프라인이 있는 경우 리소스를 정의하여 아티팩트를 pipelines 사용할 수 있습니다. Azure Pipelines만 리소스를 pipelines 사용할 수 있습니다. 파이프라인 리소스에서 CD(지속적인 배포) 워크플로에 대한 트리거를 설정할 수 있습니다.

리소스 정의 pipeline 에서 파이프라인의 뒷부분에서 파이프라인 리소스를 참조하는 데 사용할 수 있는 고유한 값입니다. 파이프라인 source 아티팩트가 생성된 파이프라인의 이름입니다. 전체 스키마 정보는 resources.pipelines.pipeline 정의를 참조 하세요.

파이프라인 pipeline 리소스 변수를 사용하거나 아티팩트 다운로드하는 경우와 같이 정의된 레이블을 사용하여 파이프라인의 다른 부분에서 파이프라인 리소스를 참조합니다. 파이프라인 아티팩트를 다운로드하는 다른 방법은 아티팩트 다운로드를 참조 하세요.

Important

파이프라인 리소스 트리거를 정의하는 경우:

리소스가 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

다음 예제에서는 CD 파이프라인에 대한 트리거 조건을 평가하기 위해 필터를 사용합니다 stages . 스테이지는 연산자를 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` 목록	지정된 태그가 모두 있는 지정된 분기에서 수행된 최신 빌드의 아티팩트
None	모든 분기에서 최신 빌드의 아티팩트

다음 pipeline 리소스 정의는 파이프라인이 branch 수동으로 트리거되거나 예약될 때 및 tags 속성을 사용하여 기본 버전을 평가합니다. 파이프라인을 수동으로 트리거하여 실행 MyCIAlias 하면 파이프라인 아티팩트 버전은 태그와 PrepProduction 태그가 있는 분기에서 main 수행되는 Production 최신 빌드입니다.

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

리소스 파이프라인 완료 트리거

리소스 파이프라인 중 하나가 완료되어 파이프라인이 트리거되면 아티팩트 버전은 트리거 파이프라인의 버전입니다. 및 branchtags 속성의 version값은 무시됩니다.

지정된 트리거	결과
`branches`	새 파이프라인 실행은 리소스 파이프라인이 분기 중 `include` 하나에서 실행을 성공적으로 완료할 때마다 트리거됩니다.
`tags`	리소스 파이프라인이 지정된 모든 태그로 태그가 지정된 실행을 성공적으로 완료할 때마다 새 파이프라인 실행이 트리거됩니다.
`stages`	새 파이프라인 실행은 리소스 파이프라인이 지정된 `stages`것을 성공적으로 실행할 때마다 트리거됩니다.
`branches`, `tags` 및 `stages`	새 파이프라인 실행은 리소스 파이프라인 실행이 모든 분기, 태그 및 스테이지 조건을 충족할 때마다 트리거됩니다.
`trigger: true`	새 파이프라인 실행은 리소스 파이프라인이 실행을 성공적으로 완료할 때마다 트리거됩니다.
없음	리소스 파이프라인이 실행을 성공적으로 완료할 때 새 파이프라인 실행 트리거가 없습니다.

다음 파이프라인은 리소스 파이프라인이 실행 될 SmartHotel-CI 때마다 실행됩니다.

분기 중 releases 하나 또는 분기에서 main 실행
둘 다 Verified 로 태그가 지정됩니다. Signed
단계와 PreProduction 단계를 모두 Production 완료합니다.

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 Jenkins, TeamCity 또는 CircleCI와 같은 외부 CI 시스템에서 사용할 수 있습니다.

범주를 builds 확장할 수 있습니다. 확장을 작성하여 빌드 서비스의 아티팩트를 사용하고 새 유형의 서비스를 도입할 builds수 있습니다.

정의 version 에서 build 기본값은 성공적인 최신 빌드입니다. trigger 기본적으로 사용하도록 설정되지 않으며 명시적으로 설정해야 합니다. 전체 스키마 정보는 resources.builds.build 정의를 참조 하세요.

다음 예제에서 Jenkins는 리소스 type입니다.

resources:
  builds:
  - build: Spaceworkz
    type: Jenkins
    connection: MyJenkinsServer 
    source: SpaceworkzProj   # name of the Jenkins source project
    trigger: true

Important

트리거는 Azure DevOps가 Jenkins 서버와 시야를 가지고 있는 경우에만 호스트된 Jenkins에 대해 지원됩니다.

downloadBuild 작업

build 리소스 아티팩트가 작업/배포 작업에서 자동으로 다운로드되지 않습니다. 작업의 일부로 리소스의 build 아티팩트를 사용하려면 작업을 명시적으로 추가 downloadBuild 해야 합니다. 각 배포 또는 작업에 대한 다운로드 동작을 사용자 지정할 수 있습니다.

이 작업은 런타임에서 정의하는 리소스 유형 build 에 대한 해당 다운로드 작업으로 자동으로 확인됩니다. 리소스의 build 아티팩트가 $(PIPELINE)로 다운로드됩니다. WORKSPACE)/<build-identifier>/ folder.

정의에서 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.repositories.repository 정의를 참조 하세요.

리포지토리 리소스 종류

Azure Pipelines는 리포지토리 유형gitgithubgithubenterprisebitbucket에 대해 다음 값을 지원합니다.

이 형식은 git Azure Repos Git 리포지토리를 참조합니다.
GitHub Enterprise 리포지토리는 권한 부여를 위해 GitHub Enterprise 서비스 연결 이 필요합니다.
Bitbucket Cloud 리포지토리는 권한 부여를 위해 Bitbucket Cloud 서비스 연결 이 필요합니다.

Type	이름 값	예시
`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)"

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사용할 수 있습니다. 이 리소스 유형을 작업의 일부로 사용하고 자동 파이프라인 트리거를 사용하도록 설정할 수 있습니다.

자동 파이프라인 트리거를 사용하려면 Azure Container Registry에 대한 기여자 또는 소유자 권한이 필요합니다. 자세한 내용은 Azure Container Registry 역할 및 권한을 참조하세요.

리소스 종류를 사용 acr 하려면 Azure Container Registry에 azureSubscription대한 값 resourceGroup및 repository 값을 지정해야 합니다. 예시:

resources:         
  containers:
  - container: petStore      
    type: acr  
    azureSubscription: ContosoConnection
    resourceGroup: ContosoGroup
    registry: petStoreRegistry
    repository: myPets
    trigger: 
      tags:
        include: 
        - production*

참고 항목

워크로드 ID 페더레이션을 사용하는 서비스 연결은 .에서 azureSubscription지원되지 않습니다.

컨테이너 리소스 변수

컨테이너를 리소스로 정의하면 컨테이너 이미지 메타데이터가 파이프라인에 변수로 전달됩니다. 이미지, 레지스트리 및 연결 세부 정보와 같은 정보는 컨테이너 배포 작업에 사용되는 모든 작업에서 액세스할 수 있습니다.

컨테이너 리소스 변수는 Docker 및 Azure Container Registry에서 작동합니다. 로컬 이미지 컨테이너에는 컨테이너 리소스 변수를 사용할 수 없습니다. 변수는 location 컨테이너 리소스의 형식에 acr 만 적용됩니다.

다음 예제에는 Azure Resource Manager 서비스 연결이 있습니다arm-connection. 자세한 내용은 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 패키지를 리소스로 사용할 수 있습니다. 새 패키지 버전이 릴리스될 때 자동화된 파이프라인 트리거를 사용하도록 설정하려면 속성을 true.로 설정합니다trigger.

리소스를 정의 package 할 때 속성에서 name 패키지 <리포지토리>/이름을> 지정하고 패키지를 type 로 NuGetnpm설정합니다. GitHub 패키지를 사용하려면 PAT(개인 액세스 토큰) 기반 인증을 사용하고 PAT를 사용하는 GitHub 서비스 연결을 만듭니다.

전체 스키마 정보는 resources.packages.package 정의를 참조 하세요.

기본적으로 패키지는 작업에 자동으로 다운로드되지 않습니다. 다운로드하려면 getPackage를 사용합니다.

다음 예제에는 이름이 GitHub npm 패키지로 명명된 pat-contoso GitHub 서비스 연결이 있습니다contoso. 자세한 내용은 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

웹후크 리소스 정의

참고 항목

웹후크는 Azure DevOps Server 2020.1에서 릴리스되었습니다.

아티팩트 사용 및 파이프라인, 컨테이너, 빌드 및 패키지 리소스를 사용하여 자동화된 트리거를 사용하도록 설정할 수 있습니다. 그러나 이러한 리소스를 사용하여 외부 이벤트 또는 서비스를 기반으로 배포를 자동화할 수는 없습니다.

webhooks YAML 파이프라인의 리소스를 사용하면 GitHub, GitHub Enterprise, Nexus 및 Artifactory와 같은 외부 서비스와 파이프라인을 통합하여 워크플로를 자동화할 수 있습니다. 웹후크를 통해 외부 이벤트를 구독하고 이벤트를 사용하여 파이프라인을 트리거할 수 있습니다.

웹후크는 파이프라인, 빌드, 컨테이너 또는 패키지와 같은 일류 리소스에서 지원되지 않는 외부 웹후크 이벤트를 기반으로 워크플로를 자동화합니다. 또한 Azure DevOps에서 프로세스에 대한 가시성이 없는 온-프레미스 서비스의 경우 서비스에서 웹후크를 구성하고 파이프라인을 자동으로 트리거할 수 있습니다.

웹후크 이벤트를 구독하려면 파이프라인에서 웹후크 리소스를 정의하고 들어오는 웹후크 서비스 연결을 가리킵니다. JSON 페이로드 데이터를 기반으로 웹후크 리소스에 대한 더 많은 필터를 정의하여 각 파이프라인에 대한 트리거를 사용자 지정할 수도 있습니다.

들어오는 웹후크 서비스 연결이 웹후크 이벤트를 받을 때마다 웹후크 이벤트를 구독하는 모든 파이프라인에 대해 새 실행이 트리거됩니다. 형식 ${{ parameters.<WebhookAlias>.<JSONPath>}}을 사용하여 작업의 JSON 페이로드 데이터를 변수로 사용할 수 있습니다.

전체 스키마 정보는 resources.webhooks.webhook 정의를 참조 하세요.

다음 예제에서는 웹후크 리소스를 정의합니다.

resources:
  webhooks:
    - webhook: WebHook
      connection: IncomingWH

steps:  
- script: echo ${{ parameters.WebHook.resource.message.title }}

웹후크 트리거

웹후크 트리거를 구성하려면 먼저 외부 서비스에 웹후크를 설정하고 다음 정보를 제공합니다.

요청 URL: https://dev.azure.com/<Azure DevOps organization>/_apis/public/distributedtask/webhooks/<webhook name>?api-version=6.0-preview
비밀 (선택 사항): JSON 페이로드를 보호해야 하는 경우 비밀 값을 제공합니다.

다음으로 들어오는 웹후크 서비스 연결을 새로 만듭니다. 이 서비스 연결 형식의 경우 다음 정보를 정의합니다.

WebHook 이름: 외부 서비스에서 만든 웹후크와 동일합니다.
비밀 (선택 사항): 들어오는 요청을 확인하기 위해 페이로드의 HMAC-SHA1 해시를 확인하는 데 사용됩니다. 웹후크를 만들 때 비밀을 사용한 경우 동일한 비밀을 제공해야 합니다.
Http 헤더: 요청 확인을 위한 페이로드의 HMAC-SHA1 해시 값을 포함하는 요청의 HTTP 헤더입니다. 예를 들어 GitHub 요청 헤더는 .입니다 X-Hub-Signature.

들어오는 웹후크 서비스 연결을 보여 주는 스크린샷

웹후크를 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!"
        }
    }
}

참고 항목

웹후크의 요청 본문에서 데이터에 액세스하면 잘못된 YAML이 발생할 수 있습니다. 예를 들어 파이프라인 단계는 - script: echo ${{ parameters.WebHook.resource.message }} 전체 JSON 메시지를 끌어와 잘못된 YAML을 생성합니다. 생성된 YAML이 유효하지 않으므로 이 웹후크를 통해 트리거된 파이프라인은 실행되지 않습니다.

다음 코드 조각은 웹후크 필터를 사용하는 또 다른 예제를 보여 줍니다.

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 파이프라인 정보

엔드 투 엔드 추적 기능을 제공하기 위해 리소스를 통해 특정 CI 파이프라인을 사용하는 CD 파이프라인을 pipelines 추적할 수 있습니다. 다른 파이프라인에서 CI 파이프라인을 사용하는 경우 실행 보기에 연결된 파이프라인 탭이 표시됩니다. 보기에는 CI 파이프라인을 사용한 모든 CD YAML 파이프라인 실행과 해당 파이프라인의 아티팩트가 표시됩니다.

CI 파이프라인의 CD 파이프라인 정보를 보여 주는 스크린샷

리소스 트리거 문제

리소스 트리거는 다음 때문에 실행하지 못할 수 있습니다.

제공된 서비스 연결의 원본이 잘못되었거나, 트리거에 구문 오류가 있거나, 트리거가 구성되지 않았습니다.
트리거 조건이 일치하지 않습니다.

파이프라인 트리거를 실행하지 못한 이유를 확인하려면 파이프라인 정의 페이지에서 트리거 문제 메뉴 항목을 선택합니다. 트리거 문제는 비리포지토리 리소스에만 사용할 수 있습니다.

트리거 문제 페이지에서 오류 및 경고 메시지는 트리거가 실패한 이유를 설명합니다.

트리거 문제 지원 가능성을 보여 주는 스크린샷

FAQ

파이프라인 리소스, 다운로드 바로 가기 또는 파이프라인 아티팩트 다운로드 작업은 언제 사용해야 하나요?

리소스를 pipelines 사용하는 것은 CI 파이프라인에서 아티팩트를 사용하고 자동화된 트리거를 구성하는 방법입니다. 리소스를 사용하면 사용된 버전, 아티팩트, 커밋 및 작업 항목을 표시하여 프로세스에 대한 모든 가시성을 제공합니다. 파이프라인 리소스를 정의하면 연결된 아티팩트가 배포 작업에서 자동으로 다운로드됩니다.

바로 가기를 download 사용하여 빌드 작업의 아티팩트 다운로드 또는 배포 작업의 다운로드 동작을 재정의할 수 있습니다. 자세한 내용은 steps.download 정의를 참조 하세요.

파이프라인 아티팩트 다운로드 작업은 추적성 또는 트리거를 제공하지 않지만 이 작업을 직접 사용하는 것이 타인의 경우도 있습니다. 예를 들어 빌드의 아티팩트를 다운로드해야 하는 스크립트 작업이 다른 템플릿에 저장되어 있을 수 있습니다. 또는 템플릿에 파이프라인 리소스를 추가하지 않을 수도 있습니다. 종속성을 방지하려면 파이프라인 아티팩트 다운로드 작업을 사용하여 모든 빌드 정보를 작업에 전달할 수 있습니다.

Docker Hub 이미지가 업데이트되면 파이프라인 실행을 트리거하려면 어떻게 해야 하나요?

YAML 파이프라인용 Docker Hub에는 컨테이너 리소스 트리거를 사용할 수 없으므로 클래식 릴리스 파이프라인을 설정해야 합니다.

새 Docker Hub 서비스 연결을 만듭니다.
클래식 릴리스 파이프라인을 만들고 Docker Hub 아티팩트를 추가합니다. 서비스 연결을 설정하고 네임스페이스, 리포지토리, 버전 및 원본 별칭을 선택합니다.
트리거를 선택하고 연속 배포 트리거를 사용으로 전환합니다. 선택한 리포지토리에 발생하는 모든 Docker 푸시는 릴리스를 만듭니다.
새 단계 및 작업을 만듭니다. Docker 로그인과 Bash의 두 작업을 추가합니다.
- Docker 작업에는 login 작업이 있으며 Docker 허브에 로그인합니다.
- Bash 태스크가 실행됩니다 docker pull <hub-user>/<repo-name>[:<tag>].

웹후크의 유효성을 검사하고 문제를 해결하려면 어떻게 해야 하나요?

서비스 연결을 만듭니다.

서비스 연결을 참조하고 섹션에서 웹후크의 webhooks 이름을 지정합니다.

resources:
  webhooks:
    - webhook: MyWebhookTriggerAlias
      connection: MyServiceConnection

파이프라인을 실행합니다. 웹후크는 조직의 분산 작업으로 Azure에서 만들어집니다.
본문에서 POST 유효한 JSON을 사용하여 API 호출을 수행합니다 https://dev.azure.com/<organization>/_apis/public/distributedtask/webhooks/<webhook-name>?api-version=<apiversion>. 200 상태 코드 응답을 받으면 웹후크가 파이프라인에서 사용할 준비가 됩니다.

오류Cannot find webhook for the given webHookId ...와 함께 500 상태 코드 응답을 받으면 코드가 기본 분기 아닌 분기에 있을 수 있습니다. 문제 해결 방법:

파이프라인 페이지에서 편집을 선택합니다.
기타 작업 메뉴에서 트리거를 선택합니다.
YAML 탭을 선택한 다음 원본 가져오기를 선택합니다.
수동 및 예약된 빌드의 기본 분기에서 기능 분기 업데이트합니다.
저장 큐를 선택합니다.
이 파이프라인이 성공적으로 실행되면 본문에서 유효한 JSON을 POST 사용하여 API 호출을 수행합니다 https://dev.azure.com/<organization>/_apis/public/distributedtask/webhooks/<webhook-name>?api-version=<apiversion>. 이제 200 상태 코드 응답을 받게 됩니다.

다음을 통해 공유

YAML 파이프라인의 리소스

리소스 스키마

파이프라인 리소스 정의

파이프라인 리소스 정의 예제

파이프라인 아티팩트 버전 평가

수동 또는 예약된 트리거

리소스 파이프라인 완료 트리거

파이프라인 아티팩트 다운로드

파이프라인 리소스 변수

리소스 정의를 빌드합니다.

downloadBuild 작업

리포지토리 리소스 정의

리포지토리 리소스 종류

리포지토리 리소스 변수

리포지토리에 대한 체크 아웃 키워드

컨테이너 리소스 정의

Azure Container Registry 리소스 종류

컨테이너 리소스 변수

패키지 리소스 정의

웹후크 리소스 정의

웹후크 트리거

리소스에 대한 수동 버전 선택기

YAML 파이프라인의 리소스 권한 부여

리소스에 대한 승인 검사

추적 기능

파이프라인 추적 가능성

환경 추적 가능성

CI 파이프라인의 관련 CD 파이프라인 정보

리소스 트리거 문제

FAQ

파이프라인 리소스, 다운로드 바로 가기 또는 파이프라인 아티팩트 다운로드 작업은 언제 사용해야 하나요?

Docker Hub 이미지가 업데이트되면 파이프라인 실행을 트리거하려면 어떻게 해야 하나요?

웹후크의 유효성을 검사하고 문제를 해결하려면 어떻게 해야 하나요?

피드백

피드백

추가 리소스

다음을 통해 공유

YAML 파이프라인의 리소스

리소스 스키마

파이프라인 리소스 정의

파이프라인 리소스 정의 예제

파이프라인 아티팩트 버전 평가

수동 또는 예약된 트리거

리소스 파이프라인 완료 트리거

파이프라인 아티팩트 다운로드

파이프라인 리소스 변수

리소스 정의를 빌드합니다.

downloadBuild 작업

리포지토리 리소스 정의

리포지토리 리소스 종류

리포지토리 리소스 변수

리포지토리에 대한 체크 아웃 키워드

컨테이너 리소스 정의

Azure Container Registry 리소스 종류

컨테이너 리소스 변수

패키지 리소스 정의

웹후크 리소스 정의

웹후크 트리거

리소스에 대한 수동 버전 선택기

YAML 파이프라인의 리소스 권한 부여

리소스에 대한 승인 검사

추적 기능

파이프라인 추적 가능성

환경 추적 가능성

CI 파이프라인의 관련 CD 파이프라인 정보

리소스 트리거 문제

FAQ

파이프라인 리소스, 다운로드 바로 가기 또는 파이프라인 아티팩트 다운로드 작업은 언제 사용해야 하나요?

Docker Hub 이미지가 업데이트되면 파이프라인 실행을 트리거하려면 어떻게 해야 하나요?

웹후크의 유효성을 검사하고 문제를 해결하려면 어떻게 해야 하나요?

관련 콘텐츠

피드백

피드백

추가 리소스