Git 리포지토리용 파이프라인 옵션

아티클
07/03/2024

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

Azure DevOps 프로젝트, GitHub, GitHub Enterprise Server, Bitbucket Cloud 또는 다른 Git 리포지토리에서 Git 리포지토리를 사용하는 파이프라인을 편집하는 동안 다음과 같은 옵션이 있습니다.

기능	Azure Pipelines	Azure DevOps Server 2019 이상	TFS 2018
Branch	예	예	예
정리	예	예	예
태그 또는 레이블 원본	프로젝트; 클래식 전용	팀 프로젝트	팀 프로젝트
보고서 작성 상태	예	예	예
하위 모듈 확인	예	예	예
LFS에서 파일 체크 아웃	예	예	예
두 번째 리포지토리 복제	예	예	예
원본 동기화 안 함	예	예	예
단순 인출	예	예	예

참고 항목

원본 가져오기 태스크에서 고급 설정을 클릭하여 위의 옵션 중 일부를 확인합니다.

Branch

이 빌드를 수동으로 큐에 대기할 때 기본값이 되도록 하려는 분기입니다. 빌드에 대해 예약된 트리거를 설정하는 경우 빌드에서 최신 원본을 가져오는 분기입니다. 빌드가 CI(연속 통합)를 통해 트리거될 때 기본 분기 아무런 영향을 주지 않습니다. 일반적으로 리포지토리의 기본 분기(예: "master")와 동일하게 설정합니다.

에이전트에서 로컬 리포지토리 정리

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

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

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

참고 항목

매번 새 에이전트를 받게 되므로 Microsoft 호스팅 에이전트를 사용하는 경우에는 정리가 효과적이지 않습니다. 자체 호스팅 에이전트를 사용하는 경우 에이전트 풀이 구성된 방식에 따라 후속 파이프라인 실행(또는 동일한 파이프라인의 단계 또는 작업)에 대한 새 에이전트를 가져올 수 있으므로 정리하지 않는 것이 후속 실행, 작업 또는 단계가 이전 실행, 작업 또는 단계의 출력에 액세스할 수 있다는 보장은 아닙니다 .

참고 항목

자체 호스팅 에이전트를 사용하는 경우 에이전트 풀이 구성된 방식에 따라 후속 파이프라인 실행(또는 동일한 파이프라인의 단계 또는 작업)에 대한 새 에이전트를 가져올 수 있으므로 정리하지 않는 것이 후속 실행, 작업 또는 단계가 이전 실행, 작업 또는 단계의 출력에 액세스할 수 있다는 보장은 아닙니다 . 빌드 아티팩트를 사용하여 파이프라인 실행, 단계 또는 작업의 출력을 후속 실행, 단계 또는 작업과 공유할 수 있습니다.

YAML
클래식

Azure Pipelines, Azure DevOps Server 2019 이상

YAML 파이프라인에 사용할 수 있는 여러 가지 정리 옵션이 있습니다.

이 checkout 단계에는 옵션이 있습니다 clean . 로 설정 true하면 리포지토리를 가져오기 전에 파이프라인이 실행됩니다 execute git clean -ffdx && git reset --hard HEAD . 자세한 내용은 체크 아웃을 참조 하세요.
설정 job 에는 workspace 여러 정리 옵션(출력, 리소스, 모두)이 있습니다. 자세한 내용은 작업 영역을 참조 하세요.
파이프라인 설정 UI에는 클린 설정이 있습니다. true로 설정하면 파이프라인의 모든 checkout 단계에 대해 지정하는 clean: true 것과 같습니다. 정리 설정을 구성하려면 다음을 수행합니다.
1. 파이프라인을 편집하고, ...를 선택하고, 트리거를 선택합니다.
2. YAML을 선택하고 원본을 가져와 원하는 정리 설정을 구성합니다. 기본값은 true입니다.

파이프라인을 수동으로 실행할 때 정리 설정을 재정의하려면 런타임 매개 변수를 사용할 수 있습니다. 다음 예제에서는 런타임 매개 변수를 사용하여 체크 아웃 정리 설정을 구성합니다.

parameters:
- name: clean
  displayName: Checkout clean
  type: boolean
  default: true
  values:
  - false
  - true

trigger:
- main

pool: FabrikamPool
#  vmImage: 'ubuntu-latest'

steps:
- checkout: self
  clean: ${{ parameters.clean }}

기본적으로 clean 는 설정되지만 런타임 매개 변수에 true 대해 추가된 체크 아웃 정리 확인란을 선택 취소하여 파이프라인을 수동으로 실행할 때 재정의할 수 있습니다.

Azure Pipelines, TFS 2018, TFS 2017.2, TFS 2017.3

다음 옵션 중 하나를 선택합니다.

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

레이블 원본

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

참고 항목

빌드의 원본 리포지토리가 GitHub 리포지토리이거나 프로젝트의 Git 또는 TFVC 리포지토리인 경우에만 이 기능을 사용할 수 있습니다.

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

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

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

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

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

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

보고서 빌드 상태(Azure Pipelines, TFS 2018 이상)

팀에 원격 원본 리포지토리의 빌드 상태를 볼 수 있는 옵션이 있습니다.

원본이 프로젝트의 Azure Repos Git 리포지토리에 있는 경우 이 옵션은 빌드가 통과하거나 실패하는지 여부를 나타내는 배지 를 코드 페이지에 표시합니다. 빌드 상태는 다음 탭에 표시됩니다.

파일: 선택한 분기에 대한 최신 빌드의 상태를 나타냅니다.
커밋: 각 커밋의 빌드 상태를 나타냅니다(빌드에 대해 CI(연속 통합) 트리거를 사용하도록 설정해야 함).
분기: 각 분기에 대한 최신 빌드의 상태를 나타냅니다.

프로젝트에서 동일한 리포지토리에 여러 빌드 파이프라인을 사용하는 경우 하나 이상의 파이프라인에 대해 이 옵션을 사용하도록 선택할 수 있습니다. 이 옵션이 여러 파이프라인에서 사용하도록 설정된 경우 코드 페이지의 배지는 모든 파이프라인에서 최신 빌드의 상태를 나타냅니다. 팀 구성원은 빌드 상태 배지를 클릭하여 각 빌드 파이프라인에 대한 최신 빌드 상태를 볼 수 있습니다.

GitHub

원본이 GitHub에 있는 경우 이 옵션은 GitHub 검사 또는 상태 API를 사용하여 빌드 상태를 GitHub에 게시합니다. 빌드가 GitHub 끌어오기 요청에서 트리거되는 경우 GitHub 끌어오기 요청 페이지에서 상태를 볼 수 있습니다. 또한 GitHub 내에서 상태 정책을 설정하고 병합을 자동화할 수 있습니다. 빌드가 CI(연속 통합)에 의해 트리거되는 경우 GitHub의 커밋 또는 분기에서 빌드 상태를 볼 수 있습니다.

다른 유형의 Git 원격 리포지토리

원본이 다른 유형의 원격 리포지토리 있는 경우 Azure Pipelines 또는 TFS를 사용하여 해당 리포지토리에 빌드 상태를 자동으로 게시할 수 없습니다. 그러나 버전 제어 환경 내에서 빌드 상태를 통합하고 표시하는 방법으로 빌드 배지를 사용할 수 있습니다.

체크 아웃 경로

단일 리포지토리를 체크 아웃하는 경우 기본적으로 소스 코드가 호출 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: ).

여러 checkout 단계를 사용하고 여러 리포지토리를 체크 아웃하고 폴더 path를 사용하여 명시적으로 지정하려는 경우 다른 체크 아웃 단계 경로의 하위 폴더인 경로(예 C:\agent\_work\1\s\repo1 : 및 C:\agent\_work\1\s\repo1\repo2)를 사용하지 않는 것이 좋습니다. 그렇지 않으면 다른 리포지토리의 정리를 통해 체크 아웃 단계의 하위 폴더가 지워집니다. 이 경우는 clean 옵션이 true repo1인 경우 유효합니다.

참고 항목

체크 아웃 경로는 YAML 파이프라인에 대해서만 지정할 수 있습니다. 자세한 내용은 YAML 스키마의 체크 아웃 을 참조하세요.

하위 모듈 체크 아웃

하위 모듈에서 파일을 다운로드할 것인지 선택합니다. 즉시 하위 모듈 또는 모든 하위 모듈을 재귀 깊이에 중첩하도록 선택할 수 있습니다. 하위 모듈에서 LFS를 사용하려면 하위 모듈과 함께 LFS를 사용하는 방법에 대한 참고 사항을 참조하세요.

참고 항목

하위 모듈을 체크 아웃하기 위한 YAML 구문에 대한 자세한 내용은 YAML 스키마의 체크 아웃을 참조하세요.

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

인증되지 않음: 복제 또는 페치할 자격 증명이 없는 인증되지 않은 공용 리포지토리입니다.
인증:
- 위에서 지정한 Git 리포지토리와 동일한 프로젝트, GitHub 조직 또는 Bitbucket Cloud 계정에 포함됩니다.
- 주 리포지토리에 상대적인 URL을 사용하여 추가됩니다. 예를 들어 체크 아웃됩니다. 체크 아웃 git submodule add /../../submodule.git mymodule 되지 않습니다. git submodule add https://dev.azure.com/fabrikamfiber/_git/ConsoleApp mymodule

인증된 하위 모듈

참고 항목

SSH를 사용하지 않고 HTTPS를 사용하여 하위 모듈을 등록했는지 확인합니다.

에이전트가 주 리포지토리에서 원본을 가져오는 데 사용하는 것과 동일한 자격 증명을 사용하여 하위 모듈의 원본을 가져옵니다.

기본 리포지토리 및 하위 모듈이 Azure DevOps 프로젝트의 Azure Repos Git 리포지토리에 있는 경우 원본에 액세스하는 데 사용되는 계정을 선택할 수 있습니다. 옵션 탭의 빌드 작업 권한 부여 범위 메뉴에서 다음 중 하나를 선택합니다.

프로젝트 컬렉션 빌드 서비스 계정을 사용하는 프로젝트 컬렉션
Project Build Service 계정을 사용하는 현재 프로젝트 입니다.

사용하는 계정이 주 리포지토리와 하위 모듈 모두에 액세스할 수 있는지 확인합니다.

주 리포지토리와 하위 모듈이 동일한 GitHub 조직에 있는 경우 GitHub 서비스 연결에 저장된 토큰을 사용하여 원본에 액세스합니다.

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

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

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

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

"<BASIC_AUTH_TOKEN>"을 Base64로 인코딩된 토큰으로 바꿔야 합니다.

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

참고 항목

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

LFS에서 파일 체크 아웃

LFS(대용량 파일 스토리지)에서 파일을 다운로드할 것인지 선택합니다.

클래식 편집기에서 확인란을 선택하여 이 옵션을 사용하도록 설정합니다.

YAML 빌드에서 다음으로 설정된 체크 아웃 단계를 lfs 추가합니다 true.

steps:
- checkout: self
  lfs: true

TFS를 사용하거나 자체 호스팅 에이전트와 함께 Azure Pipelines를 사용하는 경우 이 옵션이 작동하려면 에이전트에 설치 git-lfs 해야 합니다. 호스트된 에이전트가 Windows를 사용하는 경우 변수를 System.PreferGitFromPath 사용하여 파이프라인이 컴퓨터에 설치한 git 및 git-lfs 버전을 사용하도록 하는 것이 좋습니다. 자세한 내용은 에이전트가 실행되는 Git 버전을 참조 하세요.

하위 모듈에서 Git LFS 사용

하위 모듈에 LFS 파일이 포함된 경우 하위 모듈을 체크 아웃하기 전에 Git LFS를 구성해야 합니다. Microsoft 호스팅 macOS 및 Linux 에이전트는 이러한 방식으로 미리 구성됩니다. Windows 에이전트 및 자체 호스팅 macOS/Linux 에이전트는 그렇지 않을 수 있습니다.

해결 방법으로 YAML을 사용하는 경우 다음 단계를 다음 단계 앞에 checkout추가할 수 있습니다.

steps:
- script: |
    git config --global --add filter.lfs.required true
    git config --global --add filter.lfs.smudge "git-lfs smudge -- %%f"
    git config --global --add filter.lfs.process "git-lfs filter-process"
    git config --global --add filter.lfs.clean "git-lfs clean -- %%f"
  displayName: Configure LFS for use with submodules
- checkout: self
  lfs: true
  submodules: true
# ... rest of steps ...

두 번째 리포지토리 복제

기본적으로 파이프라인은 Azure Repos 또는 외부 공급자의 하나의 리포지토리와 연결됩니다. 커밋 및 끌어오기 요청에서 빌드를 트리거할 수 있는 리포지토리입니다.

파이프라인에 두 번째 리포지토리의 원본을 포함할 수 있습니다. 스크립트를 작성하여 이 작업을 수행할 수 있습니다.

git clone https://github.com/Microsoft/TypeScript.git

리포지토리가 공용이 아닌 경우 인증을 Git 명령에 전달해야 합니다.

Azure Repos

파이프라인은 프로젝트의 다른 리포지토리에 이미 액세스할 수 있으며 다음 예제와 같이 스크립트 명령을 사용하여 파이프라인에서 복제할 수 있습니다.

- script: | 
    git clone -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" https://organization@dev.azure.com/project/FabrikamFiber/_git/reponame

다중 리포지토리 체크 아웃을 사용하여 파이프라인과 동일한 프로젝트에서 여러 리포지토리를 복제할 수 있습니다.

공용이 아닌 다른 프로젝트에서 리포지토리를 복제해야 하는 경우 해당 프로젝트에 대한 액세스 권한이 있는 사용자로 인증해야 합니다.

참고 항목

비밀 변수를 사용하여 자격 증명을 안전하게 저장합니다.

비밀 변수는 환경 변수로 스크립트에 자동으로 제공되지 않습니다. 매핑하는 방법에 대한 비밀 변수를 참조하세요.

Azure Repos의 경우 코드(읽기) 권한이 있는 개인용 액세스 토큰을 사용할 수 있습니다. 사용자 이름 없이 "기본" 권한 부여 헤더에서 암호 필드로 보냅니다. 즉, base64는 콜론을 포함하여 값을 :<PAT>인코딩합니다.

AUTH=$(echo -n ":$REPO_PAT" | openssl base64 | tr -d '\n')
git -c http.<repo URL>.extraheader="AUTHORIZATION: basic $AUTH" clone <repo URL> --no-checkout --branch master

원본 동기화 안 함

배포가 아닌 작업은 원본을 자동으로 가져옵니다. 해당 동작을 건너뛰려면 이 옵션을 사용합니다. 이 옵션은 다음과 같은 경우에 유용할 수 있습니다.

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

원본 다운로드를 사용하지 않도록 설정하려면 다음을 수행합니다.

Azure Pipelines, TFS 2018 이상: 고급 설정을 클릭한 다음 원본 동기화 안 함을 선택합니다.

참고 항목

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

단순 인출

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

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

참고 항목

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

이 옵션을 사용하도록 설정하려면 확인란을 선택한 후 깊이 상자에서 커밋 수를 지정합니다.

팁

Agent.Source.Git.ShallowFetchDepth 아래에 언급된 변수도 작동하며 확인란 컨트롤을 재정의합니다. 이렇게 하면 빌드를 큐에 대기할 때 설정을 수정할 수 있습니다.

경로에서 Git 선호

기본적으로 Windows 에이전트는 에이전트 소프트웨어와 함께 번들로 제공되는 Git 버전을 사용합니다. Microsoft는 에이전트와 함께 번들로 제공되는 Git 버전을 사용하는 것이 좋지만 이 기본 동작을 재정의하고 에이전트 컴퓨터가 경로에 설치한 Git 버전을 사용하는 몇 가지 옵션이 있습니다.

파이프라인에 명명된 System.PreferGitFromPath 파이프라인 변수를 true 설정합니다.
자체 호스팅 에이전트에서 에이전트 루트 디렉터리에 .env라는 파일을 만들고 파일에 줄을 System.PreferGitFromPath=true 추가할 수 있습니다. 자세한 내용은 각 개별 에이전트에 대해 서로 다른 환경 변수를 설정하는 어떻게 할까요? 참조하세요.

파이프라인에서 사용되는 Git의 버전을 보려면 다음 예제와 같이 파이프라인의 단계에 대한 checkout 로그를 확인할 수 있습니다.

Syncing repository: PathFilter (Git)
Prepending Path environment variable with directory containing 'git.exe'.
git version
git version 2.26.2.windows.1

이 설정은 Windows가 아닌 에이전트에서 항상 true입니다.

다른 Git에 대한 트리거 옵션

기타/외부 Git 리포지토리가 지정된 경우 CI 빌드를 사용하려면 인터넷에서 리포지토리에 액세스할 수 있어야 합니다. 리포지토리가 방화벽 또는 프록시 뒤에 있는 경우 예약된 빌드와 수동 빌드만 작동합니다.

FAQ

빌드 에이전트가 Git에서 사용할 수 있는 프로토콜은 무엇인가요?

에이전트는 HTTPS를 지원합니다.

에이전트는 아직 SSH를 지원하지 않습니다. Git 하위 모듈을 체크 아웃하는 동안 빌드에서 SSH 인증을 사용하도록 허용을 참조 하세요.

TFS 온-프레미스를 사용하고 있지만 일부 기능이 표시되지 않습니다. 이유는 무엇인가요?

일부 기능은 Azure Pipelines에서만 사용할 수 있으며 온-프레미스에서는 아직 사용할 수 없습니다. 최신 버전의 TFS로 업그레이드한 경우 일부 기능을 온-프레미스에서 사용할 수 있습니다.

다음을 통해 공유

Git 리포지토리용 파이프라인 옵션

Branch

에이전트에서 로컬 리포지토리 정리

Azure Pipelines, Azure DevOps Server 2019 이상

Azure Pipelines, TFS 2018, TFS 2017.2, TFS 2017.3

레이블 원본

보고서 빌드 상태(Azure Pipelines, TFS 2018 이상)

GitHub

다른 유형의 Git 원격 리포지토리

체크 아웃 경로

하위 모듈 체크 아웃

인증된 하위 모듈

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

LFS에서 파일 체크 아웃

하위 모듈에서 Git LFS 사용

두 번째 리포지토리 복제

Azure Repos

원본 동기화 안 함

단순 인출

경로에서 Git 선호

다른 Git에 대한 트리거 옵션

FAQ

빌드 에이전트가 Git에서 사용할 수 있는 프로토콜은 무엇인가요?

TFS 온-프레미스를 사용하고 있지만 일부 기능이 표시되지 않습니다. 이유는 무엇인가요?

피드백

추가 리소스