YAML 파이프라인의 리소스

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022 | Azure DevOps Server 2020

이 문서에서는 YAML 파이프라인에 대한 리소스에 대해 설명합니다. 리소스는 해당 파이프라인 외부에 있는 파이프라인에서 사용하는 모든 항목입니다. YAML 파이프라인의 리소스는 다른 파이프라인, 빌드, 컨테이너, 패키지, 리포지토리 또는 웹후크일 수 있습니다.

리소스를 정의한 후에는 파이프라인의 어디에서나 리소스를 사용할 수 있습니다. 자세한 내용 및 예제는 리소스 정의를 참조하세요.

resources:
  pipelines:
  - pipeline: resources1
    source: otherPipeline

steps:
- download: resources1
  artifact: artifact1.txt

리소스 상태를 사용하여 리소스 정의에서 속성을 설정하여 파이프라인을 자동으로 트리거 할 trigger 수 있습니다. 그런 다음 파이프라인 resources.triggeringAlias 및 resources.triggeringCategory 변수가 리소스 이름 및 범주로 설정됩니다. 변수를 .로 설정Build.Reason하지 않으면 ResourceTrigger 이러한 변수는 비어 있습니다.

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

리소스 권한 부여

리소스는 파이프라인에서 사용할 수 있는 권한을 부여받아야 합니다. 리소스 소유자는 리소스에 액세스할 수 있는 사용자 및 파이프라인을 제어합니다. 리소스를 사용하도록 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(연속 통합) 실행만을 고려하여 기본 리소스 버전을 평가합니다.

수동 리소스 버전 선택기를 사용하여 YAML CD(지속적인 배포) 파이프라인을 수동으로 트리거할 때 다른 리소스 버전을 선택할 수 있습니다. 리소스 버전 선택기는 파이프라인, 빌드, 리포지토리, 컨테이너 및 패키지 리소스에 대해 지원됩니다.

리소스의 경우 pipeline 수동 버전 선택을 통해 모든 분기에서 사용 가능한 모든 실행을 확인하고, 파이프라인 번호 또는 분기에 따라 실행을 검색하고, 성공, 실패 또는 진행 중인 실행을 선택할 수 있습니다.

CD 파이프라인을 실행하기 전에 CI 실행이 완료될 때까지 기다리거나 관련 없는 오류로 인해 다시 실행할 필요가 없습니다. 필요한 아티팩트가 생성된 것으로 알고 있는 모든 실행을 유연하게 선택할 수 있습니다.

리소스 버전 선택기를 사용하려면 파이프라인 실행 창에서 리소스를 선택하고, 리소스를 선택하고, 사용 가능한 버전 목록에서 특정 버전을 선택합니다. GitHub 패키지와 같이 사용 가능한 버전을 가져올 수 없는 리소스의 경우 텍스트 필드에 원하는 버전을 입력할 수 있습니다.

리소스 정의

YAML 파이프라인 리소스는 다음과 같습니다.

• 기타 파이프라인
• 빌드
• 컨테이너
• 패키지
• 리포지토리 또는
• 웹후크.

다음 섹션에서는 YAML 파이프라인 리소스 범주의 정의 및 예제를 제공합니다. 전체 스키마 정보는 Azure Pipelines에 대한 YAML 스키마 참조의 리소스 정의를 참조하세요.

파이프라인 리소스

CI pipeline 리소스를 CD 워크플로 의 트리거 로 사용할 수 있습니다. 파이프라인에서 리소스를 참조 pipeline 하여 아티팩트 다운로드 또는 파이프라인 리소스 변수를 사용할 수도 있습니다. Azure Pipelines만 pipelines 리소스를 사용할 수 있습니다.

리소스 정의에서 다음을 수행 pipelines 합니다.

• pipeline 는 파이프라인 리소스를 참조하는 데 사용하는 고유한 이름입니다.
• source 는 파이프라인 아티팩트 생성 파이프라인의 이름입니다.

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

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

다음 예제 리소스 정의는 동일한 Azure DevOps 프로젝트 내의 파이프라인에서 아티팩트를 사용합니다.

resources:
  pipelines:
  - pipeline: SmartHotel-resource # identifier to use in pipeline resource variables
    source: SmartHotel-CI # name of the pipeline that produces the artifacts

다른 프로젝트에서 파이프라인을 지정하려면 리소스 정의에 project 이름을 포함합니다. 다음 예제에서는 파이프라인이 수동으로 또는 일정에 따라 트리거될 때 기본 버전을 확인하는 데도 사용합니다 branch . 분기 입력에는 와일드카드가 있을 수 없습니다.

resources:
  pipelines:
  - pipeline: SmartHotel
    project: otherDevOpsProject
    source: SmartHotel-CI
    branch: releases/M142

리소스 버전 평가

Azure Pipelines는 리소스 정의에 따라 리소스에 대한 기본 버전을 평가합니다. 파이프라인의 기본 리소스 아티팩트 버전은 파이프라인이 수동 또는 일정에 따라 실행되는지 또는 리소스 실행 결과에 따라 트리거 되는지에 따라 달라집니다.

수동 또는 예약된 파이프라인 실행의 경우 리소스 정의의 version값 branch및 tags 속성은 pipeline 아티팩트 버전을 정의합니다. 입력에는 branch 와일드카드가 있을 수 없으며 속성은 tags 연산자를 AND 사용합니다.

예약된 실행 또는 버전 선택기를 사용하지 않는 경우 수동 실행의 경우 Azure Pipelines는 기본 리소스 버전을 평가할 때 성공적으로 완료된 CI(연속 통합) 실행만 고려합니다. 수동 실행의 경우 수동 버전 선택기를 사용하여 정의된 버전을 재정의할 수 있습니다.

다음 표에는 리소스 정의 속성 및 해당 속성이 지정하는 아티팩트 버전이 나열 pipeline 되어 있습니다.

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

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

파이프라인 리소스 트리거

리소스 실행 결과에 대해 트리거되는 파이프라인 실행 trigger 의 경우 리소스 정의의 속성 설정에 따라 기본 리소스 아티팩트 버전이 결정됩니다. 리소스를 pipeline 트리거로 사용하여 현재 파이프라인을 실행하려면 속성을 설정 trigger 해야 합니다. 속성을 포함하지 trigger 않으면 리소스 실행이 현재 파이프라인 실행을 트리거하지 않습니다.

파이프라인이 리소스 정의의 값을 기반으로 trigger 트리거되면 전체 리소스 정의 pipelineversion및 branch 속성의 값이 무시 tags 됩니다. 속성은 trigger 아티팩트 버전을 결정합니다.

다음 표에서는 속성이 트리거 동작에 trigger 미치는 영향을 설명합니다.

다음 예제에서는 간단한 trigger파이프라인 리소스 정의를 보여 줍니다.

resources:
  pipelines:
  - pipeline: SmartHotel
    project: otherDevOpsProject
    source: SmartHotel-CI
    trigger: true

다음 예제에서는 분기 조건이 있는 파이프라인 리소스 trigger 를 보여줍니다.

resources:
  pipelines:
  - pipeline: SmartHotel
    project: otherDevOpsProject
    source: SmartHotel-CI
    trigger:
      branches:
      - releases/*
      - resources.triggeringAlias

다음 예제에서는 필터를 사용하여 stages CD 파이프라인에 대한 트리거 조건을 평가합니다. 트리거 stages 는 연산자를 AND 사용합니다. 나열된 모든 단계가 성공적으로 완료되면 CD 파이프라인이 트리거됩니다.

resources:
  pipelines:
  - pipeline: MyCIAlias  
    project: Fabrikam  
    source: Fabrikam-CI  
    trigger:    
      stages:
      - PreProduction
      - Production

다음 예제에서는 기본 버전 평가 및 트리거에 필터를 사용합니다 tags . 태그는 trigger 연산자를 AND 사용합니다. 리소스 정의의 tags 집합은 pipeline Git 리포지토리의 분기에 설정된 태그와 다릅니다.

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Fabrikam-CI
    tags: 
    - Production 
    trigger:
      tags:
      - Production
      - Signed

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

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

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

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

YAML 파이프라인의 download 단계를 사용하여 현재 실행 또는 다른 pipeline 리소스와 연결된 아티팩트를 다운로드할 수 있습니다.

아티팩트가 배포 작업에서만 자동으로 다운로드됩니다. 현재 파이프라인의 모든 아티팩트와 모든 리소스는 pipeline 자동으로 다운로드되며 각 배포 작업의 시작 부분에서 사용할 수 있습니다. 설정하거나 다른 download 리소스 식별자를 지정하여 이 동작 none 을 재정의할 pipeline수 있습니다.

일반 빌드 작업에서는 아티팩트가 자동으로 다운로드되지 않습니다. 필요한 경우 명시적으로 사용합니다 download .

이 download 단계에서 선택적 artifact 속성은 아티팩트 이름을 지정합니다. 지정하지 않으면 사용 가능한 모든 아티팩트가 다운로드됩니다.

선택적 patterns 속성은 다운로드할 파일을 나타내는 패턴을 정의합니다. 전체 스키마 정보는 steps.download 정의를 참조하세요.

- job: deploy_windows_x86_agent
  steps:
  - download: SmartHotel
    artifact: WebTier1
    patterns: '**/*.zip'

리소스의 아티팩트가 pipeline$(PIPELINE)로 다운로드됩니다. WORKSPACE)/<pipeline-identifier>/<artifact-identifier> 폴더입니다. 자세한 내용은 파이프라인 아티팩트 게시 및 다운로드를 참조 하세요. 파이프라인 아티팩트를 다운로드하는 다른 방법은 아티팩트 다운로드를 참조 하세요.

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 아티팩트를 사용할 수 있습니다.

범주를 builds 확장할 수 있습니다. 리소스는 build Jenkins, TeamCity 또는 CircleCI와 같은 외부 CI 시스템에서 사용할 수 있습니다. 확장을 작성하여 빌드 서비스에서 아티팩트를 사용 builds 하거나 새로운 유형의 서비스를 도입할 수 있습니다.

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

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

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

downloadBuild 작업

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

태스크는 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는 git, github및 githubenterprisebitbucket 리포지토리 유형을 지원합니다.

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

다음 표에서는 리소스 종류에 대해 repository 설명합니다.

리포지토리 리소스 변수

resources.repositories.<alias>.name
resources.repositories.<alias>.ref
resources.repositories.<alias>.type
resources.repositories.<alias>.id
resources.repositories.<alias>.url

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

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

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* 

컨테이너 리소스 변수

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

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

다음 예제에는 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)

resources:
  packages:
    - package: contoso
      type: npm
      connection: pat-contoso
      name: myname/contoso 
      version: 7.130.88 
      trigger: true

steps:
- getPackage: contoso

resources:
  webhooks:
    - webhook: myWebhookResource
      connection: myWebHookConnection

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

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}}

{
    "resource": {
        "message": {
            "title": "Hello, world!",
            "subtitle": "I'm using WebHooks!"
        }
    }
}

추적 기능

Azure Pipelines는 파이프라인 또는 배포 작업 수준에서 사용되는 모든 리소스에 대한 전체 추적 기능을 제공합니다. Azure Pipelines는 리소스를 사용하는 모든 파이프라인 실행에 대해 다음 정보를 보여 줍니다.

• 리소스가 파이프라인을 트리거한 경우 파이프라인을 트리거한 리소스입니다.
• 리소스 버전 및 사용된 아티팩트입니다.
• 각 리소스와 연결된 커밋입니다.
• 각 리소스와 연결된 작업 항목입니다.

CI 파이프라인에 대한 관련 CD 파이프라인 정보

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

환경 추적 가능성

파이프라인이 환경에 배포된 후 사용한 리소스 목록과 연결된 커밋 및 작업 항목을 볼 수 있습니다.

FAQ

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

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

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

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

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

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

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

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

1. 서비스 연결을 만듭니다.

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

   resources:
     webhooks:
       - webhook: MyWebhookTriggerAlias
         connection: MyServiceConnection
   

3. 파이프라인을 실행하세요. 웹후크는 조직의 분산 작업으로 Azure에서 만들어집니다.

4. 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 상태 코드 응답을 받으면 코드가 기본 분기 아닌 분기에 있을 수 있습니다. 문제 해결 방법:

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

리소스 트리거가 작동하지 않는 이유는 무엇인가요?

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

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

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

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

관련 콘텐츠

• Azure Pipelines에 대한 리소스 정보
• 변수 정의
• 변수 그룹 추가 및 사용
• 환경 만들기 및 대상 지정
• YAML 파이프라인 편집기 사용
• YAML 스키마 참조