Azure Repos Git 또는 TFS Git 리포지토리 빌드

아티클
07/03/2024

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

Azure Pipelines는 모든 끌어오기 요청을 자동으로 빌드하고 확인하고, Azure Repos Git 리포지토리를 커밋할 수 있습니다.

빌드할 리포지토리 선택

YAML
클래식

먼저 리포지토리를 선택한 다음 해당 리포지토리에서 YAML 파일을 선택하여 새 파이프라인을 만듭니다. YAML 파일이 있는 리포지토리를 리포지토리라고 합니다 self . 기본적으로 파이프라인이 빌드하는 리포지토리입니다.

나중에 다른 리포지토리 또는 여러 리포지토리를 체크 아웃하도록 파이프라인을 구성할 수 있습니다. 이 작업을 수행하는 방법을 알아보려면 다중 리포지토리 체크 아웃을 참조하세요.

파이프라인을 만드는 동안 빌드할 리포지토리를 선택하려면 먼저 리포지토리가 속한 프로젝트를 선택합니다. 그런 다음, 리포지토리를 선택합니다.

파이프라인의 일부로 추가 리포지토리를 복제하려면 다음을 수행합니다.

리포지토리가 파이프라인과 동일한 프로젝트에 있거나 액세스 토큰(아래 설명)이 다른 프로젝트의 리포지토리에 액세스할 수 있는 경우 다음 명령을 사용합니다.

git clone -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" <clone URL>

스크립트에서 사용 System.AccessToken 하려면 먼저 스크립트에서 사용할 수 있도록 해야 합니다. 이렇게 하려면 편집기에서 작업 탭 아래에서 작업을 선택하고, 오른쪽 패널에서 추가 옵션을 선택한 다음, 스크립트가 OAuth 토큰에 액세스하도록 허용하는 옵션을 선택합니다.
액세스 토큰(아래 설명)에 리포지토리에 대한 액세스 권한이 없는 경우:
1. 범위가 있는 PAT(개인용 액세스 토큰)Code (read)를 가져와서 접두사로PAT:
2. 이 문자열을 Base64로 인코딩하여 기본 인증 토큰을 만듭니다.
3. 다음 명령을 사용하여 파이프라인에 스크립트를 추가하여 해당 리포지토리를 복제합니다. git clone -c http.extraheader="AUTHORIZATION: basic <BASIC_AUTH_TOKEN>" <clone URL>

Azure Pipelines는 빌드하는 동안 빌드를 트리거하고 코드를 가져오려면 리포지토리에 대한 액세스 권한을 받아야 합니다. 일반적으로 파이프라인은 동일한 프로젝트의 리포지토리에 액세스할 수 있습니다. 그러나 다른 프로젝트의 리포지토리에 액세스하려면 작업 액세스 토큰에 부여된 권한을 업데이트해야 합니다.

CI 트리거

CI(연속 통합) 트리거는 지정된 분기에 업데이트를 푸시하거나 지정된 태그를 푸시할 때마다 파이프라인을 실행합니다.

YAML
클래식

YAML 파이프라인은 Azure DevOps 스프린트 227에 도입된 암시적 YAML CI 트리거 설정 사용 안 함을 사용하지 않는 한 모든 분기에서 CI 트리거를 사용하여 기본적으로 구성됩니다. 암시적 YAML CI 트리거 사용 안 함 설정은 조직 수준 또는 프로젝트 수준에서 구성할 수 있습니다. 암시적 YAML CI 트리거 설정 사용 안 함을 사용하면 YAML 파이프라인에 섹션이 없는 trigger 경우 YAML 파이프라인에 대한 CI 트리거가 활성화되지 않습니다. 기본적으로 암시적 YAML CI 트리거 를 사용하지 않도록 설정하지 않습니다.

분기

간단한 구문을 사용하여 CI 트리거를 가져오는 분기를 제어할 수 있습니다.

trigger:
- main
- releases/*

분기의 전체 이름(예 main: ) 또는 와일드카드(예: releases/*)를 지정할 수 있습니다. 와일드카드 구문에 대한 자세한 내용은 와일드카드를 참조하세요.

참고 항목

트리거가 발생한 후 런타임에 변수가 평가되므로 트리거에는 변수를 사용할 수 없습니다.

참고 항목

템플릿을 사용하여 YAML 파일을 작성하는 경우 파이프라인에 대한 기본 YAML 파일에서만 트리거를 지정할 수 있습니다. 템플릿 파일에서 트리거를 지정할 수 없습니다.

사용하거나 batch사용하는 더 복잡한 트리거 exclude 의 경우 다음 예제와 같이 전체 구문을 사용해야 합니다.

# specific branch build
trigger:
  branches:
    include:
    - main
    - releases/*
    exclude:
    - releases/old*

위의 예제에서 변경 내용이 릴리스 분기로 푸시되거나 릴리스 분기로 main 푸시되면 파이프라인이 트리거됩니다. 그러나 .로 시작하는 old릴리스 분기가 변경되면 트리거되지 않습니다.

절 없이 절을 exclude include 지정하는 경우 절에서 include 지정하는 * 것과 같습니다.

목록에서 분기 이름을 branches 지정하는 것 외에도 다음 형식을 사용하여 태그를 기반으로 트리거를 구성할 수도 있습니다.

trigger:
  branches:
    include:
      - refs/tags/{tagname}
    exclude:
      - refs/tags/{othertagname}

트리거를 지정하지 않았고 암시적 YAML CI 트리거 사용 안 함 설정을 사용하도록 설정하지 않은 경우 기본값은 다음과 같습니다.

trigger:
  branches:
    include:
    - '*'  # must quote since "*" is a YAML reserved character; we want a string

Important

트리거를 지정하면 기본 암시적 트리거가 대체되고 포함되도록 명시적으로 구성된 분기에만 푸시하면 파이프라인이 트리거됩니다. 포함은 먼저 처리된 다음 제외는 해당 목록에서 제거됩니다.

CI 실행 일괄 처리

변경 내용을 자주 업로드하는 팀 구성원이 많은 경우 시작하는 실행 수를 줄일 수 있습니다. 파이프라인이 실행 중일 때 실행이 완료될 때까지 대기한 다음 아직 빌드되지 않은 모든 변경 내용으로 다른 실행을 시작하도록 true설정하는 batch 경우

# specific branch build with batching
trigger:
  batch: true
  branches:
    include:
    - main

참고 항목

batch 는 리포지토리 리소스 트리거에서 지원되지 않습니다.

이 예제를 명확히 하기 위해 위의 파이프라인을 실행하도록 main 푸시 A 했다고 가정해 보겠습니다. 해당 파이프라인이 실행되는 동안 추가 푸시가 B C 리포지토리에 발생합니다. 이러한 업데이트는 새 독립 실행을 즉시 시작하지 않습니다. 그러나 첫 번째 실행이 완료되면 해당 시점이 함께 일괄 처리되고 새 실행이 시작될 때까지 모든 푸시가 수행됩니다.

참고 항목

파이프라인에 여러 작업 및 단계가 있는 경우 첫 번째 실행은 두 번째 실행을 시작하기 전에 모든 작업 및 단계를 완료하거나 건너뛰어 터미널 상태에 도달해야 합니다. 이러한 이유로 여러 단계 또는 승인이 있는 파이프라인에서 이 기능을 사용할 때는 주의해야 합니다. 이러한 경우 빌드를 일괄 처리하려는 경우 CI/CD 프로세스를 빌드용(일괄 처리 포함) 및 배포용 파이프라인의 두 파이프라인으로 분할하는 것이 좋습니다.

경로

포함하거나 제외할 파일 경로를 지정할 수 있습니다.

# specific path build
trigger:
  branches:
    include:
    - main
    - releases/*
  paths:
    include:
    - docs
    exclude:
    - docs/README.md

경로를 지정할 때 Azure DevOps Server 2019.1 이하를 사용하는 경우 트리거할 분기를 명시적으로 지정해야 합니다. 경로 필터만 사용하여 파이프라인을 트리거할 수 없습니다. 또한 분기 필터가 있어야 하며 경로 필터와 일치하는 변경된 파일은 분기 필터와 일치하는 분기에서 온 것이어야 합니다. Azure DevOps Server 2020 이상에서 사용하는 경우 경로 필터와 함께 모든 분기에서 필터링을 생략 branches 할 수 있습니다.

와일드 카드는 경로 필터에 대해 지원됩니다. 예를 들어 일치하는 src/app/**/myapp*모든 경로를 포함할 수 있습니다. 와일드카드 문자(***또는 ?) 경로 필터를 지정할 때)를 사용할 수 있습니다.

경로는 항상 리포지토리의 루트를 기준으로 지정됩니다.
경로 필터를 설정하지 않으면 리포지토리의 루트 폴더가 기본적으로 암시적으로 포함됩니다.
경로를 제외하는 경우 더 깊은 폴더로 한정하지 않으면 경로를 포함할 수 없습니다. 예를 들어 /tools를 제외하면 /tools/trigger-runs-on-these를 포함할 수 있습니다.
경로 필터의 순서는 중요하지 않습니다.
Git 의 경로는 대/소문자를 구분합니다. 실제 폴더와 동일한 사례를 사용해야 합니다.
트리거가 발생한 후 런타임에 변수가 평가되므로 경로에 변수를 사용할 수 없습니다.

분기 필터와 함께 태그를 지정하면 분기 필터가 충족되거나 태그 필터가 충족되면 트리거가 발생합니다. 예를 들어 푸시된 태그가 분기 필터를 만족하는 경우 푸시가 분기 필터를 만족하므로 태그가 태그 필터에서 제외되더라도 파이프라인이 트리거됩니다.

CI 옵트아웃

CI 트리거를 사용하지 않도록 설정

를 지정하여 CI 트리거를 완전히 옵트아웃할 수 있습니다 trigger: none.

# A pipeline with no CI trigger
trigger: none

Important

분기로 변경 사항을 푸시하면 해당 분기의 YAML 파일이 평가되어 CI 실행을 시작해야 하는지 확인합니다.

누군가가 코드를 체크 인할 때마다 빌드를 실행하려면 트리거 탭에서 연속 통합 사용을 선택하여 이 트리거를 사용하도록 설정합니다.

일괄 처리 변경 내용

변경 내용을 자주 업로드하는 팀 구성원이 많고 실행 중인 빌드 수를 줄이려면 이 확인란을 선택합니다. 이 옵션을 선택하면 빌드가 실행될 때 시스템이 실행이 완료될 때까지 기다린 다음 아직 빌드되지 않은 모든 변경 내용의 또 다른 실행을 큐에 대기합니다.

변경 내용을 일괄 처리하고 함께 빌드할 수 있습니다.

참고 항목

다단계 YAML 파이프라인에서 일괄 처리를 사용하는 경우 다음 단계를 시작하기 전에 실행이 터미널 상태에 도달해야 합니다. 다단계 파이프라인이 승인 및 장기 실행 배포 단계를 통과할 수 있으므로 이는 바람직하지 않은 경우가 많습니다. 이러한 경우 다음 솔루션 중 하나를 따르는 것이 좋습니다.

일괄 처리를 사용하지 마세요.
파이프라인을 두 개의 개별 파이프라인(CI용 및 CD용)으로 분할
스테이지에서 적절한 조건을 설정하여 건너뛰고 실행이 신속하게 종료되도록 합니다.

분기 필터

빌드를 트리거할 분기를 지정할 수 있습니다. 와일드카드 문자를 사용하려면 분기 사양(예 features/modules/*: )을 입력한 다음 Enter 키를 누릅니다.

패스 필터

Git 리포지토리가 Azure Repos 또는 TFS에 있는 경우 경로 필터를 지정하여 빌드를 트리거하려는 파일 집합을 줄일 수도 있습니다.

팁:

경로는 항상 리포지토리의 루트를 기준으로 지정됩니다.

경로 필터를 설정하지 않으면 리포지토리의 루트 폴더가 기본적으로 암시적으로 포함됩니다.

경로를 제외하는 경우 더 깊은 폴더로 한정하지 않으면 경로를 포함할 수 없습니다. 예를 들어 /tools를 제외하면 /tools/trigger-runs-on-these를 포함할 수 있습니다.

경로 필터의 순서는 중요하지 않습니다.

Git의 경로는 대/소문자를 구분합니다. 실제 폴더와 동일한 사례를 사용해야 합니다.

예시

예를 들어 기능 분기 변경 main 내용에 의해 빌드가 트리거되도록 할 수 있습니다. 또한 도구 폴더의 파일 변경으로 인해 빌드가 트리거되지 않도록 합니다.

연속 통합 트리거 분기 필터를 구성합니다.

개별 푸시에 대한 CI 건너뛰기

푸시가 일반적으로 트리거되는 파이프라인 실행을 건너뛰도록 Azure Pipelines에 지시할 수도 있습니다. 푸시의 일부인 커밋의 메시지에 포함 ***NO_CI*** 하기만 하면 Azure Pipelines는 이 푸시에 대한 CI 실행을 건너뜁니다.

푸시가 일반적으로 트리거되는 파이프라인 실행을 건너뛰도록 Azure Pipelines에 지시할 수도 있습니다. 푸시의 일부인 커밋에 대한 메시지 또는 설명에 포함 [skip ci] 하기만 하면 Azure Pipelines는 이 푸시에 대한 CI 실행을 건너뜁니다. 다음과 같은 변형을 사용할 수도 있습니다.

[skip ci] 또는 [ci skip]
skip-checks: true 또는 skip-checks:true
[skip azurepipelines] 또는 [azurepipelines skip]
[skip azpipelines] 또는 [azpipelines skip]
[skip azp] 또는 [azp skip]
***NO_CI***

조건에서 트리거 유형 사용

실행을 시작한 트리거 유형에 따라 파이프라인에서 다른 단계, 작업 또는 단계를 실행하는 것이 일반적인 시나리오입니다. 시스템 변수 Build.Reason를 사용하여 이 작업을 수행할 수 있습니다. 예를 들어 다음 조건을 단계, 작업 또는 단계에 추가하여 PR 유효성 검사에서 제외합니다.

condition: and(succeeded(), ne(variables['Build.Reason'], 'PullRequest'))

새 분기를 만들 때 트리거의 동작

동일한 리포지토리에 대해 여러 파이프라인을 구성하는 것이 일반적입니다. 예를 들어 앱에 대한 문서를 빌드하는 파이프라인 하나와 소스 코드를 빌드하는 파이프라인이 있을 수 있습니다. 이러한 각 파이프라인에서 적절한 분기 필터 및 경로 필터를 사용하여 CI 트리거를 구성할 수 있습니다. 예를 들어 폴더에 업데이트를 푸시할 때 하나의 파이프라인이 트리거되고, 애플리케이션 코드에 docs 업데이트를 푸시할 때 다른 파이프라인이 트리거되도록 할 수 있습니다. 이러한 경우 새 분기를 만들 때 파이프라인이 트리거되는 방식을 이해해야 합니다.

다음은 새 분기(분기 필터와 일치)를 리포지토리에 푸시할 때의 동작입니다.

파이프라인에 경로 필터가 있는 경우 새 분기에 해당 경로 필터와 일치하는 파일이 변경된 경우에만 트리거됩니다.
파이프라인에 경로 필터가 없는 경우 새 분기에 변경 내용이 없더라도 트리거됩니다.

와일드카드

분기, 태그 또는 경로를 지정할 때 정확한 이름 또는 와일드카드를 사용할 수 있습니다. 와일드카드 패턴은 0개 이상의 문자를 일치시키고 ? 단일 문자를 일치시킬 수 있습니다*.

YAML 파이프라인에서 패턴을 * 시작하는 경우 다음과 같이 "*-releases"패턴을 따옴표로 래핑해야 합니다.
분기 및 태그의 경우:
- 와일드카드는 패턴의 아무 곳에나 나타날 수 있습니다.
경로의 경우:
- Azure DevOps Services를 포함하여 Azure DevOps Server 2022 이상에서는 경로 패턴 내의 아무 곳에나 와일드카드가 표시되어 사용하거나 ?사용할 * 수 있습니다.
- Azure DevOps Server 2020 이하에서는 최종 문자로 포함 * 할 수 있지만 디렉터리 이름 자체를 지정하는 것과 다르게 수행되지는 않습니다. 경로 필터의 중간에 포함되지 * 않을 수 있으며 사용하지 ?않을 수 있습니다.

trigger:
  branches:
    include:
    - main
    - releases/*
    - feature/*
    exclude:
    - releases/old*
    - feature/*-working
  paths:
    include:
    - docs/*.md

PR 트리거

끌어오기 요청(PR) 트리거는 끌어오기 요청을 열 때마다 또는 변경 내용을 푸시할 때 파이프라인이 실행되도록 합니다. Azure Repos Git에서 이 기능은 분기 정책을 사용하여 구현됩니다. PR 유효성 검사를 사용하도록 설정하려면 원하는 분기에 대한 분기 정책으로 이동하고 해당 분기에 대한 빌드 유효성 검사 정책을 구성합니다. 자세한 내용은 분기 정책 구성을 참조 하세요.

열려 있는 PR이 있고 원본 분기에 변경 내용을 푸시하는 경우 여러 파이프라인이 실행되었을 수 있습니다.

대상 분기의 빌드 유효성 검사 정책에 의해 지정된 파이프라인은 메시지 또는 설명이 포함된 [skip ci] 푸시된 커밋(또는 해당 변형)이 있는지 여부에 관계없이 병합 커밋(끌어오기 요청의 원본 분기와 대상 분기 간의 병합된 코드)에서 실행됩니다.
메시지 또는 설명에 포함 [skip ci] 되는 푸시된 커밋이 없는 경우(또는 해당 변형) PR의 원본 분기 변경에 의해 트리거되는 파이프라인입니다. 푸시된 커밋이 하나 이상 포함되어 [skip ci]있으면 파이프라인이 실행되지 않습니다.

마지막으로 PR을 병합한 후 Azure Pipelines는 병합된 커밋의 메시지 또는 설명 중 일부(또는 해당 변형)가 포함된 [skip ci] 경우에도 대상 분기에 푸시하여 트리거되는 CI 파이프라인을 실행합니다.

참고 항목

Azure Repos Git 리포지토리에 대한 유효성 검사 빌드를 구성하려면 프로젝트의 프로젝트 관리자여야 합니다.

참고 항목

분기 정책을 구성하더라도 끌어오기 요청 초안은 파이프라인을 트리거하지 않습니다.

포크에서 기여 유효성 검사

Azure Repos 포크에서 끌어오기 요청을 빌드하는 것은 동일한 리포지토리 또는 프로젝트 내에서 끌어오기 요청을 빌드하는 것과 다르지 않습니다. 프로젝트가 속한 동일한 조직 내에서만 포크를 만들 수 있습니다.

작업 권한 부여 범위 제한

Azure Pipelines는 파이프라인이 실행되는 작업 권한 부여 범위를 구성하는 몇 가지 보안 설정을 제공합니다.

작업 권한 부여 범위를 현재 프로젝트로 제한
YAML 파이프라인에서 리포지토리에 대한 액세스 보호

작업 권한 부여 범위를 현재 프로젝트로 제한

Azure Pipelines는 현재 프로젝트 설정에 대한 두 가지 제한 작업 권한 부여 범위를 제공합니다.

작업 권한 부여 범위를 릴리스가 아닌 파이프라인 의 현재 프로젝트로 제한 - 이 설정은 YAML 파이프라인 및 클래식 빌드 파이프라인에 적용됩니다. 이 설정은 클래식 릴리스 파이프라인에는 적용되지 않습니다.
작업 권한 부여 범위를 릴리스 파이프라인 의 현재 프로젝트로 제한 - 이 설정은 클래식 릴리스 파이프라인에 만 적용됩니다 .

파이프라인 유형에 대한 관련 설정을 사용하도록 설정하지 않는 한 파이프라인은 컬렉션 범위 액세스 토큰으로 실행됩니다. 작업 권한 부여 범위 제한 설정을 사용하면 현재 프로젝트에 대한 모든 파이프라인에 대한 액세스 범위를 줄일 수 있습니다. 조직의 다른 프로젝트에서 Azure Repos Git 리포지토리에 액세스하는 경우 파이프라인에 영향을 미칠 수 있습니다.

Azure Repos Git 리포지토리가 파이프라인과 다른 프로젝트에 있고 파이프라인 유형에 대한 작업 권한 부여 범위 제한 설정을 사용하도록 설정한 경우 파이프라인에 대한 빌드 서비스 ID에 대한 권한을 두 번째 프로젝트에 부여해야 합니다. 자세한 내용은 빌드 서비스 계정 권한 관리를 참조 하세요.

Azure Pipelines는 파이프라인이 실행되는 작업 권한 부여 범위를 구성하는 보안 설정을 제공합니다.

작업 권한 부여 범위를 현재 프로젝트 로 제한 - 이 설정은 YAML 파이프라인 및 클래식 빌드 파이프라인에 적용됩니다. 이 설정은 클래식 릴리스 파이프라인에는 적용되지 않습니다.

파이프라인은 현재 프로젝트에 대한 작업 권한 부여 범위를 제한하지 않는 한 컬렉션 범위 액세스 토큰으로 실행됩니다. 이 설정을 사용하면 현재 프로젝트에 대한 모든 파이프라인에 대한 액세스 범위를 줄일 수 있습니다. 조직의 다른 프로젝트에서 Azure Repos Git 리포지토리에 액세스하는 경우 파이프라인에 영향을 미칠 수 있습니다.

Azure Repos Git 리포지토리가 파이프라인과 다른 프로젝트에 있고 작업 권한 부여 범위 제한 설정을 사용하는 경우 파이프라인에 대한 빌드 서비스 ID에 대한 권한을 두 번째 프로젝트에 부여해야 합니다. 자세한 내용은 작업 권한 부여 범위를 참조하세요.

작업 권한 부여 범위 제한에 대한 자세한 내용은 작업 액세스 토큰 이해를 참조하세요.

참조된 Azure DevOps 리포지토리로 작업 권한 부여 범위 제한

파이프라인은 참조된 Azure DevOps 리포지토리로 작업 권한 부여 범위를 제한하지 않는 한 이전 작업 권한 부여 범위에서 현재 프로젝트로 제한 섹션에 설명된 대로 권한 있는 프로젝트의 모든 Azure DevOps 리포지토리에 액세스할 수 있습니다. 이 옵션을 사용하도록 설정하면 모든 파이프라인에 대한 액세스 범위를 해당 리포지토리를 사용하는 파이프라인 작업의 단계 또는 uses 문에서 명시적으로 참조한 checkout Azure DevOps 리포지토리로만 줄일 수 있습니다.

이 설정을 구성하려면 조직 설정 또는 프로젝트 설정에서 파이프라인, 설정으로 이동합니다. 조직 수준에서 사용하도록 설정하면 설정이 회색으로 표시되고 프로젝트 설정 수준에서 사용할 수 없습니다.

참조된 Azure DevOps 리포지토리로 작업 권한 부여 범위를 제한할 경우 YAML 파이프라인은 파이프라인에서 사용하려는 Azure Repos Git 리포지토리를 리포지토리를 사용하는 작업의 체크 아웃 단계로 명시적으로 참조해야 합니다. 리포지토리가 먼저 명시적으로 참조되지 않는 한 Azure Repos Git 리포지토리에 대한 스크립팅 작업 및 git 명령을 사용하여 코드를 가져올 수 없습니다.

참조된 Azure DevOps 리포지토리로 작업 권한 부여 범위를 제한할 때 파이프라인에서 사용하기 전에 Azure Repos Git 리포지 토리를 명시적으로 참조할 필요가 없는 몇 가지 예외가 있습니다.

파이프라인에 명시적 체크 아웃 단계가 없는 경우 마치 단계가 checkout: self 있고 리포지토리가 self 체크 아웃된 것처럼 표시됩니다.
스크립트를 사용하여 퍼블릭 프로젝트의 리포지토리에서 읽기 전용 작업을 수행하는 경우 한 단계에서 퍼블릭 프로젝트 리포지 checkout 토리를 참조할 필요가 없습니다.
PAT와 같이 리포지토리에 자체 인증을 제공하는 스크립트를 사용하는 경우 한 단계에서 해당 리포지 checkout 토리를 참조할 필요가 없습니다.

예를 들어 작업 권한 부여 범위를 참조된 Azure DevOps 리포지토리로 제한할 수 있는 경우 파이프라인이 조직의 리포지토리에 FabrikamProject/Fabrikam 있고 스크립트를 사용하여 리포지토리를 체크 아웃 FabrikamProject/FabrikamTools 하려는 경우 한 단계 또는 uses 문을 사용하여 이 리포지 checkout 토리를 참조해야 합니다.

체크 아웃 단계를 사용하여 파이프라인의 리포지토리를 이미 체크 아웃 FabrikamTools 한 경우 나중에 스크립트를 사용하여 해당 리포지토리와 상호 작용할 수 있습니다.

steps:
- checkout: git://FabrikamFiber/FabrikamTools # Azure Repos Git repository in the same organization
- script: # Do something with that repo

# Or you can reference it with a uses statement in the job
uses:
  repositories: # List of referenced repositories
  - FabrikamTools # Repository reference to FabrikamTools

steps:
- script: # Do something with that repo like clone it

참고 항목

많은 시나리오에서 다중 리포지토리 체크 아웃을 활용하여 스크립트를 사용하여 파이프라인의 추가 리포지토리를 체크 아웃할 필요가 없습니다. 자세한 내용은 파이프라인에서 여러 리포지토리를 확인하세요.

YAML 파이프라인에서 리포지토리에 대한 액세스 보호

YAML 파이프라인의 리포지토리에 대한 액세스를 보호하지 않는 한 파이프라인은 이전 작업 권한 부여 범위에서 현재 프로젝트 섹션으로 작업 권한 부여 제한 섹션에 설명된 대로 권한 있는 프로젝트의 모든 Azure DevOps 리포지토리에 액세스할 수 있습니다. 이 옵션을 사용하도록 설정하면 모든 파이프라인에 대한 액세스 범위를 해당 리포지토리를 사용하는 파이프라인 작업의 단계 또는 uses 문에서 명시적으로 참조한 checkout Azure DevOps 리포지토리로만 줄일 수 있습니다.

Important

YAML 파이프라인 의 리포지토리에 대한 액세스 보호는 기본적으로 2020년 5월 이후에 만들어진 새 조직 및 프로젝트에 대해 사용하도록 설정됩니다. YAML 파이프라인의 리포지토리에 대한 액세스 보호가 사용하도록 설정된 경우 YAML 파이프라인은 리포지토리를 사용하는 작업의 체크 아웃 단계로 파이프라인에서 사용하려는 Azure Repos Git 리포지토리를 명시적으로 참조해야 합니다. 리포지토리가 먼저 명시적으로 참조되지 않는 한 Azure Repos Git 리포지토리에 대한 스크립팅 작업 및 git 명령을 사용하여 코드를 가져올 수 없습니다.

YAML 파이프라인의 리포지토리에 대한 액세스 보호가 사용하도록 설정된 경우 파이프라인에서 사용하기 전에 Azure Repos Git 리포지토리를 명시적으로 참조할 필요가 없는 몇 가지 예외가 있습니다 .

파이프라인에 명시적 체크 아웃 단계가 없는 경우 마치 단계가 checkout: self 있고 리포지토리가 self 체크 아웃된 것처럼 표시됩니다.
스크립트를 사용하여 퍼블릭 프로젝트의 리포지토리에서 읽기 전용 작업을 수행하는 경우 한 단계에서 퍼블릭 프로젝트 리포지 checkout 토리를 참조할 필요가 없습니다.
PAT와 같이 리포지토리에 자체 인증을 제공하는 스크립트를 사용하는 경우 한 단계에서 해당 리포지 checkout 토리를 참조할 필요가 없습니다.

예를 들어 YAML 파이프라인 의 리포지토리에 대한 액세스 보호가 사용하도록 설정된 경우 파이프라인이 조직의 리포지토리에 FabrikamProject/Fabrikam 있고 스크립트를 사용하여 리포지토리를 확인 FabrikamProject/FabrikamTools 하려는 경우 이 리포지 checkout 토리를 한 단계 또는 문으로 uses 참조해야 합니다.

steps:
- checkout: git://FabrikamFiber/FabrikamTools # Azure Repos Git repository in the same organization
- script: # Do something with that repo
# Or you can reference it with a uses statement in the job
uses:
  repositories: # List of referenced repositories
  - FabrikamTools # Repository reference to FabrikamTools
steps:
- script: # Do something with that repo like clone it

참고 항목

체크 아웃

파이프라인이 트리거되면 Azure Pipelines는 Azure Repos Git 리포지토리에서 소스 코드를 가져옵니다. 이러한 동작의 다양한 측면을 제어할 수 있습니다.

참고 항목

파이프라인에 체크 아웃 단계를 포함하면 다음 명령을 git -c fetch --force --tags --prune --prune-tags --progress --no-recurse-submodules origin --depth=1실행합니다. 요구 사항을 충족하지 않는 경우 기본 제공 체크 아웃 checkout: none 을 제외한 다음 스크립트 작업을 사용하여 사용자 고유의 체크 아웃을 수행할 수 있습니다.

기본 버전의 Git

Windows 에이전트에는 자체 Git 복사본이 함께 제공됩니다. 포함된 복사본을 사용하는 대신 사용자 고유의 Git을 제공하려면 .로 설정합니다 System.PreferGitFromPath true. 이 설정은 Windows가 아닌 에이전트에서 항상 true입니다.

단일 리포지토리를 체크 아웃하는 경우 기본적으로 소스 코드가 호출 s된 디렉터리로 체크 아웃됩니다. YAML 파이프라인의 checkout path경우 . 지정한 경로가 .을 기준으로 합니다 $(Agent.BuildDirectory). 예를 들어 체크 아웃 경로 값이 mycustompath 있는 $(Agent.BuildDirectory) C:\agent\_work\1경우 소스 코드가 체크 아웃 C:\agent\_work\1\mycustompath됩니다.

여러 단계를 사용하고 여러 checkout 리포지토리를 체크 아웃하고 폴더 path를 명시적으로 지정하지 않는 경우 각 리포지토리는 리포지토리의 s 이름을 따서 명명된 하위 폴더에 배치됩니다. 예를 들어 이름이 지정된 tools 두 개의 리포지토리를 체크 아웃하면 code소스 코드가 체크 아웃 C:\agent\_work\1\s\tools 되고 C:\agent\_work\1\s\code.

체크 아웃 경로 값은 위의 $(Agent.BuildDirectory)디렉터리 수준을 올라가도록 설정할 수 없으므로 path\..\anotherpath 유효한 체크 아웃 경로(예 C:\agent\_work\1\anotherpath: )가 발생하지만 같은 ..\invalidpath 값은 그렇지 않습니다(예 C:\agent\_work\invalidpath: ).

파이프라인의 path 체크 아웃 단계에서 설정을 구성할 수 있습니다.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

하위 모듈

YAML
클래식

하위 모듈에서 파일을 다운로드하려는 경우 파이프라인의 체크 아웃 단계에서 설정을 구성할 submodules 수 있습니다.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

빌드 파이프라인은 다음과 같은 경우 Git 하위 모듈을 확인합니다.

인증되지 않음: 복제 또는 페치할 자격 증명이 없는 인증되지 않은 공용 리포지토리입니다.
인증:
- 위에 지정된 Azure Repos Git 리포지토리와 동일한 프로젝트에 포함되어 있습니다. 에이전트가 주 리포지토리에서 원본을 가져오는 데 사용하는 것과 동일한 자격 증명을 사용하여 하위 모듈의 원본을 가져옵니다.
- 주 리포지토리에 상대적인 URL을 사용하여 추가됩니다. 예를 들어
  - 이 작업은 체크 아웃됩니다. git submodule add ../../../FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber
    
    이 예제에서 하위 모듈은 동일한 Azure DevOps 조직에서 리포지토리(FabrikamFiber)를 참조하지만 다른 프로젝트(FabrikamFiberProject)를 참조합니다. 에이전트가 주 리포지토리에서 원본을 가져오는 데 사용하는 것과 동일한 자격 증명을 사용하여 하위 모듈의 원본을 가져옵니다. 이렇게 하려면 작업 액세스 토큰이 두 번째 프로젝트의 리포지토리에 액세스할 수 있어야 합니다. 위의 섹션에서 설명한 대로 작업 액세스 토큰을 제한한 경우 이 작업을 수행할 수 없습니다. (a) 두 번째 프로젝트에서 프로젝트 빌드 서비스 계정에 대한 액세스 권한을 명시적으로 부여하거나 (b) 전체 조직에 대한 프로젝트 범위 토큰 대신 컬렉션 범위 액세스 토큰을 사용하여 작업 액세스 토큰이 두 번째 프로젝트의 리포지토리에 액세스하도록 허용할 수 있습니다. 이러한 옵션 및 해당 보안 영향에 대한 자세한 내용은 Access 리포지토리, 아티팩트 및 기타 리소스를 참조 하세요.
  - 체크 아웃되지 않습니다. git submodule add https://fabrikam-fiber@dev.azure.com/fabrikam-fiber/FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

체크 아웃 하위 모듈 옵션을 사용하는 대신

경우에 따라 체크 아웃 하위 모듈 옵션을 사용할 수 없습니다. 하위 모듈에 액세스하기 위해 다른 자격 증명 집합이 필요한 시나리오가 있을 수 있습니다. 예를 들어 주 리포지토리 및 하위 모드 리포지토리가 동일한 Azure DevOps 조직에 저장되지 않거나 작업 액세스 토큰이 다른 프로젝트의 리포지토리에 액세스할 수 없는 경우 이러한 문제가 발생할 수 있습니다.

체크 아웃 하위 모듈 옵션을 사용할 수 없는 경우 대신 사용자 지정 스크립트 단계를 사용하여 하위 모듈을 가져올 수 있습니다. 먼저 PAT(개인용 액세스 토큰)를 가져와 접두사로 pat:하세요. 다음으로 이 접두사 문자열을 base64로 인코딩 하여 기본 인증 토큰을 만듭니다. 마지막으로 파이프라인에 다음 스크립트를 추가합니다.

git -c http.https://<url of submodule repository>.extraheader="AUTHORIZATION: Basic <BASE64_ENCODED_STRING>" submodule update --init --recursive

"<BASE64_ENCODED_STRING>"을 Base64로 인코딩된 "pat:token" 문자열로 바꿔야 합니다.

프로젝트 또는 빌드 파이프라인에서 비밀 변수를 사용하여 생성한 기본 인증 토큰을 저장합니다. 이 변수를 사용하여 위의 Git 명령에서 비밀을 채웁니다.

참고 항목

Q: 에이전트에서 Git 자격 증명 관리자를 사용할 수 없는 이유는 무엇인가요? A: 프라이빗 빌드 에이전트에 설치된 Git 자격 증명 관리자에 하위 모드 자격 증명을 저장하는 것은 일반적으로 유효하지 않습니다. 자격 증명 관리자가 하위 모드를 업데이트할 때마다 자격 증명을 다시 입력하라는 메시지가 표시될 수 있기 때문에 일반적으로 유효하지 않습니다. 사용자 상호 작용이 불가능한 경우 자동화된 빌드 중에는 바람직하지 않습니다.

태그 동기화

Important

동기화 태그 기능은 Azure DevOps Server 2022.1 이상을 사용하는 Azure Repos Git에서 지원됩니다.

체크 아웃 단계에서는 Git 리포지토리의 콘텐츠를 가져올 때 이 옵션을 사용합니다 --tags . 이렇게 하면 서버는 모든 태그와 해당 태그가 가리키는 모든 개체를 가져옵니다. 이렇게 하면 특히 많은 태그가 있는 큰 리포지토리가 있는 경우 파이프라인에서 작업을 실행하는 시간이 늘어나게 됩니다. 또한 체크 아웃 단계는 단순 인출 옵션을 사용하도록 설정한 경우에도 태그를 동기화하므로 용도가 무용지물이 될 수 있습니다. Git 리포지토리에서 가져오거나 가져온 데이터의 양을 줄이기 위해 Microsoft는 태그 동기화 동작을 제어하는 새로운 체크 아웃 옵션을 추가했습니다. 이 옵션은 클래식 및 YAML 파이프라인 모두에서 사용할 수 있습니다.

리포지토리를 체크 아웃할 때 태그를 동기화할지 여부는 YAML에서 속성을 설정하고 동기화 태그 설정을 fetchTags 구성 하여 UI에서 구성할 수 있습니다 .

YAML
클래식

파이프라인의 fetchTags 체크 아웃 단계에서 설정을 구성할 수 있습니다.

YAML에서 설정을 구성하려면 속성을 설정합니다 fetchTags .

steps:
- checkout: self
  fetchTags: true

파이프라인 설정 UI에서 태그 동기화 옵션을 사용하여 이 설정을 구성할 수도 있습니다.

YAML 파이프라인을 편집하고 추가 작업, 트리거를 선택합니다.
YAML을 선택하고 원본을 가져옵니다.
동기화 태그 설정을 구성합니다.

참고 항목

단계에서 명시적으로 설정하는 fetchTags checkout 경우 해당 설정은 파이프라인 설정 UI에 구성된 설정보다 우선합니다.

기본 동작

2022년 9월에 릴리스된 Azure DevOps 스프린트 209 릴리스 전에 만든 기존 파이프라인의 경우 태그 동기화에 대한 기본값은 동기화 태그 옵션이 추가되기 전의 기존 동작과 동일하게 유지됩니다true.
Azure DevOps 스프린트 릴리스 209 이후 생성된 새 파이프라인의 경우 태그 동기화의 기본값은 다음과 같습니다 false.

참고 항목

단계에서 명시적으로 설정하는 fetchTags checkout 경우 해당 설정은 파이프라인 설정 UI에 구성된 설정보다 우선합니다.

단순 인출

기록에서 다운로드할 정도를 제한할 수 있습니다. 실제로 이렇게 하면 .가 발생합니다 git fetch --depth=n. 리포지토리가 큰 경우 이 옵션을 사용하면 빌드 파이프라인의 효율성을 높일 수 있습니다. 리포지토리가 오랫동안 사용되어 왔으며 상당한 기록이 있는 경우 리포지토리가 클 수 있습니다. 대용량 파일을 추가하고 나중에 삭제한 경우에도 클 수 있습니다.

Important

2022년 9월 Azure DevOps 스프린트 209 업데이트 이후에 만든 새 파이프라인은 기본적으로 단순 인출을 사용하도록 설정하고 깊이가 1로 구성됩니다. 이전에는 기본값이 단순 인출이 아니었습니다. 파이프라인을 확인하려면 다음 섹션에 설명된 대로 파이프라인 설정 UI에서 단순 인출 설정을 확인합니다.

YAML
클래식

파이프라인의 fetchDepth 체크 아웃 단계에서 설정을 구성할 수 있습니다.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

파이프라인 설정 UI에서 단순 깊이 옵션을 설정 하여 인출 깊이 를 구성할 수도 있습니다.

YAML 파이프라인을 편집하고 추가 작업, 트리거를 선택합니다.
YAML을 선택하고 원본을 가져옵니다.
단순 인출 설정을 구성합니다. 단순 인출을 선택 취소하여 얕은 인출을 사용하지 않도록 설정하거나 확인란을 선택하고 깊이를 입력하여 얕은 인출을 사용하도록 설정합니다.

참고 항목

단계에서 명시적으로 설정하는 fetchDepth checkout 경우 해당 설정은 파이프라인 설정 UI에 구성된 설정보다 우선합니다. 설정은 fetchDepth: 0 모든 기록을 가져오고 단순 인출 설정을 재정의합니다.

이러한 경우 이 옵션은 네트워크 및 스토리지 리소스를 절약하는 데 도움이 될 수 있습니다. 시간이 절약될 수도 있습니다. 항상 시간을 절약하지 않는 이유는 경우에 따라 서버가 지정한 깊이에 대해 다운로드할 커밋을 계산하는 데 시간을 소비해야 할 수 있기 때문입니다.

참고 항목

파이프라인이 시작되면 빌드할 분기가 커밋 ID 확인됩니다. 그런 다음 에이전트가 분기를 가져오고 원하는 커밋을 확인합니다. 분기가 커밋 ID 확인될 때와 에이전트가 체크 아웃을 수행하는 경우 사이에는 작은 창이 있습니다. 분기가 빠르게 업데이트되고 단순 인출에 대해 매우 작은 값을 설정하는 경우 에이전트가 체크 아웃을 시도할 때 커밋이 존재하지 않을 수 있습니다. 이 경우 얕은 인출 깊이 설정을 늘입니다.

원본 동기화 안 함

새 커밋 가져오기를 건너뛸 수 있습니다. 이 옵션은 다음과 같은 경우에 유용할 수 있습니다.

사용자 고유의 사용자 지정 옵션을 사용하여 Git init, 구성 및 페치
빌드 파이프라인을 사용하여 버전 제어의 코드에 의존하지 않는 자동화(예: 일부 스크립트)를 실행합니다.

YAML
클래식

파이프라인의 체크 아웃 단계에서 설정하여 checkout: none원본 동기화 안 함 설정을 구성할 수 있습니다.

steps:
- checkout: none  # Don't sync sources

참고 항목

이 옵션을 사용하면 에이전트는 리포지토리를 정리하는 Git 명령 실행도 건너뜁니다.

클린 빌드

빌드를 실행하기 전에 자체 호스팅 에이전트의 작업 디렉터리를 정리하는 다양한 형식을 수행할 수 있습니다.

일반적으로 자체 호스팅 에이전트의 성능을 향상시키려면 리포지토리를 정리하지 마세요. 이 경우 최상의 성능을 얻으려면 빌드하는 데 사용하는 작업 또는 도구의 정리 옵션을 사용하지 않도록 설정하여 증분 방식으로 빌드하고 있는지 확인합니다.

리포지토리를 정리해야 하는 경우(예: 이전 빌드의 잔여 파일로 인한 문제를 방지하기 위해) 옵션은 다음과 같습니다.

참고 항목

매번 새 에이전트를 받게 되므로 Microsoft 호스팅 에이전트를 사용하는 경우에는 정리가 효과적이지 않습니다.

YAML
클래식

파이프라인의 clean 체크 아웃 단계에서 설정을 구성할 수 있습니다.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

빌드 파이프라인$(Build.SourcesDirectory)으로 true 설정된 경우 clean . 더 구체적으로 말하자면, 다음 Git 명령은 원본을 가져오기 전에 실행됩니다.

git clean -ffdx
git reset --hard HEAD

더 많은 옵션을 위해 작업 설정을 구성할 workspace 수 있습니다.

jobs:
- job: string  # name of the job, A-Z, a-z, 0-9, and underscore
  ...
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs

이렇게 하면 다음과 같은 정리 옵션이 제공됩니다.

outputs: 이전 체크 아웃 태스크에 설명된 정리 설정과 동일한 작업 및 다음을 삭제하고 다시 만듭니다 $(Build.BinariesDirectory). $(Build.ArtifactStagingDirectory) 이러한 설정에 $(Common.TestResultsDirectory) 관계없이 모든 빌드 전에 항상 삭제되고 다시 만들어집니다.
resources: 삭제하고 다시 만듭니다 $(Build.SourcesDirectory). 그러면 모든 빌드에 대한 새 로컬 Git 리포지토리가 초기화됩니다.
all: 삭제하고 다시 만듭니다 $(Agent.BuildDirectory). 그러면 모든 빌드에 대한 새 로컬 Git 리포지토리가 초기화됩니다.

파이프라인의 원본 가져오기 작업의 속성에서 정리 설정을 선택하고 다음 옵션 중 하나를 선택합니다.

정리 설정을 선택합니다.

원본: 빌드 파이프라인은 모든 변경 내용의 실행 취소를 $(Build.SourcesDirectory)수행합니다. 더 구체적으로 말하자면, 다음 Git 명령은 원본을 가져오기 전에 실행됩니다.
```
git clean -ffdx
git reset --hard HEAD
```
원본 및 출력 디렉터리: 위의 원본 옵션과 동일한 작업, 더하기: 삭제하고 다시 만듭니다$(Build.BinariesDirectory). $(Build.ArtifactStagingDirectory) 이러한 설정에 $(Common.TestResultsDirectory) 관계없이 모든 빌드 전에 항상 삭제되고 다시 만들어집니다.
원본 디렉터리: 삭제하고 다시 만듭니다 $(Build.SourcesDirectory). 그러면 모든 빌드에 대한 새 로컬 Git 리포지토리가 초기화됩니다.
모든 빌드 디렉터리: 삭제하고 다시 만듭니다 $(Agent.BuildDirectory). 그러면 모든 빌드에 대한 새 로컬 Git 리포지토리가 초기화됩니다.

레이블 원본

팀이 완료된 빌드에 포함된 각 파일의 버전을 쉽게 식별할 수 있도록 소스 코드 파일에 레이블을 지정할 수 있습니다. 또한 소스 코드가 모든 빌드에 대해 레이블을 지정해야 하는지 아니면 성공적인 빌드에 대해서만 레이블을 지정해야 하는지를 지정하는 옵션도 있습니다.

YAML
클래식

현재 YAML에서는 이 설정을 구성할 수 없지만 클래식 편집기에서 구성할 수 있습니다. YAML 파이프라인을 편집할 때 YAML 편집기 메뉴에서 트리거 중 하나를 선택하여 클래식 편집기에서 액세스할 수 있습니다.

클래식 편집기에서 YAML을 선택하고 원본 가져오기 작업을 선택한 다음 원하는 속성을 구성합니다.

클래식 편집기에서 YAML > 원본 가져오기를 선택합니다.

태그 형식에서는 범위가 "모두"인 사용자 정의 및 미리 정의된 변수를 사용할 수 있습니다. 예를 들어:

$(Build.DefinitionName)_$(Build.DefinitionVersion)_$(Build.BuildId)_$(Build.BuildNumber)_$(My.Variable)

처음 네 개의 변수가 미리 정의됩니다. My.Variable는 변수 탭에서 정의할 수 있습니다.

빌드 파이프라인은 Git 태그를 사용하여 원본에 레이블을 지정합니다.

일부 빌드 변수는 유효한 레이블이 아닌 값을 생성할 수 있습니다. 예를 들어 공백과 같은 $(Build.RequestedFor) 변수를 $(Build.DefinitionName) 포함할 수 있습니다. 값에 공백이 있으면 태그가 만들어지지 않습니다.

빌드 파이프라인에서 원본에 태그를 지정하면 Git ref refs/tags/{tag} 가 있는 아티팩트가 완료된 빌드에 자동으로 추가됩니다. 이렇게 하면 팀에서 추가 추적 기능을 제공하고 빌드에서 빌드된 코드로 탐색할 수 있는 사용자 친화적인 방법을 제공합니다. 이 태그는 빌드에서 생성되므로 빌드 아티팩트로 간주됩니다. 수동으로 또는 보존 정책을 통해 빌드를 삭제하면 태그도 삭제됩니다.

FAQ

Azure Repos 통합과 관련된 문제는 다음 세 가지 범주로 구분됩니다.

실패 트리거: 리포지토리에 업데이트를 푸시할 때 파이프라인이 트리거되지 않습니다.
체크 아웃 실패: 내 파이프라인이 트리거되고 있지만 체크 아웃 단계에서 실패합니다.
잘못된 버전: 내 파이프라인이 실행되지만 예기치 않은 버전의 원본/YAML을 사용하고 있습니다.

실패한 트리거

CI/PR 트리거를 사용하여 새 YAML 파이프라인을 만들었지만 파이프라인은 트리거되지 않습니다.

다음 각 단계에 따라 실패한 트리거 문제를 해결합니다.

YAML CI 또는 PR 트리거가 UI의 파이프라인 설정에 의해 재정의되고 있나요? 파이프라인을 편집하는 동안 ...를 선택한 다음 트리거합니다.

리포지토리에 사용할 수 있는 트리거 유형(연속 통합 또는 끌어오기 요청 유효성 검사)은 여기 설정에서 YAML 트리거 재정의를 확인합니다.

YAML 파일 또는 리포지토리에 대한 분기 정책에서 PR 트리거를 구성하고 있나요? Azure Repos Git 리포지토리의 경우 YAML 파일에서 PR 트리거를 구성할 수 없습니다. 분기 정책을 사용해야 합니다.

파이프라인이 일시 중지되거나 비활성화되어 있나요? 파이프라인에 대한 편집기를 연 다음 설정을 선택하여 확인합니다. 파이프라인이 일시 중지되거나 비활성화된 경우 트리거가 작동하지 않습니다.
올바른 분기에서 YAML 파일을 업데이트했나요? 분기로 업데이트를 푸시하는 경우 동일한 분기의 YAML 파일이 CI 동작을 제어합니다. 원본 분기에 업데이트를 푸시하는 경우 원본 분기를 대상 분기와 병합하여 발생하는 YAML 파일이 PR 동작을 제어합니다. 올바른 분기의 YAML 파일에 필요한 CI 또는 PR 구성이 있는지 확인합니다.
트리거를 올바르게 구성했나요? YAML 트리거를 정의할 때 분기, 태그 및 경로에 대한 include 및 exclude 절을 모두 지정할 수 있습니다. include 절이 커밋의 세부 정보와 일치하고 제외 절에서 제외하지 않는지 확인합니다. 트리거의 구문을 확인하고 정확한지 확인합니다.
트리거 또는 경로를 정의하는 데 변수를 사용했나요? 이는 지원되지 않습니다.
YAML 파일에 템플릿을 사용했나요? 그렇다면 트리거가 기본 YAML 파일에 정의되어 있는지 확인합니다. 템플릿 파일 내에 정의된 트리거는 지원되지 않습니다.
변경 내용을 푸시한 분기 또는 경로를 제외했나요? 포함된 분기의 포함된 경로로 변경한 항목을 푸시하여 테스트합니다. 트리거의 경로는 대/소문자를 구분합니다. 트리거에서 경로를 지정할 때 실제 폴더의 사례와 동일한 경우를 사용해야 합니다.
새 분기를 푸시했나요? 이 경우 새 분기가 새 실행을 시작하지 않을 수 있습니다. "새 분기를 만들 때 트리거의 동작" 섹션을 참조하세요.

CI 또는 PR 트리거가 정상적으로 작동했습니다. 그러나, 그들은 지금 일을 중단.

먼저 이전 질문의 문제 해결 단계를 진행합니다. 그런 다음, 다음 추가 단계를 수행합니다.

PR에 병합 충돌 있나요? 파이프라인을 트리거하지 않은 PR의 경우 파이프라인을 열고 병합 충돌 있는지 확인합니다. 병합 충돌 해결합니다.
푸시 또는 PR 이벤트 처리가 지연되나요? 일반적으로 문제가 단일 파이프라인과 관련이 있는지 또는 프로젝트의 모든 파이프라인 또는 리포지토리에 공통적인지 확인하여 이를 확인할 수 있습니다. 리포지토리에 대한 푸시 또는 PR 업데이트가 이러한 증상을 보이는 경우 업데이트 이벤트 처리가 지연될 수 있습니다. 상태 페이지에서 서비스 중단 이 발생하는지 확인합니다. 상태 페이지에 문제가 표시되면 우리 팀은 이미 문제를 해결하기 시작했어야 합니다. 이 문제에 대한 업데이트는 페이지를 자주 확인하세요.

사용자가 YAML 파일을 업데이트할 때 트리거에 대한 분기 목록을 재정의하지 않도록 합니다. 어떻게 하면 되나요?

코드를 기여할 수 있는 권한이 있는 사용자는 YAML 파일을 업데이트하고 추가 분기를 포함/제외할 수 있습니다. 따라서 사용자는 YAML 파일에 자신의 기능 또는 사용자 분기를 포함하고 해당 업데이트를 기능 또는 사용자 분기에 푸시할 수 있습니다. 이로 인해 해당 분기에 대한 모든 업데이트에 대해 파이프라인이 트리거될 수 있습니다. 이 동작을 방지하려면 다음을 수행할 수 있습니다.

Azure Pipelines UI에서 파이프라인을 편집합니다.
트리거 메뉴로 이동합니다.
여기에서 YAML 연속 통합 트리거 재정의를 선택합니다.
트리거에 포함하거나 제외할 분기를 지정합니다.

이러한 단계를 수행하면 YAML 파일에 지정된 모든 CI 트리거가 무시됩니다.

YAML 파이프라인에 여러 리포지토리가 있습니다. 각 리포지토리에 대한 트리거를 어떻게 설정하나요?

여러 리포지토리 사용에서 트리거를 참조하세요.

체크 아웃 실패

체크 아웃 단계 중에 로그 파일에 다음 오류가 표시됩니다. 수정 방법

remote: TF401019: The Git repository with name or identifier XYZ does not exist or you do not have permissions for the operation you are attempting.
fatal: repository 'XYZ' not found
##[error] Git fetch failed with exit code: 128

다음 각 단계에 따라 실패한 체크 아웃 문제를 해결합니다.

리포지토리가 여전히 존재하나요? 먼저 Repos 페이지에서 열어야 합니다.
스크립트를 사용하여 리포지토리에 액세스하고 있나요? 그렇다면 참조된 Azure DevOps 리포지토리 설정으로 작업 권한 부여 제한 범위를 확인합니다 . 참조된 Azure DevOps 리포지토리로 작업 권한 부여 범위를 제한하는 경우 파이프라인에서 먼저 명시적으로 참조되지 않는 한 스크립트를 사용하여 Azure Repos Git 리포지토리를 체크 아웃할 수 없습니다.
파이프라인의 작업 권한 부여 범위 는 무엇인가요?
- 범위가 컬렉션인 경우:
  - 일시적인 오류일 수 있습니다. 파이프라인을 다시 실행합니다.
  - 다른 사용자가 Project Collection Build Service 계정에 대한 액세스를 제거했을 수 있습니다.
    - 리포지토리가 있는 프로젝트의 프로젝트 설정으로 이동합니다. 리포지 > 토리 특정 리포지>토리를 선택한 다음 보안을 선택합니다.
    - 사용자 목록에 Project Collection Build Service(사용자 컬렉션 이름)가 있는지 확인합니다.
    - 해당 계정에 태그 만들기 및 읽기 권한이 있는지 확인합니다.
- 범위가 프로젝트인 경우:
  - 리포지토리가 파이프라인과 동일한 프로젝트에 있나요?
    - 예:
      - 일시적인 오류일 수 있습니다. 파이프라인을 다시 실행합니다.
      - 다른 사용자가 Project Build Service 계정에 대한 액세스를 제거했을 수 있습니다.
        
        리포지토리가 있는 프로젝트의 프로젝트 설정으로 이동합니다. 리포지 > 토리 특정 리포지>토리를 선택한 다음 보안을 선택합니다.
        
        사용자 목록에 프로젝트 이름 빌드 서비스(사용자 컬렉션 이름)가 있는지 확인합니다.
        
        해당 계정에 태그 만들기 및 읽기 권한이 있는지 확인합니다.
    - 아니요:
      - 파이프라인이 공용 프로젝트에 있나요?
        
        예: 공용 프로젝트 외부에서는 리소스에 액세스할 수 없습니다. 프로젝트를 비공개로 만듭니다.
        
        아니요: 동일한 프로젝트 컬렉션의 다른 리포지토리에 액세스할 수 있는 권한을 구성해야 합니다.

잘못된 버전

파이프라인에서 잘못된 버전의 YAML 파일이 사용되고 있습니다. 왜 그럴까요?

CI 트리거의 경우 푸시하는 분기에 있는 YAML 파일을 평가하여 CI 빌드를 실행해야 하는지 확인합니다.
PR 트리거의 경우 PR의 원본 및 대상 분기를 병합하여 발생하는 YAML 파일을 평가하여 PR 빌드를 실행해야 하는지 확인합니다.

다음을 통해 공유

Azure Repos Git 또는 TFS Git 리포지토리 빌드

빌드할 리포지토리 선택

CI 트리거

분기

CI 실행 일괄 처리

경로

태그

CI 옵트아웃

CI 트리거를 사용하지 않도록 설정

개별 푸시에 대한 CI 건너뛰기

조건에서 트리거 유형 사용

새 분기를 만들 때 트리거의 동작

와일드카드

PR 트리거

포크에서 기여 유효성 검사

작업 권한 부여 범위 제한

작업 권한 부여 범위를 현재 프로젝트로 제한

참조된 Azure DevOps 리포지토리로 작업 권한 부여 범위 제한

YAML 파이프라인에서 리포지토리에 대한 액세스 보호

체크 아웃

기본 버전의 Git

체크 아웃 경로

하위 모듈

체크 아웃 하위 모듈 옵션을 사용하는 대신

태그 동기화

기본 동작

단순 인출

원본 동기화 안 함

클린 빌드

레이블 원본

FAQ

실패한 트리거

CI/PR 트리거를 사용하여 새 YAML 파이프라인을 만들었지만 파이프라인은 트리거되지 않습니다.

CI 또는 PR 트리거가 정상적으로 작동했습니다. 그러나, 그들은 지금 일을 중단.

사용자가 YAML 파일을 업데이트할 때 트리거에 대한 분기 목록을 재정의하지 않도록 합니다. 어떻게 하면 되나요?

YAML 파이프라인에 여러 리포지토리가 있습니다. 각 리포지토리에 대한 트리거를 어떻게 설정하나요?

체크 아웃 실패

체크 아웃 단계 중에 로그 파일에 다음 오류가 표시됩니다. 수정 방법

잘못된 버전

파이프라인에서 잘못된 버전의 YAML 파일이 사용되고 있습니다. 왜 그럴까요?

관련된 문서

피드백

추가 리소스