GitHub 리포지토리 빌드

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에서 동일한 구조를 설정하려면 다음을 수행합니다.

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

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

사용자

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

GitHub 조직 역할

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

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

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

GitHub 사용자 계정 역할

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

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

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

GitHub 리포지토리 권한

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

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

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

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

파이프라인별 권한

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

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

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

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

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

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 앱은 설치하는 동안 다음 권한을 요청합니다.

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에 인증합니다. 이 작업은 새 서비스 연결 > GitHub > 권한 부여를 > Pipelines > Service 연결 아래의 Azure DevOps 프로젝트 설정에서 수행할 수 있습니다. 여기"사용 권한" Azure Pipelines에 리포지토리에 대한 액세스 권한을 부여합니다.

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

• 리포지토리가 사용자가 소유한 GitHub 조직에 있는 경우 개인 GitHub 계정 자격 증명을 사용하여 OAuth를 사용하여 GitHub에 인증합니다. 이 작업은 새 서비스 연결 > GitHub > 권한 부여를 > Pipelines > Service 연결 아래의 Azure DevOps 프로젝트 설정에서 수행할 수 있습니다. 여기에서 "조직 액세스" Azure Pipelines에 조직에 대한 액세스 권한을 부여합니다. "공동 작업자 및 팀"의 리포지토리 설정에서 공동 작업자로 추가되거나 팀을 추가해야 합니다.

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

OAuth 액세스 취소

OAuth를 사용하도록 Azure Pipelines에 권한을 부여한 후 나중에 해지하고 추가 사용을 방지하려면 GitHub 설정에서 OAuth Apps 방문하세요. 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에는 , , 및 개인 액세스 토큰 아래에 필요한 액세스 범위가 있어야 합니다.

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

• 리포지토리가 소유한 GitHub 조직에 있는 경우 PAT에는 , , 및 개인 액세스 토큰 아래에 필요한 액세스 범위가 있어야 합니다. "공동 작업자 및 팀"의 리포지토리 설정에서 공동 작업자로 추가되거나 팀을 추가해야 합니다.

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

PAT 액세스 취소

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

CI 트리거

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

trigger:
- main
- releases/*

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

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

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

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

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

# specific tag
trigger:
  tags:
    include:
    - v2.*
    exclude:
    - v2.0

# A pipeline with no CI trigger
trigger: none

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

pr:
- main
- releases/*

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

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

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

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

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

# no PR triggers
pr: none

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

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

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

보호된 분기

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

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

1. 먼저 리포지토리에 대한 파이프라인을 만들고 해당 상태가 GitHub에 게시되도록 한 번 이상 빌드하여 GitHub가 파이프라인의 이름을 인식하도록 합니다.

2. 다음으로, 리포지토리의 설정에서 보호된 분기를 구성하는 GitHub의 설명서를 따릅니다.

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

   GitHub 파이프라인 상태 확인

외부 원본의 기여

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

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

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

액세스 제한 사항

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

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

포크의 기여

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

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

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

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

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

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

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

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

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

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

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

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

중요한 보안 고려 사항

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

• 파이프라인에서 비밀을 누출합니다. 이 위험을 완화하려면 리포지토리가 공용이거나 신뢰할 수 없는 사용자가 빌드를 자동으로 트리거하는 끌어오기 요청을 제출할 수 있는 경우 포크 빌드 확인란에 비밀을 사용할 수 있도록 설정하지 마세요. 이 옵션은 기본적으로 사용하지 않도록 설정됩니다.

• 에이전트를 실행하는 컴퓨터를 손상하여 다른 파이프라인에서 코드 또는 비밀을 도용합니다. 이를 완화하려면 다음을 수행합니다.

  • Microsoft 호스팅 에이전트 풀 사용하여 포크에서 끌어오기 요청을 빌드합니다. Microsoft에서 호스팅하는 에이전트 컴퓨터는 빌드를 완료한 후 즉시 삭제되므로 손상된 경우 지속적인 영향이 없습니다.

  • 자체 호스팅 에이전트사용해야 하는 경우 리포지토리가 비공개이고 끌어오기 요청 작성자를 신뢰하지 않는 한 비밀을 저장하거나 동일한 에이전트에서 비밀을 사용하는 다른 빌드 및 릴리스를 수행하지 마세요.

주석 트리거

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

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

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

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

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

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

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

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

정보 실행

정보 실행은 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

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

체크 아웃 경로

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

하위 모듈

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 명령에서 비밀을 채웁니다.

태그 동기화

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

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

steps:
- checkout: self
  fetchTags: true

기본 동작

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

단순 인출

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

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 init, 구성 및 페치

• 빌드 파이프라인을 사용하여 버전 제어의 코드에 의존하지 않는 자동화(예: 일부 스크립트)를 실행합니다.

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

클린 빌드

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

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

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

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 clean -ffdx
git reset --hard HEAD

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

레이블 원본

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

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

$(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/커밋에 대해 실패한 모든 검사를 다시 실행하거나, 처음에 성공했는지 여부에 관계없이 모든 검사를 다시 실행하도록 선택할 수 있습니다.

확인

실행 확인 이름 옆에 있는 "다시 실행" 링크를 클릭하면 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 Portal의 드롭다운 목록으로 최대 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 앱으로 전환하려면 다음 단계를 수행합니다.

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

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

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

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

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

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

1. GitHub 리포지토리에서 끌어오기 요청을 열고 주석을 /azp where. 이 보고서는 리포지토리가 매핑된 Azure DevOps 조직을 다시 보고합니다.

2. 매핑을 변경하려면 GitHub 조직에서 앱을 제거하고 다시 설치합니다. 다시 설치할 때 Azure DevOps로 리디렉션될 때 올바른 조직을 선택해야 합니다.

실패한 트리거

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

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

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

  파이프라인 설정 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 파일에 자신의 기능 또는 사용자 분기를 포함하고 해당 업데이트를 기능 또는 사용자 분기에 푸시할 수 있습니다. 이로 인해 해당 분기에 대한 모든 업데이트에 대해 파이프라인이 트리거될 수 있습니다. 이 동작을 방지하려면 다음을 수행할 수 있습니다.

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

이러한 단계를 수행하면 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을 간단하게 업데이트하여 문제를 해결할 수 있는지 확인합니다.

관련 문서

• 예약된 트리거
• 파이프라인 완료 트리거