GitHub에서 GitLab으로 프로젝트 가져오기

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated
  • GitLab 15.8에서 소개된 내용으로, 이제 GitLab은 존재하지 않는 네임스페이스 또는 그룹을 자동으로 생성하지 않습니다. 또한, 네임스페이스나 그룹 이름이 사용 중이면 더 이상 사용자의 개인 네임스페이스를 대체로 사용하지 않습니다.
  • GitLab 15.10에서 소개된 내용으로, GitLab에서는 필수 풀 리퀘스트가 Merge되기 전에 옵션 액터가 필수 풀 리퀘스트를 우회할 수 있도록 허용 브랜치 보호 규칙을 성공적으로 가져오려면 더 이상 상위 그룹에 사용자를 추가할 필요가 없습니다.

GitHub 프로젝트를 GitHub.com 또는 GitHub Enterprise에서 가져올 수 있습니다. 프로젝트를 가져오면 GitHub에서 GitLab으로 그룹이나 조직의 유형을 이동하거나 가져오지는 않습니다.

네임스페이스는 GitLab의 사용자나 그룹으로, gitlab.com/sidney-jones 또는 gitlab.com/customer-success와 같은 형태입니다.

GitLab UI를 사용하여 GitHub 가져오기 도구는 항상 github.com 도메인에서 가져옵니다. 만약 자체 호스팅된 GitHub Enterprise Server 도메인에서 가져올 경우 GitLab Import API의 GitHub 엔드포인트를 사용하세요.

가져오기 전에 대상 네임스페이스와 대상 리포지터리 이름을 변경할 수 있습니다.

가져오기 프로세스 개요는 GitHub에서 GitLab으로 마이그레이션하는 방법(액션 포함)를 참조하세요.

사전 요구 사항

GitHub에서 프로젝트를 가져오려면 GitHub 가져오기 소스를 활성화해야 합니다. 해당 가져오기 소스가 활성화되지 않은 경우 GitLab 관리자에게 활성화할 것을 요청하세요. GitHub 가져오기 소스는 기본적으로 GitLab.com에서 활성화되어 있습니다.

권한 및 역할

  • GitLab 16.0에서 Developer 역할 대신 Maintainer 역할이 요구사항으로 추가되었으며, 이 내용은 GitLab 15.11.1과 GitLab 15.10.5로 백포트되었습니다.

GitHub 가져오기 도구를 사용하기 위해 다음이 필요합니다:

  • 가져올 GitHub 프로젝트에 대한 액세스 권한
  • 가져오기할 대상 GitLab 그룹에서 적어도 Maintainer 역할이 필요합니다.

또한, GitHub 리포지터리가 속한 조직이 GitLab 인스턴스에 대한 타사 애플리케이션 액세스 정책을 제한해서는 안됩니다.

사용자 기여 매핑을 위한 계정

GitHub과 GitLab 간의 사용자 기여 매핑이 작업하려면:

  • 리포지터리 내의 각 GitHub 작성자와 지정된자는 공개적인 이메일 주소를 가져야 합니다.
  • GitHub 사용자의 이메일 주소가 GitLab의 이메일 주소와 일치해야 합니다.
  • GitHub에서 사용자의 이메일 주소가 GitLab에서 보조 이메일 주소로 설정된 경우, 확인해야 합니다.

GitHub Enterprise는 공개 이메일 주소를 필요로하지 않기 때문에 기존 계정에 추가해야 할 수도 있습니다.

위의 요구 사항을 충족하지 않으면 가져오기 도구가 특정 사용자의 기여를 매핑할 수 없습니다. 이 경우에는:

  • 프로젝트 생성자가 이슈 및 머지 요청의 작성자 및 지정자로 설정됩니다. 프로젝트 생성자는 보통 가져오기 프로세스를 시작한 사용자입니다. 풀 리퀘스트에 추가된 내용으로 각 기여를 생성한 사람의 세부 정보가 들어 있는 경우, 가져오기 도구가 생성한 기록에 원래 기여자의 세부 정보를 넣습니다.
  • GitHub에서 풀 리퀘스트에 추가된 리뷰어와 승인이 가져와지지 않습니다. 이 경우, 가져오기 도구는 존재하지 않는 사용자가 리뷰어와 승인자로 추가되었음을 설명하는 코멘트를 생성합니다. 그러나 실제 리뷰어 상태와 승인은 GitLab의 머지 요청에 적용되지 않습니다.

알려진 이슈

  • 2017년 이전에 만들어진 GitHub 풀 리퀘스트 코멘트(깃랩에서는 diff notes로 알려진 내용)는 별도의 스레드로 가져오집니다. 이는 2017년 이전의 코멘트에 대한 in_reply_to_id가 GitHub API에 포함되지 않는 제한 때문입니다.
  • GitHub Enterprise Server 인스턴스의 리포지터리에서 가져온 Markdown 첨부 파일이 가져와지지 않습니다. 이는 알려진 이슈 때문입니다.
  • GitHub 자동 머지를 사용한 프로젝트를 가져올 때, 가져온 GitLab 프로젝트에는 커밋이 “unverified”로 레이블이 지정될 수 있습니다. 이는 GitHub의 내장 GPG 키로 커밋이 서명된 경우에 해당합니다.

GitHub 리포지터리를 GitLab으로 가져오기

시작하기 전에, GitHub 사용자가 GitLab 사용자에 해당하는 GitLab 이메일 주소를 가지고 있는지 확인하세요. 공개적으로 표시되는 이메일 주소에 매치되는 GitLab 이메일 주소가 없는 경우, 사용자의 활동은 가져오기 작업을 수행하는 사용자 계정과 연관됩니다.

GitHub 리포지터리를 다음 중 하나로 가져올 수 있습니다:

github.com에서 가져올 경우 어떤 방법이든 사용할 수 있습니다. 자체 호스팅된 GitHub Enterprise Server는 API를 사용해야합니다.

GitHub OAuth 사용

GitLab.com 또는 GitHub OAuth가 구성된 자체 호스팅 GitLab로 가져오는 경우, GitHub OAuth를 사용하여 리포지터리를 가져올 수 있습니다.

이 방법은 GitHub 개인 액세스 토큰 (PAT) 사용보다 장점이 있는데, 백엔드가 적절한 권한을 가진 액세스 토큰을 교환하기 때문입니다.

  1. 왼쪽 사이드바에서 맨 위의 새로 만들기 ()를 선택하고 새로 만들기를 선택합니다.
  2. 프로젝트/리포지터리 만들기를 선택한 다음 프로젝트 가져오기와 GitHub을 선택합니다.
  3. GitHub로 승인을 선택하세요.
  4. 가져올 리포지터리 선택으로 이동하세요.

이러한 단계를 수행한 후 다른 방법으로 가져오기를 하려면, GitLab 계정에서 로그아웃한 후 다시 로그인하세요.

GitHub 개인 접근 토큰 사용

GitHub 개인 접근 토큰을 사용하여 GitHub 리포지터리를 가져오려면 다음을 수행하세요:

  1. GitHub 개인 접근 토큰 생성:
    1. https://github.com/settings/tokens/new로 이동합니다.
    2. 노트 필드에 토큰 설명을 입력합니다.
    3. repo 범위를 선택합니다.
    4. 선택 사항. 협력자 가져오기를 하려면 read:org 범위를 선택합니다.
    5. 토큰 생성을 선택합니다.
  2. GitLab 왼쪽 사이드바에서 상단에 있는 새로 만들기 () 및 새 프로젝트/리포지터리를 선택합니다.
  3. 프로젝트 가져오기를 선택한 다음 GitHub을 선택합니다.
  4. GitHub으로 승인을 선택합니다.
  5. 개인 접근 토큰 필드에 GitHub 개인 접근 토큰을 붙여넣습니다.
  6. 인증을 선택합니다.
  7. 가져올 리포지터리를 선택하러 이동합니다.

이전에 이러한 단계를 수행한 후 가져오기를 수행하려면 GitLab 계정에서 로그아웃한 후 다시 로그인하거나 GitHub에서 이전 토큰을 취소하십시오.

API 사용

GitLab REST API를 사용하여 GitHub 리포지터리를 가져올 수 있습니다. 이는 GitLab UI를 사용하는 것보다 몇 가지 장점이 있습니다:

  • 공개 리포지터리인 경우, 소유하지 않은 GitHub 리포지터리를 가져올 수 있습니다.
  • 자체 호스팅된 GitHub Enterprise Server에서 가져올 수 있습니다.
  • UI에서 제공되지 않는 timeout_strategy 옵션을 설정할 수 있습니다.

REST API는 GitLab 개인 접근 토큰을 사용한 인증으로 제한됩니다.

GitLab REST API를 사용하여 GitHub 리포지터리를 가져오려면:

  1. GitHub 개인 접근 토큰 생성:
    1. https://github.com/settings/tokens/new로 이동합니다.
    2. 노트 필드에 토큰 설명을 입력합니다.
    3. repo 범위를 선택합니다.
    4. 선택 사항. 협력자 가져오기를 하려면 read:org 범위를 선택합니다.
    5. 토큰 생성을 선택합니다.
  2. GitLab REST API를 사용하여 GitHub 리포지터리를 가져옵니다.

리포지터리 디렉터리 필터링

GitHub 리포지터리에 대한 액세스를 승인한 후 GitLab은 가져오기 페이지로 이동하고 GitHub 리포지터리가 디렉터리으로 표시됩니다.

다음 탭 중 하나를 사용하여 리포지터리 디렉터리을 필터링합니다:

  • 소유자 (기본): 소유자인 리포지터리 디렉터리을 필터링합니다.
  • 공동 작업: 기여한 리포지터리 디렉터리을 필터링합니다.
  • 조직: 소속된 조직의 리포지터리 디렉터리을 필터링합니다.

조직 탭이 선택된 경우, 사용 가능한 GitHub 조직을 드롭다운 디렉터리에서 선택하여 검색 범위를 좁힐 수 있습니다.

추가 가져올 항목 선택

  • GitLab 15.5에서 소개.
  • 협력자를 추가 가져오는 기능이 GitLab 16.0에서 소개.
  • 피처 플래그 github_import_extended_events는 GitLab 16.8에 도입되었습니다. 기본적으로 비활성화됩니다. 이 플래그는 가져오기의 성능을 향상시키지만 이슈 및 풀 리퀘스트 이벤트 가져오기 옵션을 제거합니다.
  • 피처 플래그 github_import_extended_events가 GitLab 16.9에서 GitLab.com 및 자체 호스팅에서 활성화되었습니다.

가능한 빠르게 가져오기를 수행하려면 기본적으로 GitHub에서 다음 항목은 가져오지 않습니다:

  • 이슈 및 풀 리퀘스트 이벤트. 예를 들어 오픈됨 또는 닫힘, 이름 변경, 라벨 지정 또는 제거.
  • GitHub API의 제한으로 인해, 약 30,000개 이상의 코멘트.
  • 리포지터리 코멘트, 릴리스 게시물, 이슈 설명 및 풀 리퀘스트 설명에서의 마크다운 첨부 파일. 이미지, 텍스트 또는 이진 첨부 파일을 포함할 수 있습니다. 가져오지 않으면 GitHub에서 첨부 파일을 제거한 후 마크다운의 링크가 깨질 수 있습니다.

이러한 항목을 가져올 수는 있지만 가져오기 시간이 크게 증가할 수 있습니다. 이러한 항목을 가져오려면 UI에서 적절한 필드를 선택하십시오:

  • 이슈 및 풀 리퀘스트 이벤트 가져오기. github_import_extended_events 피처 플래그가 활성화되어 있는 경우, 이 옵션을 사용할 수 없습니다.
  • 대체 코멘트 가져오기 방법 사용. 모든 이슈 및 풀 리퀘스트에서 약 30,000개 이상의 코멘트가 있는 경우 이 방법을 사용해야 합니다.
  • 마크다운 첨부 파일 가져오기
  • 협력자 가져오기 (기본 선택). 선택해 두면 그룹이나 이름공간에서 새로운 사용자가 좌석을 사용하거나 프로젝트 소유자 수준의 권한을 부여받을 수 있습니다. 직접 협력자만 가져옵니다. 외부 협력자는 가져오지 않습니다.

가져올 리포지터리 선택

  • 대기 중이거나 활성 상태인 가져오기를 취소하는 기능이 GitLab 15.7에서 소개.
  • 프로젝트를 다시 가져오는 기능이 GitLab 15.9에서 소개.

기본적으로 제안된 리포지터리 네임스페이스는 GitHub에 있는 것과 일치하지만 권한에 따라 계속하기 전에 이러한 이름을 편집할 수 있습니다.

가져올 리포지터리를 선택하려면 리포지터리 번호 옆에 가져오기 또는 모든 리포지터리 가져오기를 선택합니다.

또한 이름으로 프로젝트를 필터링할 수 있습니다. 필터가 적용된 경우 모든 리포지터리 가져오기는 일치하는 리포지터리만 가져옵니다.

상태 열에는 각 리포지터리의 가져오기 상태가 표시됩니다. 페이지를 계속 가지고 두고 실시간으로 업데이트를 보거나 나중에 돌아와도 됩니다.

대기 중이거나 진행 중인 가져오기를 취소하려면 가져올 프로젝트 옆에 취소를 선택합니다. 가져오기가 이미 시작된 경우 가져온 파일이 보관됩니다.

가져온 후에 GitLab URL에서 리포지터리를 열려면 해당 GitLab 경로를 선택합니다.

완료된 가져오기는 새 이름을 지정하여 재가져오기를 선택하여 다시 가져올 수 있습니다. 이렇게 하면 소스 프로젝트의 새 복사본이 생성됩니다.

GitHub 가져오기 페이지

Imports 상태 확인

  • 일부 완료된 imports의 세부 정보와 import에 실패한 엔터티 디렉터리은 GitLab 16.1에서 소개되었습니다.

imports의 완료 후, 다음 중 하나의 상태가 될 수 있습니다:

  • 완료: GitLab은 모든 리포지터리 엔터티를 가져왔습니다.
  • 일부 완료: GitLab은 일부 리포지터리 엔터티를 가져오지 못했습니다.
  • 실패: GitLab은 심각한 오류가 발생한 후 import를 중단했습니다.

세부 정보를 확장하여 리포지터리 엔터티를 import하지 못한 디렉터리을 확인하세요.

리포지터리를 미러링하고 파이프라인 상태 공유하기

Tier: Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

귀하의 GitLab 티어에 따라, 리포지터리 미러링은 귀하의 import된 리포지터리를 해당 GitHub 사본과 동기화하도록 설정할 수 있습니다.

추가로, GitLab을 구성하여 GitHub 프로젝트 통합으로 GitHub에 파이프라인 상태 업데이트를 보낼 수 있습니다.

만약 CI/CD for external repository를 사용하여 귀하의 프로젝트를 import했다면, 위의 두 가지가 자동으로 구성됩니다.

note
미러링은 GitHub 프로젝트의 새로운 또는 업데이트된 풀 리퀘스트를 동기화하지 않습니다.

Self-managed 인스턴스에서 import 속도 향상

이러한 단계를 수행하려면 GitLab 서버의 관리자 액세스가 필요합니다.

Sidekiq 워커 수 증가

대형 프로젝트의 경우 모든 데이터를 import하는 데 시간이 걸릴 수 있습니다. 필요한 시간을 줄이기 위해 다음 큐를 처리하는 Sidekiq 워커 수를 늘릴 수 있습니다:

  • github_importer
  • github_importer_advanced_stage

최적의 경험을 위해, 각각 CPU 코어 수와 같은 수의 스레드를 실행하는 적어도 4개의 Sidekiq 프로세스(각각의 큐를 만 처리하는)를 가지는 것이 좋습니다. 또한 이러한 프로세스가 각각 별도의 서버에서 실행되는 것이 좋습니다. 8개 코어가 있는 4개의 서버에 대해 말하면, 예를들어 이슈와 같은 32개의 객체를 병렬로 import할 수 있습니다.

리포지터리를 복제하는 데 걸리는 시간을 줄이려면 네트워크 처리량, CPU 용량, 그리고 디스크 성능(예: 고성능 SSD 사용)을 늘리는 것이 도움이 됩니다. Sidekiq 워커 수를 늘리는 것은 리포지터리 복제에 소요되는 시간을 줄이지 않습니다.

GitHub OAuth를 사용하여 GitHub OAuth 앱 활성화

GitHub Enterprise Cloud 조직에 속해 있다면, Self-managed GitLab 인스턴스를 구성하여 더 높은 GitHub API 요청 속도 제한을 얻을 수 있습니다.

일반적으로 GitHub API 요청은 1시간에 5,000개의 요청 속도로 제한됩니다. 아래 단계를 사용하여 더 높은 1시간에 15,000개의 요청 속도로 제한을 얻을 수 있으며, 전반적인 import 시간을 단축할 수 있습니다.

전제 조건:

보다 높은 요청 속도를 활성화하려면:

Imported data

프로젝트의 다음 항목이 import됩니다:

풀 리퀘스트 및 이슈에 대한 참조는 보존됩니다. 각 import된 리포지터리는 가시성 수준을 유지합니다. 가시성 수준이 제한된 경우, 기본 프로젝트 가시성으로 변경됩니다.

브랜치 보호 규칙 및 프로젝트 설정

이들이 가져올 때, 지원되는 GitHub 브랜치 보호 규칙은 다음 중 하나로 매핑됩니다:

  • GitLab 브랜치 보호 규칙.
  • 프로젝트 전반적인 GitLab 설정.
GitHub 규칙 GitLab 규칙 도입된 버전
프로젝트의 기본 브랜치에 Merge하기 전에 대화 해결이 필요합니다 모든 스레드가 해결되어야 함 프로젝트 설정 GitLab 15.5
Merge하기 전에 풀 리퀘스트가 필요합니다 브랜치 보호 설정의 밀어넣거나 Merge할 권한 디렉터리에서 아무도 옵션 GitLab 15.5
프로젝트의 기본 브랜치에 서명된 커밋이 필요합니다 GitLab 푸시 규칙에서 서명되지 않은 커밋 거부 GitLab 15.5
강제 푸시 허용 - 모두 브랜치 보호 설정의 강제 푸시 허용 GitLab 15.6
Merge하기 전에 풀 리퀘스트가 필요합니다 - 코드 소유자의 검토 필요 브랜치 보호 설정의 코드 소유자의 승인 필요 GitLab 15.6
Merge하기 전에 풀 리퀘스트가 필요합니다 - 특정 배우들이 필요한 풀 리퀘스트를 우회할 수 있습니다 브랜치 보호 설정의 밀어넣거나 Merge할 권한 디렉터리. Premium 구독 없이는, 푸시와 Merge이 허용된 사용자 디렉터리이 권한에 따라 제한됩니다. GitLab 15.8

GitHub 규칙 Merge하기 전에 상태 확인이 필요합니다를 외부 상태 확인에 매핑하는 것은 이슈 370948에서 고려되었습니다. 그러나 기술적 어려움으로 인해 이 규칙은 프로젝트 가져오기 중에 GitLab로 가져오지 않습니다. 그럼에도 불구하고, 외부 상태 확인을 매뉴얼으로 생성할 수 있습니다.

공동 작업자 (멤버)

이러한 GitHub 협업자 역할은 다음과 같은 GitLab 멤버 역할에 매핑됩니다:

GitHub 역할 매핑된 GitLab 역할
Read Guest
Triage Reporter
Write Developer
Maintain Maintainer
Admin Owner

GitHub Enterprise Cloud에는 사용자 지정 리포지터리 역할. 이러한 역할은 지원되지 않으며, 일부 완료되지 않은 가져오기를 야기시킵니다.

GitHub 협업자를 가져오려면 GitHub 프로젝트에서 쓰기 권한을 가져야 합니다. 그렇지 않으면 협업자 가져오기가 건너뛰어집니다.

내부 네트워크의 GitHub Enterprise에서 가져오기

GitHub Enterprise 인스턴스가 인터넷에 액세스할 수 없는 내부 네트워크에 있는 경우, GitLab.com이 인스턴스에 액세스할 수 있게 하려면 반대 프록시를 사용할 수 있습니다.

프록시는 다음과 같아야 합니다:

  • GitHub Enterprise 인스턴스로 요청을 전달합니다.
  • API 응답 본문에서 내부 호스트 이름의 모든 발생을 공용 프록시 호스트 이름으로 변환합니다.
  • API 응답 Link 헤더에서도 마찬가지로 작업합니다.

GitHub API는 페이지네이션에 Link 헤더를 사용합니다.

프록시를 구성한 후 API 요청을 하여 테스트합니다. 아래에는 API를 테스트하는 몇 가지 명령어 예제가 있습니다: 

curl --header "Authorization: Bearer <YOUR-TOKEN>" "https://{PROXY_HOSTNAME}/user"

### 응답 본문의 URL은 프록시 호스트 이름을 사용해야 합니다

{
  "login": "example_username",
  "id": 1,
  "url": "https://{PROXY_HOSTNAME}/users/example_username",
  "html_url": "https://{PROXY_HOSTNAME}/example_username",
  "followers_url": "https://{PROXY_HOSTNAME}/api/v3/users/example_username/followers",
  ...
  "created_at": "2014-02-11T17:03:25Z",
  "updated_at": "2022-10-18T14:36:27Z"
}

curl --head --header "Authorization: Bearer <YOUR-TOKEN>" "https://{PROXY_DOMAIN}/api/v3/repos/{repository_path}/pulls?states=all&sort=created&direction=asc"

### Link 헤더는 프록시 호스트 이름을 사용해야 함

HTTP/1.1 200 OK
Date: Tue, 18 Oct 2022 21:42:55 GMT
Server: GitHub.com
Content-Type: application/json; charset=utf-8
Cache-Control: private, max-age=60, s-maxage=60
...
X-OAuth-Scopes: repo
X-Accepted-OAuth-Scopes:
github-authentication-token-expiration: 2022-11-22 18:13:46 UTC
X-GitHub-Media-Type: github.v3; format=json
X-RateLimit-Limit: 5000
X-RateLimit-Remaining: 4997
X-RateLimit-Reset: 1666132381
X-RateLimit-Used: 3
X-RateLimit-Resource: core
Link: <https://{PROXY_DOMAIN}/api/v3/repositories/1/pulls?page=2>; rel="next", <https://{PROXY_DOMAIN}/api/v3/repositories/1/pulls?page=11>; rel="last"

또한 프록시를 사용하여 리포지터리를 클론하는 것이 실패하지 않음을 테스트합니다: 

git clone -c http.extraHeader="Authorization: basic <base64 encode YOUR-TOKEN>" --mirror https://{PROXY_DOMAIN}/{REPOSITORY_PATH}.git

샘플 Reverse Proxy 구성

다음 구성은 Apache HTTP Server를 역방향 프록시로 구성하는 방법에 대한 예시입니다.

caution
간단히 하기 위해 스니펫에는 클라이언트와 프록시 간의 연결을 암호화하는 구성이 없습니다. 그러나 보안상의 이유로 해당 구성을 포함해야 합니다. 샘플 Apache TLS/SSL 구성을 참조하십시오.
# 필수 모듈
LoadModule filter_module lib/httpd/modules/mod_filter.so
LoadModule reflector_module lib/httpd/modules/mod_reflector.so
LoadModule substitute_module lib/httpd/modules/mod_substitute.so
LoadModule deflate_module lib/httpd/modules/mod_deflate.so
LoadModule headers_module lib/httpd/modules/mod_headers.so
LoadModule proxy_module lib/httpd/modules/mod_proxy.so
LoadModule proxy_connect_module lib/httpd/modules/mod_proxy_connect.so
LoadModule proxy_http_module lib/httpd/modules/mod_proxy_http.so
LoadModule ssl_module lib/httpd/modules/mod_ssl.so

<VirtualHost GITHUB_ENTERPRISE_HOSTNAME:80>
  ServerName GITHUB_ENTERPRISE_HOSTNAME
  
  # SSL 지원을 통한 역방향 프록시 구성 활성화
  SSLProxyEngine On
  ProxyPass "/" "https://GITHUB_ENTERPRISE_HOSTNAME/"
  ProxyPassReverse "/" "https://GITHUB_ENTERPRISE_HOSTNAME/"
  
  # 로컬 GitHub Enterprise URL의 발생을 대체함
  # GitHub Enterprise은 응답을 압축하며, 응답을 압축 해제하고 다시 압축하기 위해 INFLATE 및 DEFLATE 필터를 사용해야 합니다
  AddOutputFilterByType INFLATE;SUBSTITUTE;DEFLATE application/json
  Substitute "s|https://GITHUB_ENTERPRISE_HOSTNAME|https://PROXY_HOSTNAME|ni"
  SubstituteMaxLineLength 50M
  
  # GitHub API는 응답 헤더 "Link"를 API 페이지네이션에 사용함
  # 예시:
  #   <https://example.com/api/v3/repositories/1/issues?page=2>; rel="next", <https://example.com/api/v3/repositories/1/issues?page=3>; rel="last"
  # 아래 지시문은 응답 헤더 Link가 있는 경우 GitHub Enterprise URL의 모든 발생을 Proxy URL로 대체함
  Header edit* Link "https://GITHUB_ENTERPRISE_HOSTNAME" "https://PROXY_HOSTNAME"
</VirtualHost>

문제 해결

이전에 실패한 가져오기 프로세스 매뉴얼으로 계속하기

일부 경우에는 GitHub 가져오기 프로세스가 리포지터리를 가져오지 못할 수 있습니다. 이로 인해 GitLab은 프로젝트 가져오기 프로세스를 중단시키고 리포지터리를 매뉴얼으로 가져와야 합니다. 시스템 관리자는 다음과 같이 이전에 실패한 가져오기 프로세스를 위해 리포지터리를 매뉴얼으로 가져올 수 있습니다:

  1. Rails 콘솔을 엽니다.

  2. 콘솔에서 다음 일련의 명령을 실행합니다: 

    project_id = <PROJECT_ID>
github_access_token =  <GITHUB_ACCESS_TOKEN>
github_repository_path = '<GROUP>/<REPOSITORY>'
   
github_repository_url = "https://#{github_access_token}@github.com/#{github_repository_path}.git"
   
# ID로 프로젝트 찾기
project = Project.find(project_id)
# 가져오기 URL 및 자격 증명 설정
project.import_url = github_repository_url
project.import_type = 'github'
project.import_source = github_repository_path
project.save!
# 프로젝트가 매뉴얼으로 생성되었고 가져오기 실패로부터의 경우 가져오기 상태 생성
project.create_import_state if project.import_state.blank?
# 상태를 시작으로 설정
project.import_state.force_start
   
# 선택 사항: 가져오기에 일부 선택적인 단계가 선택되었거나 시간 초과 전략이 설정된 경우 여기서 이를 재설정할 수 있습니다. 아래는 예시입니다.
# 매개변수는 API에서 문서화된 형식을 따릅니다:
# https://docs.gitlab.com/ee/api/import.html#import-repository-from-github
Gitlab::GithubImport::Settings
.new(project)
.write(
  timeout_strategy: "optimistic",
  optional_stages: {
    single_endpoint_issue_events_import: true,
    single_endpoint_notes_import: true,
    attachments_import: true,
    collaborators_import: true
  }
)
   
# 두 번째 단계에서 가져오기 트리거
Gitlab::GithubImport::Stage::ImportRepositoryWorker.perform_async(project.id)

대형 프로젝트를 가져올 때 발생하는 오류

누락된 댓글

GitHub API에는 약 30,000개의 노트 또는 diff 노트를 가져오는 것을 방지하는 제한이 있습니다. 이 제한에 도달하면 GitHub API는 대신 다음 오류를 반환합니다: 

모든 사용자에게 빠른 API를 유지하기 위해 이 리소스에 대한 페이지네이션을 제한합니다. 거칠 수 있는 마지막 링크 관계를 확인하려면 Link 응답 헤더에서 rel=last 링크 관계를 확인하세요.

댓글이 많은 GitHub 프로젝트를 가져올 경우 대체 댓글 가져오기 방법 사용 추가 가져오기 항목 확인란을 선택해야 합니다. 이 설정은 가져오기 프로세스가 더 오래 걸리게 할 수 있으며, 가져오기를 수행하는 데 필요한 네트워크 요청 수를 증가시킵니다.

GitHub API 요청 당 객체 수 줄이기

일부 GitHub API 엔드포인트는 대형 리포지터리에서 프로젝트 가져오기를 위해 500 또는 502 오류를 반환할 수 있습니다. 이러한 오류 발생 확률을 줄이려면 그룹 프로젝트에서 github_importer_lower_per_page_limit 피처 플래그를 활성화하세요. 이 플래그를 활성화하면 페이지 크기가 100에서 50으로 줄어듭니다.

이 피처 플래그를 활성화하려면 다음을 수행하세요:

  1. Rails 콘솔을 시작합니다.

  2. 다음 enable 명령을 실행하세요: 

    group = Group.find_by_full_path('my/group/fullpath')
   
# 활성화
Feature.enable(:github_importer_lower_per_page_limit, group)

이 피처 플래그를 비활성화하려면 다음 명령을 실행하세요: 

# 비활성화
Feature.disable(:github_importer_lower_per_page_limit, group)

GitLab 인스턴스가 GitHub에 연결할 수 없음

GitLab 15.10 이전에 실행되는 온프레미스 인스턴스는 프록시 뒤에 있을 때 github.com 또는 api.github.com의 DNS를 해석할 수 없을 수 있습니다. 이 상황에서 GitLab 인스턴스는 가져오기 중에 GitHub에 연결하지 못하며 로컬 요청을 위한 허용 디렉터리에 github.com 및 api.github.com 항목을 추가해야 합니다.