GitHub 리포지토리 빌드

아티클
11/27/2023

Azure DevOps Services

Azure Pipelines는 모든 끌어오기 요청을 자동으로 빌드하고 확인하며 GitHub 리포지토리를 커밋할 수 있습니다. 이 문서에서는 GitHub와 Azure Pipelines 간의 통합을 구성하는 방법을 설명합니다.

GitHub와 파이프라인 통합을 처음 접하는 경우 첫 번째 파이프라인 만들기의 단계를 따릅니다. 이 문서로 돌아와서 GitHub와 Azure Pipelines 간의 통합을 구성하고 사용자 지정하는 방법에 대해 자세히 알아보세요.

조직 및 사용자

GitHub와 Azure Pipelines는 서로 잘 통합되는 두 가지 독립적인 서비스입니다. 각 조직에는 자체 조직 및 사용자 관리가 있습니다. 이 섹션에서는 GitHub에서 Azure Pipelines로 조직 및 사용자를 복제하는 방법에 대한 권장 사항을 제공합니다.

조직

GitHub의 구조는 리포지토리를 포함하는 조직 및 사용자 계정으로 구성됩니다. GitHub의 설명서를 참조하세요.

GitHub 조직 구조

Azure DevOps의 구조는 프로젝트를 포함하는 조직으로 구성됩니다. 조직 구조 계획을 참조하세요.

Azure DevOps 조직 구조

Azure DevOps는 다음을 사용하여 GitHub 구조를 반영할 수 있습니다.

GitHub 조직 또는 사용자 계정에 대한 DevOps 조직
GitHub 리포지토리에 대한 DevOps 프로젝트

Azure DevOps에 매핑된 GitHub 구조체

Azure DevOps에서 동일한 구조를 설정하려면 다음을 수행합니다.

GitHub 조직 또는 사용자 계정의 이름을 따서 명명된 DevOps 조직을 만듭니다. 다음과 같은 https://dev.azure.com/your-organizationURL이 있습니다.
DevOps 조직에서 리포지토리의 이름을 따서 명명된 프로젝트를 만듭니다. 다음과 같은 https://dev.azure.com/your-organization/your-repositoryURL이 있습니다.
DevOps 프로젝트에서 빌드하는 GitHub 조직 및 리포지토리의 이름을 따서 명명된 파이프라인을 만듭니다(예: your-organization.your-repository.) 그런 다음 어떤 리포지토리를 사용할지 분명합니다.

이 패턴에 따라 GitHub 리포지토리 및 Azure DevOps Projects에는 일치하는 URL 경로가 있습니다. 예시:

서비스	URL
GitHub	`https://github.com/python/cpython`
Azure DevOps	`https://dev.azure.com/python/cpython`

사용자

GitHub 사용자는 Azure Pipelines에 자동으로 액세스하지 않습니다. Azure Pipelines는 GitHub ID를 인식하지 못합니다. 이러한 이유로 GitHub ID 및 전자 메일 주소를 사용하여 사용자에게 빌드 실패 또는 PR 유효성 검사 실패를 자동으로 알리도록 Azure Pipelines를 구성할 수 있는 방법은 없습니다. GitHub 사용자를 복제하려면 Azure Pipelines에서 새 사용자를 명시적으로 만들어야 합니다. 새 사용자를 만든 후에는 GitHub에서 해당 권한을 반영하도록 Azure DevOps에서 해당 권한을 구성할 수 있습니다. DevOps ID를 사용하여 DevOps에서 알림을 구성할 수도 있습니다.

GitHub 조직 역할

GitHub 조직 구성원 역할은 (바꾸기your-organization)에서 https://github.com/orgs/your-organization/people 찾을 수 있습니다.

DevOps 조직 구성원 권한은 (바꾸기your-organization)에서 https://dev.azure.com/your-organization/_settings/security 찾을 수 있습니다.

GitHub 조직의 역할 및 Azure DevOps 조직의 동등한 역할은 다음과 같습니다.

GitHub 조직 역할	DevOps 조직에 해당하는 항목
담당자	의 멤버 `Project Collection Administrators`
청구 관리자	의 멤버 `Project Collection Administrators`
멤버	의 멤버입니다 `Project Collection Valid Users`. 기본적으로 멤버 그룹에는 새 프로젝트를 만들 수 있는 권한이 없습니다. 사용 권한을 변경하려면 그룹의 `Create new projects` 사용 권한을 설정하거나 필요한 권한이 `Allow`있는 새 그룹을 만듭니다.

GitHub 사용자 계정 역할

GitHub 사용자 계정에는 계정의 소유권인 하나의 역할이 있습니다.

DevOps 조직 구성원 권한은 (바꾸기your-organization)에서 https://dev.azure.com/your-organization/_settings/security 찾을 수 있습니다.

GitHub 사용자 계정 역할은 다음과 같이 DevOps 조직 권한에 매핑됩니다.

GitHub 사용자 계정 역할	DevOps 조직에 해당하는 항목
담당자	의 멤버 `Project Collection Administrators`

GitHub 리포지토리 권한

GitHub 리포지토리 권한은 (바꾸기 your-organization 및your-repository)에서 https://github.com/your-organization/your-repository/settings/collaboration 찾을 수 있습니다.

DevOps 프로젝트 권한은 (바꾸기 your-organization 및your-project)에서 https://dev.azure.com/your-organization/your-project/_settings/security 찾을 수 있습니다.

GitHub 리포지토리와 Azure DevOps Projects 간의 동등한 권한은 다음과 같습니다.

GitHub 리포지토리 권한	DevOps 프로젝트에 해당
Admin	의 멤버 `Project Administrators`
쓰기	의 멤버 `Contributors`
읽기	의 멤버 `Readers`

GitHub 리포지토리에서 팀에 권한을 부여하는 경우 Azure DevOps 프로젝트 설정 섹션에서 일치하는 팀을 Teams 만들 수 있습니다. 그런 다음, 사용자와 마찬가지로 위의 보안 그룹에 팀을 추가합니다.

파이프라인별 권한

DevOps 프로젝트의 특정 파이프라인에 대한 권한을 사용자 또는 팀에 부여하려면 다음 단계를 수행합니다.

프로젝트의 파이프라인 페이지(예: https://dev.azure.com/your-organization/your-project/_build)를 방문합니다.
특정 사용 권한을 설정할 파이프라인을 선택합니다.
'...' 상황에 맞는 메뉴에서 보안을 선택합니다.
추가...를 선택하여 특정 사용자, 팀 또는 그룹을 추가하고 파이프라인에 대한 사용 권한을 사용자 지정합니다.

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

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

빌드를 트리거하고 빌드 중에 코드를 가져오려면 리포지토리에 대한 액세스 권한을 Azure Pipelines에 부여해야 합니다.

파이프라인을 만드는 동안 GitHub 리포지토리에 대한 Azure Pipelines 액세스 권한을 부여하기 위한 세 가지 인증 유형이 있습니다.

인증 유형	파이프라인을 사용하여 실행	GitHub 검사 사용
1. GitHub 앱	Azure Pipelines ID	예
2. OAuth	개인 GitHub ID	아니요
3. PAT(개인용 액세스 토큰)	개인 GitHub ID	아니요

GitHub 앱 인증

Azure Pipelines GitHub 앱은 연속 통합 파이프라인에 권장되는 인증 유형입니다. GitHub 계정 또는 조직에 GitHub 앱을 설치한 후에는 개인 GitHub ID를 사용하지 않고 파이프라인이 실행됩니다. 빌드 및 GitHub 상태 업데이트는 Azure Pipelines ID를 사용하여 수행됩니다. 이 앱은 GitHub 검사와 함께 작동하여 GitHub에서 빌드, 테스트 및 코드 검사 결과를 표시합니다.

GitHub 앱을 사용하려면 일부 또는 모든 리포지토리에 대한 GitHub 조직 또는 사용자 계정에 설치합니다. GitHub 앱은 앱의 홈페이지에서 설치 및 제거할 수 있습니다.

설치 후 리포지토리에 대한 파이프라인을 만들 때 GitHub 앱은 OAuth 대신 GitHub에 대한 Azure Pipelines의 기본 인증 방법이 됩니다.

GitHub 조직의 모든 리포지토리에 대해 GitHub 앱을 설치하는 경우 대량 이메일을 보내거나 사용자를 대신하여 파이프라인을 자동으로 설정하는 Azure Pipelines에 대해 걱정할 필요가 없습니다. 리포지토리 관리자는 모든 리포지토리에 앱을 설치하는 대신 개별 리포지토리에 대해 한 번에 하나씩 설치할 수 있습니다. 이렇게 하려면 관리자에게 더 많은 작업이 필요하지만 장점이나 단점은 없습니다.

GitHub에 필요한 권한

Azure Pipelines GitHub 앱을 설치하려면 GitHub 조직 소유자 또는 리포지토리 관리자여야 합니다. 또한 연속 통합 및 끌어오기 요청 트리거를 사용하여 GitHub 리포지토리에 대한 파이프라인을 만들려면 필요한 GitHub 권한이 구성되어 있어야 합니다. 그렇지 않으면 파이프라인을 만드는 동안 리포지토리 목록에 리포지토리가 표시되지 않습니다. 리포지토리의 인증 유형 및 소유권에 따라 적절한 액세스가 구성되었는지 확인합니다.

리포지토리가 개인 GitHub 계정에 있는 경우 개인 GitHub 계정에 Azure Pipelines GitHub 앱을 설치하면 Azure Pipelines에서 파이프라인을 만들 때 이 리포지토리를 나열할 수 있습니다.
리포지토리가 다른 사람의 개인 GitHub 계정에 있는 경우 다른 사용자는 개인 GitHub 계정에 Azure Pipelines GitHub 앱을 설치해야 합니다. "협력자" 아래 리포지토리의 설정에서 공동 작업자로 추가해야 합니다. 전자 메일로 전송되는 링크를 사용하여 공동 작업자가 되도록 초대를 수락합니다. 이렇게 하면 해당 리포지토리에 대한 파이프라인을 만들 수 있습니다.
리포지토리가 소유한 GitHub 조직에 있는 경우 GitHub 조직에 Azure Pipelines GitHub 앱을 설치합니다. 또한 "공동 작업자 및 팀"의 리포지토리 설정에 공동 작업자로 추가되거나 팀을 추가해야 합니다.
리포지토리가 다른 사용자가 소유한 GitHub 조직에 있는 경우 GitHub 조직 소유자 또는 리포지토리 관리자는 조직에 Azure Pipelines GitHub 앱을 설치해야 합니다. "공동 작업자 및 팀"의 리포지토리 설정에서 공동 작업자로 추가되거나 팀을 추가해야 합니다. 전자 메일로 전송되는 링크를 사용하여 공동 작업자가 되도록 초대를 수락합니다.

GitHub 앱 권한

GitHub 앱은 설치하는 동안 다음 권한을 요청합니다.

Permission	Azure Pipelines에서 사용 권한을 사용하는 방법
코드에 대한 쓰기 권한	의도적인 작업에서만 Azure Pipelines는 GItHub 리포지토리의 선택한 분기에 YAML 파일을 커밋하여 파이프라인 만들기를 간소화합니다.
메타데이터에 대한 읽기 권한	Azure Pipelines는 빌드 요약에서 빌드와 관련된 리포지토리, 분기 및 문제를 표시하기 위해 GitHub 메타데이터를 검색합니다.
검사에 대한 읽기 및 쓰기 액세스 권한	Azure Pipelines는 GitHub에 표시할 자체 빌드, 테스트 및 코드 검사 결과를 읽고 작성합니다.
끌어오기 요청에 대한 읽기 및 쓰기 액세스 권한	의도적인 작업에서만 Azure Pipelines는 GitHub 리포지토리의 선택한 분기에 커밋된 YAML 파일에 대한 끌어오기 요청을 만들어 파이프라인 만들기를 간소화합니다. 파이프라인은 끌어오기 요청과 연결된 빌드 요약에 표시할 요청 메타데이터를 검색합니다.

GitHub 앱 설치 문제 해결

GitHub는 다음과 같은 오류를 표시할 수 있습니다.

You do not have permission to modify this app on your-organization. Please contact an Organization Owner.

즉, GitHub 앱이 조직에 이미 설치되어 있는 것 같습니다. 조직에서 리포지토리에 대한 파이프라인을 만들면 GitHub 앱이 GitHub에 연결하는 데 자동으로 사용됩니다.

여러 Azure DevOps 조직 및 프로젝트에서 파이프라인 만들기

GitHub 앱이 설치되면 다른 Azure DevOps 조직 및 프로젝트에서 조직의 리포지토리에 대한 파이프라인을 만들 수 있습니다. 그러나 여러 Azure DevOps 조직에서 단일 리포지토리에 대한 파이프라인을 만드는 경우 GitHub 커밋 또는 끌어오기 요청에 의해 첫 번째 조직의 파이프라인만 자동으로 트리거될 수 있습니다. 수동 또는 예약된 빌드는 보조 Azure DevOps 조직에서 계속 가능합니다.

OAuth 인증

OAuth 는 개인 GitHub 계정의 리포지토리를 시작하는 가장 간단한 인증 유형입니다. GitHub 상태 업데이트는 개인 GitHub ID를 대신하여 수행됩니다. 파이프라인이 계속 작동하려면 리포지토리 액세스가 활성 상태로 유지되어야 합니다. Check와 같은 일부 GitHub 기능은 OAuth에서 사용할 수 없으며 GitHub 앱이 필요합니다.

OAuth를 사용하려면 파이프라인을 만드는 동안 리포지토리 목록 아래에 있는 다른 연결 선택을 선택합니다. 그런 다음, 권한을 선택하여 GitHub에 로그인하고 OAuth로 권한을 부여합니다. OAuth 연결은 나중에 사용할 수 있게 Azure DevOps 프로젝트에 저장되고 생성되는 파이프라인에 사용됩니다.

GitHub에 필요한 권한

연속 통합 및 끌어오기 요청 트리거를 사용하여 GitHub 리포지토리에 대한 파이프라인을 만들려면 필요한 GitHub 권한이 구성되어 있어야 합니다. 그렇지 않으면 파이프라인을 만드는 동안 리포지토리 목록에 리포지토리가 표시되지 않습니다. 리포지토리의 인증 유형 및 소유권에 따라 적절한 액세스가 구성되었는지 확인합니다.

리포지토리가 개인 GitHub 계정에 있는 경우 개인 GitHub 계정 자격 증명을 사용하여 OAuth를 사용하여 GitHub에 인증합니다. 이 작업은 Pipelines Service 연결 새 서비스 연결 > GitHub > 권한 부여 아래의 Azure DevOps > > 프로젝트 설정에서 수행할 수 있습니다. 여기에서 "사용 권한"에서 리포지토리에 대한 Azure Pipelines 액세스 권한을 부여합니다.
리포지토리가 다른 사람의 개인 GitHub 계정에 있는 경우 적어도 한 번은 다른 사용자가 개인 GitHub 계정 자격 증명을 사용하여 OAuth를 사용하여 GitHub에 인증해야 합니다. 이 작업은 Pipelines Service 연결 새 서비스 연결 > GitHub > 권한 부여 아래의 Azure DevOps > > 프로젝트 설정에서 수행할 수 있습니다. 다른 사용자는 여기에서 "권한"에 따라 해당 리포지토리에 대한 Azure Pipelines 액세스 권한을 부여해야 합니다. "협력자" 아래 리포지토리의 설정에서 공동 작업자로 추가해야 합니다. 전자 메일로 전송되는 링크를 사용하여 공동 작업자가 되도록 초대를 수락합니다.
리포지토리가 사용자가 소유한 GitHub 조직에 있는 경우 개인 GitHub 계정 자격 증명을 사용하여 OAuth를 사용하여 GitHub에 인증합니다. 이 작업은 Pipelines Service 연결 새 서비스 연결 > GitHub > 권한 부여 아래의 Azure DevOps > > 프로젝트 설정에서 수행할 수 있습니다. 여기에서 "조직 액세스" 에서 조직에 대한 Azure Pipelines 액세스 권한을 부여합니다. "공동 작업자 및 팀"의 리포지토리 설정에서 공동 작업자로 추가되거나 팀을 추가해야 합니다.
리포지토리가 다른 사용자가 소유한 GitHub 조직에 있는 경우 GitHub 조직 소유자 개인 GitHub 계정 자격 증명을 사용하여 OAuth를 사용하여 GitHub에 인증해야 합니다. 이 작업은 Pipelines Service 연결 새 서비스 연결 > GitHub > 권한 부여 아래의 Azure DevOps > > 프로젝트 설정에서 수행할 수 있습니다. 조직 소유자 여기에서 "조직 액세스" 아래의 조직에 대한 Azure Pipelines 액세스 권한을 부여해야 합니다. "공동 작업자 및 팀"의 리포지토리 설정에서 공동 작업자로 추가되거나 팀을 추가해야 합니다. 전자 메일로 전송되는 링크를 사용하여 공동 작업자가 되도록 초대를 수락합니다.

OAuth 액세스 취소

OAuth를 사용하도록 Azure Pipelines에 권한을 부여한 후 나중에 해지하고 추가 사용을 방지하려면 GitHub 설정의 OAuth 앱 방문하세요. Azure DevOps 프로젝트 설정의 GitHub 서비스 연결 목록에서 삭제할 수도 있습니다.

PAT(개인 액세스 토큰) 인증

PAT 는 OAuth와 사실상 동일하지만 Azure Pipelines에 부여되는 권한을 제어할 수 있습니다. 빌드 및 GitHub 상태 업데이트는 개인 GitHub ID를 대신하여 수행됩니다. 빌드가 계속 작동하려면 리포지토리 액세스가 활성 상태로 유지되어야 합니다.

PAT를 만들려면 GitHub 설정에서 개인용 액세스 토큰을 방문하세요. 필요한 권한 repo은 , admin:repo_hook, read:user및 user:email. 위의 OAuth를 사용할 때 필요한 것과 동일한 권한입니다. 생성된 PAT를 클립보드에 복사하여 Azure DevOps 프로젝트 설정의 새 GitHub 서비스 연결 에 붙여넣습니다. 향후 회수를 위해 GitHub 사용자 이름 뒤의 서비스 연결 이름을 지정합니다. 파이프라인을 만들 때 나중에 사용할 수 있도록 Azure DevOps 프로젝트에서 사용할 수 있습니다.

GitHub에 필요한 권한

연속 통합 및 끌어오기 요청 트리거를 사용하여 GitHub 리포지토리에 대한 파이프라인을 만들려면 필요한 GitHub 권한이 구성되어 있어야 합니다. 그렇지 않으면 파이프라인을 만드는 동안 리포지토리 목록에 리포지토리가 표시되지 않습니다. 리포지토리의 인증 유형 및 소유권에 따라 다음 액세스가 구성되었는지 확인합니다.

리포지토리가 개인 GitHub 계정에 있는 경우 PAT에는 개인 액세스 토큰 아래에 필요한 액세스 범위가 read:useradmin:repo_hookuser:email있어야 합니다.repo
리포지토리가 다른 사람의 개인 GitHub 계정에 있는 경우 PAT에는 개인 액세스 토큰 아래에 필요한 액세스 범위가 read:useradmin:repo_hookuser:email있어야 합니다.repo "협력자" 아래 리포지토리의 설정에서 공동 작업자로 추가해야 합니다. 전자 메일로 전송되는 링크를 사용하여 공동 작업자가 되도록 초대를 수락합니다.
리포지토리가 소유한 GitHub 조직에 있는 경우 PAT에는 개인용 액세스 토큰 아래에 필요한 액세스 범위가 read:useradmin:repo_hookuser:email있어야 합니다.repo "공동 작업자 및 팀"의 리포지토리 설정에서 공동 작업자로 추가되거나 팀을 추가해야 합니다.
리포지토리가 다른 사용자가 소유한 GitHub 조직에 있는 경우 PAT에는 개인용 액세스 토큰 아래에 필요한 액세스 범위가 read:useradmin:repo_hookuser:email있어야 합니다.repo "공동 작업자 및 팀"의 리포지토리 설정에서 공동 작업자로 추가되거나 팀을 추가해야 합니다. 전자 메일로 전송되는 링크를 사용하여 공동 작업자가 되도록 초대를 수락합니다.

PAT 액세스 취소

PAT를 사용하도록 Azure Pipelines에 권한을 부여한 후 나중에 삭제하고 추가 사용을 방지하려면 GitHub 설정에서 개인용 액세스 토큰을 방문합니다. Azure DevOps 프로젝트 설정의 GitHub 서비스 연결 목록에서 삭제할 수도 있습니다.

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 트리거 git 분기

개별 커밋에 대한 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(끌어오기 요청) 트리거는 지정된 대상 분기 중 하나를 사용하여 끌어오기 요청을 열거나 이러한 끌어오기 요청에 대한 업데이트가 수행될 때마다 파이프라인을 실행합니다.

YAML
클래식

분기

끌어오기 요청의 유효성을 검사할 때 대상 분기를 지정할 수 있습니다. 예를 들어 대상 main releases/*인 끌어오기 요청의 유효성을 검사하려면 다음 pr 트리거를 사용할 수 있습니다.

pr:
- main
- releases/*

이 구성은 새 끌어오기 요청이 처음 생성되고 끌어오기 요청을 업데이트할 때마다 새 실행을 시작합니다.

분기의 전체 이름(예 main: ) 또는 와일드카드(예: releases/*)를 지정할 수 있습니다.

참고 항목

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

참고 항목

끌어오기 요청을 만들 때 GitHub는 새 ref 를 만듭니다. ref는 끌어오기 요청의 원본 분기와 대상 분기 간에 병합된 코드인 병합 커밋을 가리킵니다. PR 유효성 검사 파이프라인은 이 참조 가 가리키는 커밋을 빌드합니다. 즉, 파이프라인을 실행하는 데 사용되는 YAML 파일도 원본 분기와 대상 분기 간의 병합입니다. 따라서 끌어오기 요청의 원본 분기에서 YAML 파일을 변경하면 대상 분기의 YAML 파일에서 정의한 동작을 재정의할 수 있습니다.

YAML 파일에 트리거가 표시되지 않으면 pr 다음 pr 트리거를 작성한 것처럼 모든 분기에 대해 끌어오기 요청 유효성 검사가 자동으로 활성화됩니다. 이 구성은 끌어오기 요청이 만들어지고 커밋이 활성 끌어오기 요청의 원본 분기에 들어올 때 빌드를 트리거합니다.

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

Important

분기의 하위 집합을 사용하여 pr 트리거를 지정하면 업데이트가 해당 분기에 푸시될 때만 파이프라인이 트리거됩니다.

특정 분기를 제외해야 하는 더 복잡한 트리거의 경우 다음 예제와 같이 전체 구문을 사용해야 합니다. 이 예제에서는 끌어오기 요청이 대상 main 인지 아니면 releases/* 분기 releases/old* 가 제외되는지 유효성을 검사합니다.

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

경로

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

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

팁:

Azure Pipelines는 경로 제외 규칙 때문에 유효성 검사 빌드를 실행하지 않기로 결정할 때 중립 상태를 GitHub에 다시 게시합니다. 이렇게 하면 Azure Pipelines가 처리를 완료했음을 나타내는 GitHub에 대한 명확한 방향을 제공합니다. 자세한 내용은 빌드를 건너뛸 때 GitHub에 중립 상태 게시를 참조하세요.

와일드 카드는 이제 경로 필터에서 지원됩니다.

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

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

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

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

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

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

Azure Pipelines는 경로 제외 규칙 때문에 유효성 검사 빌드를 실행하지 않기로 결정할 때 중립 상태를 GitHub에 다시 게시합니다.

여러 PR 업데이트

PR에 대한 더 많은 업데이트가 동일한 PR에 대해 진행 중인 유효성 검사 실행을 취소해야 하는지 여부를 지정할 수 있습니다. 기본값은 true입니다.

# auto cancel false
pr:
  autoCancel: false
  branches:
    include:
    - main

PR 유효성 검사 초안

기본적으로 끌어오기 요청 트리거는 초안 끌어오기 요청 및 검토할 준비가 된 끌어오기 요청에 대해 발생합니다. 끌어오기 요청 초안에 대한 끌어오기 요청 트리거를 사용하지 않도록 설정하려면 속성을 false.로 설정합니다drafts.

pr:
  autoCancel: boolean # indicates whether additional pushes to a PR should cancel in-progress runs for the same PR. Defaults to true
  branches:
    include: [ string ] # branch names which will trigger a build
    exclude: [ string ] # branch names which will not
  paths:
    include: [ string ] # file paths which must match to trigger a build
    exclude: [ string ] # file paths which will not trigger a build
  drafts: boolean # whether to build draft PRs, defaults to true

PR 유효성 검사 옵트아웃

를 지정하여 끌어오기 요청 유효성 검사를 완전히 옵트아웃할 수 있습니다 pr: none.

# no PR triggers
pr: none

자세한 내용은 YAML 스키마의 PR 트리거 를 참조하세요.

참고 항목

pr 트리거가 실행되지 않는 경우 FAQ의 문제 해결 단계를 따릅니다.

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

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

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

보호된 분기

분기를 대상으로 하는 각 커밋 또는 끌어오기 요청을 사용하여 유효성 검사 빌드를 실행하고 유효성 검사 빌드가 성공할 때까지 끌어오기 요청이 병합되지 않도록 할 수도 있습니다.

GitHub 리포지토리에 대한 필수 유효성 검사 빌드를 구성하려면 해당 소유자, 관리자 역할의 협력자 또는 쓰기 역할이 있는 GitHub 조직 구성원이어야 합니다.

먼저 리포지토리에 대한 파이프라인을 만들고 해당 상태가 GitHub에 게시되도록 한 번 이상 빌드하여 GitHub가 파이프라인의 이름을 인식하도록 합니다.
다음으로, 리포지토리의 설정에서 보호된 분기 구성하기 위한 GitHub의 설명서를 따릅니다.

상태 확인의 경우 상태 검사 목록에서 파이프라인의 이름을 선택합니다.

Important

파이프라인이 이 목록에 표시되지 않는 경우 다음을 확인하세요.

GitHub 앱 인증을 사용하고 있습니다.
파이프라인이 지난 주에 한 번 이상 실행되었습니다.

외부 원본의 기여

GitHub 리포지토리가 오픈 소스 경우 누구나 로그인하지 않고 파이프라인의 빌드 결과, 로그 및 테스트 결과를 볼 수 있도록 Azure DevOps 프로젝트를 공개할 수 있습니다. 조직 외부 사용자가 리포지토리를 포크하고 끌어오기 요청을 제출할 때 해당 끌어오기 요청의 유효성을 자동으로 검사하는 빌드의 상태를 볼 수 있습니다.

외부 원본의 기여를 수락할 때 공용 프로젝트에서 Azure Pipelines를 사용할 때 다음 사항을 고려해야 합니다.

액세스 제한
포크에서 기여 유효성 검사
중요한 보안 고려 사항

액세스 제한

Azure DevOps 퍼블릭 프로젝트에서 파이프라인을 실행하는 경우 다음과 같은 액세스 제한 사항에 유의하세요.

비밀: 기본적으로 파이프라인과 연결된 비밀은 포크의 끌어오기 요청 유효성 검사에 사용할 수 없습니다. 포크에서 기여 유효성 검사를 참조 하세요.
프로젝트 간 액세스: Azure DevOps 공용 프로젝트의 모든 파이프라인은 프로젝트로 제한된 액세스 토큰으로 실행됩니다. 공용 프로젝트의 파이프라인은 Azure DevOps 조직의 다른 프로젝트가 아닌 프로젝트 내에서만 빌드 아티팩트 또는 테스트 결과와 같은 리소스에 액세스할 수 있습니다.
Azure Artifacts 패키지: 파이프라인이 Azure Artifacts의 패키지에 액세스해야 하는 경우 패키지 피드에 액세스하려면 Project Build Service 계정에 명시적으로 권한을 부여해야 합니다.

포크의 기여

Important

이러한 설정은 파이프라인의 보안에 영향을 줍니다.

파이프라인을 만들면 리포지토리의 포크에서 끌어오기 요청에 대해 자동으로 트리거됩니다. 보안에 미치는 영향을 신중하게 고려하여 이 동작을 변경할 수 있습니다. 이 동작을 사용하거나 사용하지 않도록 설정하려면 다음을 수행합니다.

Azure DevOps 프로젝트로 이동합니다. 파이프라인을 선택하고, 파이프라인을 찾고, 편집을 선택합니다.
트리거 탭을 선택합니다. 끌어오기 요청 트리거를 사용하도록 설정한 후 이 리포지토리의 포크에서 끌어오기 요청 빌드를 사용하거나 사용하지 않도록 설정합니다.

기본적으로 GitHub 파이프라인에서는 빌드 파이프라인과 연결된 비밀을 포크의 끌어오기 요청 빌드에 사용할 수 없습니다. 이러한 비밀은 기본적으로 GitHub Enterprise Server 파이프라인에서 사용하도록 설정됩니다. 비밀은 다음과 같습니다.

GitHub 리포지토리에 대한 액세스 권한이 있는 보안 토큰입니다.
파이프라인에서 사용하는 항목은 다음과 같습니다.
- 서비스 연결 자격 증명
- 보안 파일 라이브러리의 파일
- 비밀로 표시된 변수 빌드

GitHub 파이프라인에서 이 예방 조치를 무시하려면 포크 빌드에 비밀을 사용할 수 있도록 설정 확인란을 사용합니다. 이 설정이 보안에 미치는 영향에 유의하세요.

참고 항목

포크 빌드를 사용하여 비밀에 액세스하도록 설정하면 기본적으로 Azure Pipelines는 포크 빌드에 사용되는 액세스 토큰을 제한합니다. 일반 액세스 토큰보다 열린 리소스에 대한 액세스가 더 제한적입니다. 포크 빌드에 일반 빌드와 동일한 권한을 부여하려면 포크 만들기 빌드에 일반 빌드 설정과 동일한 사용 권한이 있도록 설정합니다.

자세한 내용은 리포지토리 보호 - 포크를 참조 하세요.

분기된 GitHub 리포지토리 컨트롤의 빌드 끌어오기 요청 제한을 사용하여 파이프라인이 포크된 GitHub 리포지 토리에서 PR을 빌드하는 방법을 중앙에서 정의할 수 있습니다. 조직 및 프로젝트 수준에서 사용할 수 있습니다. 다음을 선택할 수 있습니다.

포크된 리포지토리에서 끌어오기 요청 빌드 사용 안 함
포크된 리포지토리에서 끌어오기 요청을 안전하게 빌드
포크된 리포지토리에서 끌어오기 요청을 빌드하기 위한 규칙 사용자 지정

파이프라인이 분기된 GitHub 리포지토리에서 PR을 빌드하는 방법에 대한 중앙 집중식 컨트롤 설정의 스크린샷

Sprint 229부터 파이프라인의 보안을 개선하기 위해 Azure Pipelines는 더 이상 포크된 GitHub 리포지토리에서 끌어오기 요청을 자동으로 빌드하지 않습니다. 새 프로젝트 및 조직의 경우 포크된 GitHub 리포지토리 설정에서 끌어오기 요청 제한의 기본값은 포크된 리포지토리에서 끌어오기 요청 빌드를 사용하지 않도록 설정하는 것입니다.

포크된 리포지토리 옵션에서 안전하게 빌드 끌어오기 요청을 선택하면 모든 파이프라인, 조직 또는 프로젝트 전체에서 포크된 리포지토리의 PR 빌드에 비밀을 사용할 수 없으며, 이러한 빌드가 일반 빌드와 동일한 권한을 가지도록 할 수 없으며 PR 주석에 의해 트리거되어야 합니다. 프로젝트는 여전히 파이프라인이 이러한 PR을 빌드하는 것을 허용하지 않도록 결정할 수 있습니다.

사용자 지정 옵션을 선택하면 파이프라인 설정을 제한하는 방법을 정의할 수 있습니다. 예를 들어 PR이 팀 구성원이 아닌 멤버 및 비 기여자에게 속한 경우 포크된 GitHub 리포지토리에서 PR을 빌드하기 위해 모든 파이프라인에 주석이 필요한지 확인할 수 있습니다. 그러나 이러한 빌드에서 비밀을 사용할 수 있도록 허용할 수 있습니다. 프로젝트는 파이프라인이 이러한 PR을 빌드하거나 안전하게 빌드하는 것을 허용하지 않거나 조직 수준에서 지정된 것보다 훨씬 더 제한적인 설정을 갖도록 결정할 수 있습니다.

기존 조직에 대해 컨트롤이 꺼져 있습니다. 2023년 9월부터 새 조직은 기본적으로 켜져 있는 포크된 리포지토리에서 끌어오기 요청을 안전하게 빌드합니다.

중요한 보안 고려 사항

GitHub 사용자는 리포지토리를 포크하고, 변경하고, 끌어오기 요청을 만들어 리포지토리에 변경 내용을 제안할 수 있습니다. 이 끌어오기 요청에는 트리거된 빌드의 일부로 실행할 악성 코드가 포함될 수 있습니다. 이러한 코드는 다음과 같은 방법으로 피해를 줄 수 있습니다.

파이프라인에서 비밀을 누출합니다. 이 위험을 완화하려면 리포지토리가 공용이거나 신뢰할 수 없는 사용자가 빌드를 자동으로 트리거하는 끌어오기 요청을 제출할 수 있는 경우 포크 빌드에 비밀을 사용할 수 있도록 설정하지 마세요. 이 옵션은 기본적으로 비활성화됩니다.
에이전트를 실행하는 컴퓨터를 손상하여 다른 파이프라인에서 코드 또는 비밀을 도용합니다. 이를 완화하려면 다음을 수행합니다.
- Microsoft 호스팅 에이전트 풀을 사용하여 포크에서 끌어오기 요청을 빌드합니다. Microsoft에서 호스팅하는 에이전트 컴퓨터는 빌드를 완료한 후 즉시 삭제되므로 손상된 경우 지속적인 영향이 없습니다.
- 자체 호스팅 에이전트를 사용해야 하는 경우 리포지토리가 비공개이고 끌어오기 요청 작성자를 신뢰하지 않는 한 비밀을 저장하거나 동일한 에이전트에서 비밀을 사용하는 다른 빌드 및 릴리스를 수행하지 마세요.

주석 트리거

리포지토리 공동 작업자는 끌어오기 요청에 대해 주석을 달고 파이프라인을 수동으로 실행할 수 있습니다. 이 작업을 수행할 수 있는 몇 가지 일반적인 이유는 다음과 같습니다.

변경 내용을 검토할 수 있을 때까지 알 수 없는 사용자의 끌어오기 요청을 자동으로 빌드하지 않을 수 있습니다. 팀 구성원 중 한 명이 먼저 해당 코드를 검토한 다음 파이프라인을 실행하려고 합니다. 이는 일반적으로 포크된 리포지토리에서 기여 코드를 빌드할 때 보안 조치로 사용됩니다.
선택적 테스트 도구 모음 또는 하나 이상의 유효성 검사 빌드를 실행할 수 있습니다.

주석 트리거를 사용하도록 설정하려면 다음 두 단계를 수행해야 합니다.

파이프라인에 끌어오기 요청 트리거를 사용하도록 설정하고 대상 분기를 제외하지 않았는지 확인합니다.
Azure Pipelines 웹 포털에서 파이프라인을 편집하고 추가 작업인 트리거를 선택합니다. 그런 다음 끌어오기 요청 유효성 검사에서 끌어오기 요청을 작성하기 전에 팀 구성원의 주석 필요를 사용하도록 설정합니다.
- 끌어오기 요청을 작성하기 전에 팀 구성원의 의견을 요구하려면 모든 끌어오기 요청을 선택합니다. 이 워크플로를 사용하면 팀 구성원이 끌어오기 요청을 검토하고 끌어오기 요청이 안전하다고 판단되면 주석으로 빌드를 트리거합니다.
- 팀 구성원이 아닌 구성원이 PR을 수행한 경우에만 팀 구성원의 의견을 요구하도록 팀 구성원이 아닌 구성원의 끌어오기 요청에서만 선택합니다. 이 워크플로에서 팀 구성원은 빌드를 트리거하기 위해 보조 팀 구성원의 검토가 필요하지 않습니다.

이 두 가지 변경 내용을 사용하면 팀 구성원이 아닌 구성원의 끌어오기 요청만 선택하고 팀 구성원이 PR을 수행하지 않는 한 끌어오기 요청 유효성 검사 빌드가 자동으로 트리거되지 않습니다. '쓰기' 권한이 있는 리포지토리 소유자 및 협력자만 끌어오기 요청에 /AzurePipelines run 주석을 달거나 /AzurePipelines run <pipeline-name>클릭하여 빌드를 트리거할 수 있습니다.

주석으로 Azure Pipelines에 다음 명령을 실행할 수 있습니다.

명령	결과
`/AzurePipelines help`	지원되는 모든 명령에 대한 도움말을 표시합니다.
`/AzurePipelines help <command-name>`	지정된 명령에 대한 도움말을 표시합니다.
`/AzurePipelines run`	이 리포지토리와 연결되고 트리거가 이 끌어오기 요청을 제외하지 않는 모든 파이프라인을 실행합니다.
`/AzurePipelines run <pipeline-name>`	트리거가 이 끌어오기 요청을 제외하지 않는 한 지정된 파이프라인을 실행합니다.

참고 항목

간단히 하기 위해 대신 댓글을 달 /azp /AzurePipelines수 있습니다.

Important

이러한 명령에 대한 응답은 파이프라인이 Azure Pipelines GitHub 앱을 사용하는 경우에만 끌어오기 요청 토론에 표시됩니다.

끌어오기 요청 주석 트리거 문제 해결

필요한 리포지토리 권한이 있지만 파이프라인이 주석에 의해 트리거되지 않는 경우 멤버 자격이 리포지토리의 조직에 공개 되어 있는지 확인하거나 자신을 리포지토리 공동 작업자로 직접 추가합니다. 파이프라인은 직접 공동 작업자이거나 직접 협력자인 팀에 속하지 않는 한 프라이빗 조직 구성원을 볼 수 없습니다. 여기에서 GitHub 조직 구성원 자격을 비공개에서 공개로 변경할 수 있습니다(조직 이름으로 https://github.com/orgs/Your-Organization/people대체Your-Organization).

정보 실행

정보 실행은 Azure DevOps가 YAML 파이프라인의 소스 코드를 검색하지 못했음을 알려줍니다. 소스 코드 검색은 외부 이벤트(예: 푸시된 커밋)에 대한 응답으로 발생합니다. 예를 들어 코드 변경 내용이 있는지 확인하고 예약된 실행을 시작하는 등 내부 트리거에 대한 응답으로도 발생합니다. 소스 코드 검색은 여러 가지 이유로 실패할 수 있으며, git 리포지토리 공급자가 자주 요청을 제한합니다. 정보 실행이 있다고 해서 반드시 Azure DevOps가 파이프라인을 실행한다는 의미는 아닙니다.

정보 실행은 다음 스크린샷과 같습니다.

정보 파이프라인 실행의 스크린샷.

다음 특성으로 정보 실행을 인식할 수 있습니다.

상태가 Canceled
기간은 < 1s
실행 이름에는 다음 텍스트 중 하나가 포함됩니다.
- Could not retrieve file content for {file_path} from repository {repo_name} hosted on {host} using commit {commit_sha}.
- Could not retrieve content for object {commit_sha} from repository {repo_name} hosted on {host}.
- Could not retrieve the tree object {tree_sha} from the repository {repo_name} hosted on {host}.
- Could not find {file_path} from repository {repo_name} hosted on {host} using version {commit_sha}. One of the directories in the path contains too many files or subdirectories.
실행 이름에는 일반적으로 YAML 파이프라인 로드가 실패하게 한 BitBucket/GitHub 오류가 포함됩니다.
단계 없음 / 작업 / 단계

정보 실행에 대해 자세히 알아봅니다.

체크 아웃

파이프라인이 트리거되면 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입니다.

체크 아웃 경로

YAML
클래식

단일 리포지토리를 체크 아웃하는 경우 기본적으로 소스 코드가 호출 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} 가 있는 아티팩트가 완료된 빌드에 자동으로 추가됩니다. 이렇게 하면 팀에서 추가 추적 기능을 제공하고 빌드에서 빌드된 코드로 탐색할 수 있는 사용자 친화적인 방법을 제공합니다. 이 태그는 빌드에서 생성되므로 빌드 아티팩트로 간주됩니다. 수동으로 또는 보존 정책을 통해 빌드를 삭제하면 태그도 삭제됩니다.

미리 정의된 변수

GitHub 리포지토리를 빌드할 때는 대부분의 미리 정의된 변수를 작업에 사용할 수 있습니다. 그러나 Azure Pipelines는 GitHub에서 업데이트를 하는 사용자의 ID를 인식하지 못하므로 다음 변수는 사용자의 ID 대신 시스템 ID로 설정됩니다.

Build.RequestedFor
Build.RequestedForId
Build.RequestedForEmail

상태 업데이트

Azure Pipelines가 GitHub에 다시 게시하는 상태 유형에는 기본 상태와 GitHub 검사 실행의 두 가지 유형이 있습니다. GitHub Check 기능은 GitHub Apps에서만 사용할 수 있습니다.

파이프라인 상태는 GitHub UI의 다양한 위치에 표시됩니다.

PR의 경우 PR 대화 탭에 표시됩니다.
개별 커밋의 경우 리포지토리의 커밋 탭에서 커밋 시간 이후 상태 표시를 마우스로 가리키면 표시됩니다.

PAT 또는 OAuth GitHub 연결

PAT 또는 OAuth GitHub 연결을 사용하는 파이프라인의 경우 상태는 실행을 트리거한 커밋/PR에 다시 게시됩니다. GitHub 상태 API는 이러한 업데이트를 게시하는 데 사용됩니다. 이러한 상태에는 파이프라인 상태(실패, 성공), 빌드 파이프라인에 다시 연결할 URL 및 상태에 대한 간략한 설명과 같은 제한된 정보가 포함됩니다.

PAT 또는 OAuth GitHub 연결에 대한 상태는 실행 수준에서만 전송됩니다. 즉, 전체 실행에 대해 단일 상태를 업데이트할 수 있습니다. 실행에 여러 작업이 있는 경우 각 작업에 대해 별도의 상태를 게시할 수 없습니다. 그러나 여러 파이프라인은 동일한 커밋에 별도의 상태를 게시할 수 있습니다.

GitHub 검사

Azure Pipelines GitHub 앱을 사용하여 설정된 파이프라인의 경우 상태는 GitHub 검사 형식으로 다시 게시됩니다. GitHub 검사를 사용하면 파이프라인 상태 및 테스트, 코드 검사 및 오류에 대한 자세한 정보를 보낼 수 있습니다. GitHub Checks API는 여기에서 찾을 수 있습니다.

GitHub 앱을 사용하는 모든 파이프라인에 대해 전체 실행 및 해당 실행의 각 작업에 대한 검사가 다시 게시됩니다.

GitHub는 PR/커밋에 대해 하나 이상의 Check Runs가 실패할 때 세 가지 옵션을 허용합니다. 개별 검사를 "다시 실행"하거나, 해당 PR/커밋에 대해 실패한 모든 검사를 다시 실행하거나, 처음에 성공했는지 여부에 관계없이 모든 검사를 다시 실행하도록 선택할 수 있습니다.

GitHub 검사 다시 실행

실행 확인 이름 옆에 있는 "다시 실행" 링크를 클릭하면 Azure Pipelines에서 실행 검사를 생성한 실행을 다시 시도하게 됩니다. 결과 실행은 동일한 실행 번호를 가지며 초기 빌드와 동일한 버전의 소스 코드, 구성 및 YAML 파일을 사용합니다. 초기 실행에서 실패한 작업과 종속 다운스트림 작업만 다시 실행됩니다. "실패한 모든 검사 다시 실행" 링크를 클릭하면 동일한 효과가 적용됩니다. 이는 Azure Pipelines UI에서 "다시 시도 실행"을 클릭하는 것과 동일한 동작입니다. "모든 검사 다시 실행"을 클릭하면 새 실행 번호와 함께 새 실행이 발생하며 구성 또는 YAML 파일의 변경 내용이 선택됩니다.

제한 사항

최상의 성능을 위해 단일 리포지토리에 최대 50개의 파이프라인을 사용하는 것이 좋습니다. 허용되는 성능을 위해 단일 리포지토리에서 최대 100개의 파이프라인을 사용하는 것이 좋습니다. 리포지토리에 푸시를 처리하는 데 필요한 시간은 해당 리포지토리의 파이프라인 수와 함께 증가합니다. 리포지토리에 푸시할 때마다 Azure Pipelines는 해당 리포지토리의 모든 YAML 파이프라인을 로드하여 실행해야 하는지 파악하고 각 파이프라인을 로드하면 성능 저하가 발생합니다. 성능 문제 외에도 단일 리포지토리에 파이프라인이 너무 많으면 Azure Pipelines가 짧은 시간 안에 너무 많은 요청을 수행할 수 있으므로 GitHub 쪽에서 제한이 발생할 수 있습니다.
파이프라인에서 확장 및 포함 템플릿을 사용하면 Azure Pipelines가 GitHub API 요청을 수행하고 GitHub 쪽에서 제한될 수 있는 속도에 영향을 줍니다. 파이프라인을 실행하기 전에 Azure Pipelines는 전체 YAML 코드를 생성해야 하므로 모든 템플릿 파일을 가져와야 합니다.
Azure Pipelines는 리포지토리에서 Azure DevOps 포털의 드롭다운 목록으로 최대 2,000개의 분기를 로드합니다( 예: 수동 및 예약된 빌드 설정에 대한 기본 분기의 분기 선택 창에서 또는 파이프라인을 수동으로 실행할 때 분기를 선택할 때).

목록에 원하는 분기가 표시되지 않으면 수동 및 예약된 빌드 필드에 대해 기본 분기에 원하는 분기 이름을 수동으로 입력합니다 .

줄임표를 클릭하고 분기 선택 대화 상자를 열고 드롭다운 목록에서 유효한 분기를 선택하지 않고 닫는 경우 일부 설정에 주의 메시지가 필요하고 이 설정은 수동 및 예약된 빌드를 위해 기본 분기 아래에 필요한 메시지가 표시될 수 있습니다. 이 메시지를 해결하려면 파이프라인을 다시 열고 수동 및 예약된 빌드 필드에 대한 기본 분기에 직접 이름을 입력합니다 .

FAQ

GitHub 통합과 관련된 문제는 다음 범주로 분류됩니다.

연결 유형: 파이프라인을 GitHub에 연결하는 데 사용하는 연결 유형을 잘 모를 수 있습니다.
실패 트리거: 리포지토리에 업데이트를 푸시할 때 파이프라인이 트리거되지 않습니다.
체크 아웃 실패: 내 파이프라인이 트리거되고 있지만 체크 아웃 단계에서 실패합니다.
잘못된 버전: 내 파이프라인이 실행되지만 예기치 않은 버전의 원본/YAML을 사용하고 있습니다.
누락된 상태 업데이트: Azure Pipelines에서 상태 업데이트를 보고하지 않았기 때문에 내 GitHub PR이 차단됩니다.

연결 유형

트리거 문제를 해결하려면 파이프라인에 사용하는 GitHub 연결 유형을 어떻게 알 수 있나요?

트리거 관련 문제 해결은 파이프라인에서 사용하는 GitHub 연결 유형에 따라 크게 달라집니다. GitHub와 Azure Pipelines의 연결 형식을 확인하는 방법에는 두 가지가 있습니다.

GitHub에서: GitHub 앱을 사용하도록 리포지토리가 설정된 경우, PR 및 커밋의 상태는 실행 확인이 됩니다. 리포지토리에 OAuth 또는 PAT 연결을 사용하여 Azure Pipelines가 설정된 경우 상태는 상태의 "이전" 스타일이 됩니다. 상태가 실행 확인인지 또는 간단한 상태인지 확인하는 빠른 방법은 GitHub PR의 "대화" 탭을 확인하는 것입니다.
- "세부 정보" 링크가 검사 탭으로 리디렉션되는 경우 확인 실행이며 리포지토리가 앱을 사용하고 있습니다.
- "세부 정보" 링크가 Azure DevOps 파이프라인으로 리디렉션되는 경우 상태는 "이전 스타일" 상태이며 리포지토리는 앱을 사용하지 않습니다.
Azure Pipelines: Azure Pipelines UI에서 파이프라인을 검사하여 연결 유형을 확인할 수도 있습니다. 파이프라인에 대한 편집기를 엽니다. 트리거를 선택하여 파이프라인에 대한 클래식 편집기를 엽니다. 그런 다음 YAML 탭을 선택한 다음 원본 가져오기 단계를 선택합니다. 연결을 사용하여 권한이 부여된 배너가 표시됩니다. 이는 파이프라인을 GitHub와 통합하는 데 사용된 서비스 연결을 나타냅니다. 서비스 연결의 이름은 하이퍼링크입니다. 서비스 연결 속성으로 이동하려면 선택합니다. 서비스 연결의 속성은 사용 중인 연결 유형을 나타냅니다.
- Azure Pipelines 앱 은 GitHub 앱 연결을 나타냅니다.
- oauth 는 OAuth 연결을 나타냅니다.
- personalaccesstoken 은 PAT 인증을 나타냅니다.

OAuth 대신 GitHub 앱을 사용하도록 파이프라인을 전환할 어떻게 할까요? 있나요?

OAuth 또는 PAT 연결 대신 GitHub 앱을 사용하는 것이 GitHub와 Azure Pipelines 간의 권장 통합입니다. GitHub 앱으로 전환하려면 다음 단계를 수행합니다.

여기로 이동하여 리포지토리의 GitHub 조직에 앱을 설치합니다.
설치하는 동안 Azure DevOps 조직 및 프로젝트를 선택하기 위해 Azure DevOps로 리디렉션됩니다. 앱을 사용하려는 클래식 빌드 파이프라인이 포함된 조직 및 프로젝트를 선택합니다. 이 선택은 GitHub 앱 설치를 Azure DevOps 조직과 연결합니다. 잘못 선택하는 경우 이 페이지를 방문하여 GitHub 조직에서 GitHub 앱을 제거하고 다시 시작할 수 있습니다.
표시되는 다음 페이지에서는 새 파이프라인 만들기를 계속할 필요가 없습니다.
파이프라인 페이지(예: https://dev.azure.com/YOUR_ORG_NAME/YOUR_PROJECT_NAME/_build)파이프라인 선택 및 편집 클릭)를 방문하여 파이프라인을 편집합니다.
YAML 파이프라인인 경우 트리거 메뉴를 선택하여 클래식 편집기를 엽니다.
파이프라인에서 "원본 가져오기" 단계를 선택합니다.
"연결을 사용하여 권한이 부여됨"이라는 텍스트가 있는 녹색 표시줄에서 "변경"을 선택하고 앱을 설치한 GitHub 조직과 동일한 이름으로 GitHub 앱 연결을 선택합니다.
도구 모음에서 "저장 및 큐", "저장 및 큐"를 선택합니다. 큐에 대기된 파이프라인 실행에 대한 링크를 선택하여 성공하는지 확인합니다.
GitHub 리포지토리에서 끌어오기 요청을 만들거나 닫고 다시 열어 빌드가 "검사" 섹션에서 성공적으로 큐에 대기 중인지 확인합니다.

Azure Pipelines에서 선택할 수 있도록 GitHub 리포지토리가 표시되지 않는 이유는 무엇인가요?

리포지토리의 인증 유형 및 소유권에 따라 특정 권한이 필요합니다.

GitHub 앱을 사용하는 경우 GitHub 앱 인증을 참조하세요.
OAuth를 사용하는 경우 OAuth 인증을 참조하세요.
PAT를 사용하는 경우 PAT(개인용 액세스 토큰) 인증을 참조하세요.

파이프라인을 만드는 동안 리포지토리를 선택하면 "리포지토리 {repo-name}이 다른 Azure DevOps 조직의 Azure Pipelines GitHub 앱과 함께 사용 중입니다."라는 오류가 발생합니다.

즉, 리포지토리가 이미 다른 조직의 파이프라인과 연결되어 있습니다. 이 리포지토리의 CI 및 PR 이벤트는 다른 조직에 전달되므로 작동하지 않습니다. 파이프라인을 만들기 전에 다른 조직에 대한 매핑을 제거하기 위해 수행해야 하는 단계는 다음과 같습니다.

GitHub 리포지토리에서 끌어오기 요청을 열고 주석 /azp where을 만듭니다. 이 보고서는 리포지토리가 매핑된 Azure DevOps 조직을 다시 보고합니다.
매핑을 변경하려면 GitHub 조직에서 앱을 제거하고 다시 설치합니다. 다시 설치할 때 Azure DevOps로 리디렉션될 때 올바른 조직을 선택해야 합니다.

실패한 트리거

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

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

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

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

GitHub 앱 연결을 사용하여 파이프라인을 GitHub에 연결하고 있나요? 연결 유형을 확인하려면 연결 유형을 참조하세요. GitHub 앱 연결을 사용하는 경우 다음 단계를 수행합니다.
- GitHub와 Azure DevOps 간에 매핑이 제대로 설정되나요? GitHub 리포지토리에서 끌어오기 요청을 열고 주석 /azp where을 만듭니다. 이 보고서는 리포지토리가 매핑된 Azure DevOps 조직을 다시 보고합니다.
  - 앱을 사용하여 이 리포지토리를 빌드하도록 설정된 조직이 없는 경우 앱 구성으로 https://github.com/<org_name>/<repo_name>/settings/installations 이동하여 완료합니다.
  - 다른 Azure DevOps 조직이 보고되면 다른 조직에서 이 리포지토리에 대한 파이프라인을 이미 설정한 것입니다. 현재 GitHub 리포지토리를 단일 DevOps 조직에만 매핑할 수 있는 제한 사항이 있습니다. 첫 번째 Azure DevOps 조직의 파이프라인만 자동으로 트리거될 수 있습니다. 매핑을 변경하려면 GitHub 조직에서 앱을 제거하고 다시 설치합니다. 다시 설치할 때 Azure DevOps로 리디렉션될 때 올바른 조직을 선택해야 합니다.
OAuth 또는 PAT를 사용하여 파이프라인을 GitHub에 연결하나요? 연결 유형을 확인하려면 연결 유형을 참조하세요. GitHub 연결을 사용하는 경우 다음 단계를 수행합니다.
1. OAuth 및 PAT 연결은 웹후크를 사용하여 Azure Pipelines에 업데이트를 전달합니다. GitHub에서 리포지토리의 설정으로 이동한 다음 웹후크로 이동합니다. 웹후크가 있는지 확인합니다. 일반적으로 푸시, pull_request 및 issue_comment 세 가지 웹후크가 표시됩니다. 그렇지 않은 경우 서비스 연결을 다시 만들고 새 서비스 연결을 사용하도록 파이프라인을 업데이트해야 합니다.
2. GitHub에서 각 웹후크를 선택하고 사용자의 커밋에 해당하는 페이로드가 존재하고 Azure DevOps로 성공적으로 전송되었는지 확인합니다. Azure DevOps에 이벤트를 전달할 수 없는 경우 여기에 오류가 표시될 수 있습니다.
Azure DevOps의 트래픽은 GitHub에 의해 제한될 수 있습니다. Azure Pipelines가 GitHub에서 알림을 받으면 GitHub에 연락하여 리포지토리 및 YAML 파일에 대한 자세한 정보를 가져오려고 합니다. 많은 수의 업데이트 및 끌어오기 요청이 있는 리포지토리가 있는 경우 이러한 제한으로 인해 이 호출이 실패할 수 있습니다. 이 경우 일괄 처리 또는 더 엄격한 경로/분기 필터를 사용하여 빌드 빈도를 줄일 수 있는지 확인합니다.

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

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

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

PR에 병합 충돌 있나요? 파이프라인을 트리거하지 않은 PR의 경우 파이프라인을 열고 병합 충돌 있는지 확인합니다. 병합 충돌 해결합니다.
푸시 또는 PR 이벤트 처리가 지연되나요? 일반적으로 문제가 단일 파이프라인과 관련이 있는지 또는 프로젝트의 모든 파이프라인 또는 리포지토리에 공통적인지 확인하여 지연을 확인할 수 있습니다. 리포지토리에 대한 푸시 또는 PR 업데이트가 이러한 증상을 보이는 경우 업데이트 이벤트 처리가 지연될 수 있습니다. 지연이 발생할 수 있는 몇 가지 이유는 다음과 같습니다.
- 상태 페이지에서 서비스 중단이 발생합니다. 상태 페이지에 문제가 표시되면 우리 팀은 이미 문제를 해결하기 시작했어야 합니다. 이 문제에 대한 업데이트는 페이지를 자주 확인하세요.
- 리포지토리에 YAML 파이프라인이 너무 많습니다. 최상의 성능을 위해 단일 리포지토리에 최대 50개의 파이프라인을 사용하는 것이 좋습니다. 허용되는 성능을 위해 단일 리포지토리에서 최대 100개의 파이프라인을 사용하는 것이 좋습니다. 파이프라인이 많을수록 해당 리포지토리에 대한 푸시 처리 속도가 느려집니다. 리포지토리에 푸시가 있을 때마다 Azure Pipelines는 해당 리포지토리의 모든 YAML 파이프라인을 로드하여 실행해야 하는지를 파악하고 각 새 파이프라인에 성능 저하가 발생합니다.

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

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

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

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

체크 아웃 실패

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

remote: Repository not found.
fatal: repository <repo> not found

이는 GitHub의 중단으로 인해 발생할 수 있습니다. GitHub의 리포지토리에 액세스하여 수행할 수 있는지 확인합니다.

잘못된 버전

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

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

누락된 상태 업데이트

Azure Pipelines가 상태를 업데이트하지 않았기 때문에 GitHub의 내 PR이 차단되었습니다.

이는 일시적인 오류로 인해 Azure DevOps가 GitHub와 통신할 수 없게 될 수 있습니다. GitHub 앱을 사용하는 경우 체크 인 GitHub를 다시 시도합니다. 또는 PR을 간단하게 업데이트하여 문제를 해결할 수 있는지 확인합니다.

다음을 통해 공유

GitHub 리포지토리 빌드

조직 및 사용자

조직

사용자

GitHub 조직 역할

GitHub 사용자 계정 역할

GitHub 리포지토리 권한

파이프라인별 권한

GitHub 리포지토리에 대한 액세스

GitHub 앱 인증

GitHub에 필요한 권한

GitHub 앱 권한

GitHub 앱 설치 문제 해결

여러 Azure DevOps 조직 및 프로젝트에서 파이프라인 만들기

OAuth 인증

GitHub에 필요한 권한

OAuth 액세스 취소

PAT(개인 액세스 토큰) 인증

GitHub에 필요한 권한

PAT 액세스 취소

CI 트리거

분기

CI 실행 일괄 처리

경로

태그

CI 옵트아웃

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

개별 커밋에 대한 CI 건너뛰기

조건에서 트리거 유형 사용

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

와일드카드

PR 트리거

분기

경로

여러 PR 업데이트

PR 유효성 검사 초안

PR 유효성 검사 옵트아웃

보호된 분기

외부 원본의 기여

액세스 제한

포크의 기여

중요한 보안 고려 사항

주석 트리거

끌어오기 요청 주석 트리거 문제 해결

정보 실행

체크 아웃

기본 버전의 Git

체크 아웃 경로

하위 모듈

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

태그 동기화

기본 동작

단순 인출

원본 동기화 안 함

클린 빌드

레이블 원본

미리 정의된 변수

상태 업데이트

PAT 또는 OAuth GitHub 연결

GitHub 검사

제한 사항

FAQ

연결 유형

트리거 문제를 해결하려면 파이프라인에 사용하는 GitHub 연결 유형을 어떻게 알 수 있나요?

OAuth 대신 GitHub 앱을 사용하도록 파이프라인을 전환할 어떻게 할까요? 있나요?

Azure Pipelines에서 선택할 수 있도록 GitHub 리포지토리가 표시되지 않는 이유는 무엇인가요?

파이프라인을 만드는 동안 리포지토리를 선택하면 "리포지토리 {repo-name}이 다른 Azure DevOps 조직의 Azure Pipelines GitHub 앱과 함께 사용 중입니다."라는 오류가 발생합니다.

실패한 트리거

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

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

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

체크 아웃 실패

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

잘못된 버전

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

누락된 상태 업데이트

Azure Pipelines가 상태를 업데이트하지 않았기 때문에 GitHub의 내 PR이 차단되었습니다.

관련된 문서

피드백