GitHub Enterprise 서버 리포지토리 빌드

  • 아티클

Azure DevOps Services

온-프레미스 GitHub Enterprise Server를 Azure Pipelines와 통합할 수 있습니다. 온-프레미스 서버가 인터넷에 노출되거나 노출되지 않을 수 있습니다.

Azure Pipelines 서비스를 실행하는 서버에서 GitHub Enterprise Server에 연결할 수 있는 경우 다음을 수행합니다.

  • 클래식 빌드 및 YAML 파이프라인을 설정할 수 있습니다.
  • CI, PR 및 예약된 트리거를 구성할 수 있습니다.

Azure Pipelines 서비스를 실행하는 서버에서 GitHub Enterprise Server에 연결할 수 없는 경우 다음을 수행합니다.

  • 클래식 빌드 파이프라인만 설정할 수 있습니다.
  • 수동 또는 예약된 빌드만 시작할 수 있습니다.
  • YAML 파이프라인을 설정할 수 없습니다.
  • 클래식 빌드 파이프라인에 대한 CI 또는 PR 트리거를 구성할 수 없습니다.

Microsoft 호스팅 에이전트에서 온-프레미스 서버에 연결할 수 있는 경우 이를 사용하여 파이프라인을 실행할 수 있습니다. 그렇지 않으면 온-프레미스 서버에 액세스하고 코드를 가져올 수 있는 자체 호스팅 에이전트를 설정해야 합니다.

Azure Pipelines에서 연결할 수 있습니다.

가장 먼저 검사 것은 Azure Pipelines 서비스에서 GitHub Enterprise Server에 연결할 수 있는지 여부입니다.

  1. Azure DevOps UI에서 프로젝트 설정으로 이동하고 파이프라인에서 서비스 커넥트을 선택합니다.
  2. 새 서비스 연결을 선택하고 연결 유형으로 GitHub Enterprise Server를 선택합니다.
  3. GitHub Enterprise Server에 대한 연결을 만드는 데 필요한 정보를 입력합니다.
  4. 서비스 연결 패널에서 확인을 선택합니다.

확인이 통과하면 Azure Pipelines 서비스를 실행하는 서버가 온-프레미스 GitHub Enterprise Server에 연결할 수 있습니다. 계속 진행하여 연결을 설정할 수 있습니다. 그런 다음 클래식 빌드 또는 YAML 파이프라인을 만들 때 이 서비스 연결을 사용할 수 있습니다. 파이프라인에 대한 CI 및 PR 트리거를 구성할 수도 있습니다. GitHub와 함께 작동하는 Azure Pipelines의 대부분의 기능은 GitHub Enterprise Server에서도 작동합니다. GitHub에 대한 설명서를 검토하여 이러한 기능을 이해합니다. 다음은 몇 가지 차이점입니다.

  • GitHub 마켓플레이스의 Azure Pipelines 앱을 통해 GitHub와 Azure Pipelines 간의 통합이 더 쉬워집니다. 이 앱을 사용하면 특정 사용자의 OAuth 토큰을 사용하지 않고도 통합을 설정할 수 있습니다. GitHub Enterprise Server에서 작동하는 유사한 앱이 없습니다. 따라서 PAT, 사용자 이름 및 암호 또는 OAuth를 사용하여 Azure Pipelines와 GitHub Enterprise 서버 간의 연결을 설정해야 합니다.
  • Azure Pipelines는 외부 포크에서 기여 유효성을 검사하는 여러 GitHub 보안 기능을 지원합니다. 예를 들어 파이프라인에 저장된 비밀은 실행 중인 작업에 사용할 수 없습니다. GitHub Enterprise 서버로 작업할 때는 이러한 보호를 사용할 수 없습니다.
  • GitHub Enterprise 서버에서는 주석 트리거를 사용할 수 없습니다. GitHub Enterprise 서버 리포지토리 끌어오기 요청에서 주석을 사용하여 파이프라인을 트리거할 수 없습니다.
  • GitHub Enterprise 서버에서는 GitHub 검사를 사용할 수 없습니다. 모든 상태 업데이트는 기본 상태 통해 제공됩니다.

Azure Pipelines에서 연결할 수 없음

위 섹션에 설명된 대로 GitHub Enterprise Server 연결 확인에 실패하면 Azure Pipelines가 서버와 통신할 수 없습니다. 이는 엔터프라이즈 네트워크를 설정하는 방법 때문에 발생할 수 있습니다. 예를 들어 네트워크의 방화벽으로 인해 외부 트래픽이 서버에 도달하지 못할 수 있습니다. 이 경우 두 가지 옵션이 있습니다.

  • IT 부서와 협력하여 Azure Pipelines와 GitHub Enterprise Server 간에 네트워크 경로를 엽니다. 예를 들어 Azure Pipelines의 트래픽이 통과할 수 있도록 방화벽 규칙에 예외를 추가할 수 있습니다. 허용해야 하는 IP 주소를 보려면 Azure DevOps IP의 섹션을 참조하세요. 또한 Azure Pipelines가 서버의 FQDN을 IP 주소로 확인할 수 있도록 GitHub Enterprise Server에 대한 공용 DNS 항목이 있어야 합니다. 이러한 모든 변경 내용을 사용하여 Azure Pipelines에서 GitHub Enterprise Server 연결을 만들고 확인합니다.

  • GitHub Enterprise Server 연결을 사용하는 대신 다른 Git 연결을 사용할 수 있습니다. Azure Pipelines에서 이 Git 서버에 액세스하는 옵션을 검사 제거해야 합니다. 이 연결 형식을 사용하면 클래식 빌드 파이프라인만 구성할 수 있습니다. 이 구성에서는 CI 및 PR 트리거가 작동하지 않습니다. 수동 또는 예약된 파이프라인 실행만 시작할 수 있습니다.

Microsoft 호스팅 에이전트에서 연결할 수 있습니다.

Microsoft 호스팅 에이전트 또는 자체 호스팅 에이전트를 사용하여 파이프라인을 실행할지 여부를 결정해야 할 수도 있습니다. 이는 종종 Microsoft 호스팅 에이전트가 서버에 연결할 수 있는지 여부에 따라 달라집니다. 가능한지 여부를 검사 위해 Microsoft 호스팅 에이전트를 사용하는 간단한 파이프라인을 만들고 서버에서 소스 코드를 검사 단계를 추가해야 합니다. 이 경우 Microsoft 호스팅 에이전트를 계속 사용할 수 있습니다.

Microsoft 호스팅 에이전트에서 연결할 수 없음

위의 섹션에서 멘션 간단한 테스트 파이프라인이 오류TF401019: The Git repository with name or identifier <your repo name> does not exist or you do not have permissions for the operation you are attempting와 함께 실패하면 Microsoft 호스팅 에이전트에서 GitHub Enterprise Server에 연결할 수 없습니다. 이는 이러한 서버의 트래픽을 차단하는 방화벽으로 인해 다시 발생할 수 있습니다. 이 경우 두 가지 옵션이 있습니다.

  • IT 부서와 협력하여 Microsoft 호스팅 에이전트와 GitHub Enterprise Server 간에 네트워크 경로를 엽니다. Microsoft 호스팅 에이전트의 네트워킹 섹션을 참조하세요.

  • 자체 호스팅 에이전트 또는 확장 집합 에이전트 사용으로 전환합니다. 이러한 에이전트는 네트워크 내에서 설정할 수 있으므로 GitHub Enterprise Server에 액세스할 수 있습니다. 이러한 에이전트는 Azure Pipelines에 대한 아웃바운드 연결만 필요합니다. 인바운드 연결에 대한 방화벽을 열 필요가 없습니다. GitHub Enterprise Server 연결을 만들 때 지정한 서버의 이름을 자체 호스팅 에이전트에서 확인할 수 있는지 확인합니다.

Azure DevOps IP 주소

Azure Pipelines는 GitHub Enterprise Server에 요청을 전송하여 다음을 수행합니다.

  • 파이프라인을 만드는 동안 리포지토리 목록 쿼리(클래식 및 YAML 파이프라인)
  • 파이프라인을 만드는 동안 기존 YAML 파일 찾기(YAML 파이프라인)
  • YAML 파일 체크 인(YAML 파이프라인)
  • 파이프라인을 만드는 동안 웹후크 등록(클래식 및 YAML 파이프라인)
  • YAML 파일 편집기 표시(YAML 파이프라인)
  • 실행 전에 템플릿 확인 및 YAML 파일 확장(YAML 파이프라인)
  • 마지막으로 예약된 실행(클래식 및 YAML 파이프라인) 이후 변경 내용이 있는지 확인합니다.
  • 최신 커밋에 대한 세부 정보를 가져오고 사용자 인터페이스(클래식 및 YAML 파이프라인)에 표시

YAML 파이프라인은 기본적으로 Azure Pipelines와 GitHub Enterprise Server 간의 통신이 필요하다는 것을 확인할 수 있습니다. 따라서 GitHub Enterprise Server가 Azure Pipelines에 표시되지 않는 경우 YAML 파이프라인을 설정할 수 없습니다.

다른 Git 연결을 사용하여 클래식 파이프라인을 설정하고, Azure Pipelines 서비스와 GitHub Enterprise Server 간의 통신을 사용하지 않도록 설정하고, 자체 호스팅 에이전트를 사용하여 코드를 빌드하면 성능이 저하됩니다.

  • 파이프라인을 만드는 동안 리포지토리의 이름을 수동으로 입력해야 합니다.
  • Azure Pipelines가 GitHub Enterprise Server에 웹후크를 등록할 수 없으므로 CI 또는 PR 트리거를 사용할 수 없습니다.
  • 변경 내용이 있는 경우에만 빌드 옵션과 함께 예약된 트리거를 사용할 수 없습니다.
  • 사용자 인터페이스에서 최신 커밋에 대한 정보를 볼 수 없습니다.

YAML 파이프라인을 설정하거나 클래식 파이프라인을 사용하여 환경을 향상하려는 경우 Azure Pipelines에서 GitHub Enterprise Server로의 통신을 사용하도록 설정하는 것이 중요합니다.

Azure DevOps의 트래픽이 GitHub Enterprise Server에 도달할 수 있도록 하려면 인바운드 연결에 지정된 IP 주소 또는 서비스 태그를 방화벽의 허용 목록에 추가합니다. ExpressRoute를 사용하는 경우 방화벽의 허용 목록에 ExpressRoute IP 범위도 포함해야 합니다.

제한 사항

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

FAQ

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

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

실패한 트리거

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

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

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

    Pipeline settings UI.

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

    Override YAML trigger from here.

  • 웹후크는 GitHub Enterprise에서 Azure Pipelines로 업데이트를 전달하는 데 사용됩니다. GitHub Enterprise에서 리포지토리의 설정으로 이동한 다음 웹후크로 이동합니다. 웹후크가 있는지 확인합니다. 일반적으로 푸시, pull_request 두 개의 웹후크가 표시됩니다. 그렇지 않은 경우 서비스 연결을 다시 만들고 새 서비스 연결을 사용하도록 파이프라인을 업데이트해야 합니다.

  • GitHub Enterprise에서 각 웹후크를 선택하고 사용자의 커밋에 해당하는 페이로드가 존재하고 Azure DevOps로 성공적으로 전송되었는지 확인합니다. Azure DevOps에 이벤트를 전달할 수 없는 경우 여기에 오류가 표시될 수 있습니다.

  • Azure Pipelines가 GitHub에서 알림을 받으면 GitHub에 연락하여 리포지토리 및 YAML 파일에 대한 자세한 정보를 가져오려고 합니다. GitHub Enterprise Server가 방화벽 뒤에 있는 경우 이 트래픽이 서버에 도달하지 못할 수 있습니다. Azure DevOps IP 주소를 참조하고 필요한 모든 IP 주소에 예외를 부여했는지 확인합니다. 이러한 IP 주소는 원래 예외 규칙을 설정했기 때문에 변경되었을 수 있습니다.

  • 파이프라인이 일시 중지되거나 비활성화되어 있나요? 파이프라인에 대한 편집기를 연 다음 설정 선택하여 검사. 파이프라인이 일시 중지되거나 비활성화된 경우 트리거가 작동하지 않습니다.

  • 올바른 분기에서 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 파이프라인을 로드하여 실행해야 하는지를 파악하고 각 새 파이프라인에 성능 저하가 발생합니다.
    • GitHub Enterprise Server 인스턴스의 프로비전이 미달되어 Azure Pipelines의 요청 처리 속도가 느려질 수 있습니다. GitHub Enterprise Server의 하드웨어 고려 사항에 대해 자세히 알아보세요.

실패 검사out

Microsoft 호스팅 에이전트를 사용합니까? 이 경우 이러한 에이전트가 GitHub Enterprise Server에 연결하지 못할 수 있습니다. 자세한 내용은 Microsoft 호스팅 에이전트에서 연결할 수 없음을 참조 하세요 .

잘못된 버전

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

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