전제 조건
- 권한 및 역할
- 사용자 기여 매핑용 계정
알려진 문제
GitHub 리포지토리를 GitLab으로 가져오기
리포지토리를 미러로 설정하고 파이프라인 상태 공유
자체 호스팅된 인스턴스에서 가져오기 속도 향상
- Sidekiq 워커 수 증가
- GitHub OAuth를 사용하여 GitHub 엔터프라이즈 클라우드 OAuth 앱 활성화
가져온 데이터
- 브랜치 Protection 규칙 및 프로젝트 설정
- 협력자 (구성원)
내부 네트워크에 속한 GitHub 기업에서 가져오기
- 역방향 프록시 구성 샘플
문제 해결

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

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

GitLab 15.8에서 소개된 바에 의하면, 더 이상 자동으로 존재하지 않는 네임스페이스 또는 그룹을 생성하지 않습니다. GitLab은 또한 네임스페이스 또는 그룹 이름이 사용 중이라면 더 이상 사용자의 개인 네임스페이스를 기본값으로 사용하지 않습니다.
GitLab 15.10에서 소개된 바에 의하면, 병합 요청 전에 풀 리퀘스트를 필요로 함 - 지정된 사용자가 필요한 풀 리퀘스트를 우회할 수 있게 함 브랜치 보호 규칙을 성공적으로 가져오기 위해 GitLab의 상위 그룹에 사용자를 더 이상 추가할 필요가 없습니다.

GitHub 프로젝트를 GitHub.com 또는 GitHub Enterprise에서 가져올 수 있습니다. 프로젝트를 가져오면 GitHub의 어떠한 유형의 그룹이나 조직도 GitLab으로 마이그레이션되거나 가져오지 않습니다.

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

GitLab UI를 사용하여 GitHub 가져오기기능은 항상 github.com 도메인에서 가져옵니다. 만약 자체 호스팅된 GitHub Enterprise Server 도메인에서 가져오려면 GitLab 가져오기 API GitHub 엔드포인트를 사용하세요.

가져오기 전에 대상 네임스페이스와 대상 저장소 이름을 변경할 수 있습니다.

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

전제 조건

GitHub에서 프로젝트를 가져오려면 GitHub 가져오기 원본을 활성화해야 합니다. 해당 가져오기 원본이 활성화되지 않았다면 GitLab 관리자에게 활성화하도록 요청하세요. GitHub 가져오기 원본은 기본적으로 GitLab.com에서 활성화되어 있습니다.

권한 및 역할

GitLab 16.0에 도입된 Maintainer 역할의 필수성, 그리고 GitLab 15.11.1 및 GitLab 15.10.5에 백포트(backported)된 사항입니다.

GitHub 가져오기기능을 사용하려면 다음이 필요합니다:

가져오려는 GitHub 프로젝트에 대한 액세스 권한.
가져오기할 대상 GitLab 그룹에서 적어도 Maintainer 역할.

또한, GitHub 저장소가 속한 조직이 GitLab 인스턴스에 대해 제 3자 응용 프로그램 액세스 정책을 제한하지 않아야 합니다.

사용자 기여 매핑용 계정

GitHub 및 GitLab 간 사용자 기여 매핑을 위해:

저장소의 각 GitHub 작성자 및 담당자는 공개 이메일 주소가 있어야 합니다.
GitHub 사용자의 이메일 주소는 GitLab 이메일 주소와 일치해야 합니다.
GitHub에서 사용자의 이메일 주소가 GitLab의 보조 이메일 주소로 설정된 경우, 확인해야 합니다.

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

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

프로젝트 생성자가 이슈 및 병합 요청의 작성자 및 담당자로 설정됩니다. 프로젝트 생성자는 보통 가져오기 프로세스를 시작한 사용자입니다. 일부 설명 또는 노트가 있는 기여의 경우, 가져오기기능은 원래 기여를 생성한 사용자의 세부 정보로 텍스트를 보완합니다.
GitHub에서 pull request에 추가된 리뷰어 및 승인이 가져와지지 않습니다. 이 경우, 가져오기기능은 존재하지 않는 사용자가 리뷰어 및 승인자로 추가되었다는 코멘트를 생성합니다. 그러나 실제 리뷰어 상태 및 승인은 GitLab의 병합 요청에 적용되지 않습니다.

알려진 문제

2017년 이전에 생성된 GitHub pull request 코멘트(이를 GitLab에서는 diff notes라고 함)는 별도의 쓰레드로 가져와집니다. 이것은 2017년 이전의 코멘트에 대한 in_reply_to_id이 GitHub API에 포함되지 않는 제한 때문입니다.
GitHub Enterprise Server 인스턴스의 저장소에서 Markdown 첨부 파일은 가져오지 않습니다는 알려진 문제 때문입니다.
가져오기 수행시 GitHub 자동 병합을 사용한 프로젝트는 GitHub의 내부 GPG 키로 서명된 커밋이면 가져온 GitLab 프로젝트에 “unverified”로 레이블이 붙은 병합 커밋이 있을 수 있습니다는 알려진 문제 때문입니다.

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

시작하기 전에, GitHub 사용자를 GitLab 사용자와 매핑하려면 해당 GitHub 사용자가 GitHub의 publicly visible email address와 일치하는 GitLab 이메일 주소를 가져야 합니다.

GitHub 사용자의 public 이메일 주소가 GitLab 사용자 이메일 주소와 일치하지 않으면 사용자의 활동은 가져오기를 수행하는 사용자 계정과 연관됩니다.

GitHub 리포지토리를 가져오는 방법은 다음과 같습니다:

GitHub OAuth 사용
GitHub 개인 액세스 토큰 사용
API 사용

github.com에서 가져오는 경우에는 모든 방법을 사용할 수 있습니다. Self-hosted GitHub Enterprise Server 고객은 API를 사용해야 합니다.

GitHub OAuth 사용

GitLab.com이나 GitHub OAuth가 구성된 Self-managed GitLab으로 가져오는 경우, GitHub OAuth를 사용하여 리포지토리를 가져올 수 있습니다.

이 방법은 Personal Access Token (PAT)을 사용하는 것보다 백엔드가 적절한 권한으로 액세스 토큰을 교환하는 장점이 있습니다.

왼쪽 사이드바에서 위쪽에 있는 Create new(🌟)과 New project/repository를 선택합니다.
Import project를 선택한 다음 GitHub을 선택합니다.
Authorize with GitHub을 선택합니다.
가져올 리포지토리를 선택하십시오.

이 단계를 수행한 후에 다른 방법으로 가져오기를 원하는 경우, GitLab 계정에서 로그아웃한 후 다시 로그인하십시오.

GitHub 개인 액세스 토큰 사용

GitHub 개인 액세스 토큰을 사용하여 GitHub 리포지토리를 가져오려면:

GitHub 개인 액세스 토큰을 생성합니다:
1. https://github.com/settings/tokens/new로 이동합니다.
2. Note 필드에 토큰 설명을 입력합니다.
3. repo 스코프를 선택합니다.
4. 옵션. 협력자를 가져오려면, read:org 스코프를 선택합니다.
5. Generate token을 선택합니다.
GitLab 왼쪽 사이드바에서 위쪽에 있는 Create new(🌟)과 New project/repository를 선택합니다.
Import project를 선택한 다음 GitHub을 선택합니다.
Authorize with GitHub을 선택합니다.
Personal Access Token 필드에 GitHub 개인 액세스 토큰을 붙여넣습니다.
Authenticate를 선택합니다.
가져올 리포지토리를 선택하십시오.

이 단계를 수행한 후에 다른 토큰으로 가져오기를 원하는 경우, GitLab 계정에서 로그아웃한 후 다시 로그인하거나 GitHub에서 이전 토큰을 폐기하십시오.

API 사용

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

GitHub에서 소유권이 없는 GitHub 리포지토리를 가져올 수 있습니다(공개된 경우).
Self-hosted인 GitHub Enterprise Server에서 가져올 수 있습니다.
UI에서 사용할 수 없는 timeout_strategy 옵션을 설정할 수 있습니다.

REST API는 GitLab Personal Access Token으로만 인증할 수 있습니다.

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

GitHub 개인 액세스 토큰을 생성합니다:
1. https://github.com/settings/tokens/new로 이동합니다.
2. Note 필드에 토큰 설명을 입력합니다.
3. repo 스코프를 선택합니다.
4. 옵션. 협력자를 가져오려면, read:org 스코프를 선택합니다.
5. Generate token을 선택합니다.
GitLab REST API를 사용하여 GitHub 리포지토리를 가져옵니다.

리포지토리 목록 필터링

GitLab 16.0에서 도입되었습니다.

GitHub 리포지토리에 대한 액세스 권한을 승인한 후, GitLab은 가져오기 페이지로 리디렉션하고 GitHub 리포지토리가 나열됩니다.

리포지토리 목록을 필터링하려면 다음 탭 중 하나를 사용하십시오:

Owner(기본): 소유자가 되는 리포지토리를 필터링합니다.
Collaborated: 기여한 리포지토리를 필터링합니다.
Organization: 조직에 속한 리포지토리를 필터링합니다.

Organization 탭이 선택된 경우, 사용 가능한 GitHub 조직을 드롭다운 목록에서 선택하여 검색을 좁힐 수 있습니다.

추가 가져오기 항목 선택

GitLab 15.5에서 도입되었습니다.
협력자를 추가 항목으로 가져오는 것은 GitLab 16.0에서 도입되었습니다.
기능 플래그 github_import_extended_events가 GitLab 16.8에서 도입되었습니다. 기본적으로 비활성화되어 있습니다. 이 플래그는 가져오는 성능을 향상시키지만 이슈 및 풀 리퀘스트 이벤트 가져오기 옵션을 없애고 가져오기 주기적으로 많은 코멘트를 가져오는데 도움이 됩니다.
기능 플래그 github_import_extended_events가 GitLab 16.9에서 GitLab.com 및 Self-managed에 대해 활성화되었습니다.

가능한 빠르게 가져오기를 수행하기 위해 다음 항목은 GitHub로부터 기본적으로 가져오지 않습니다:

이슈 및 풀 리퀘스트 이벤트. 예를 들어, 열림(Opened) 또는 닫힘(Closed), 이름 변경(Renamed), 라벨 추가 또는 제거(Labeled or Unlabeled).
약 30,000개 이상의 코멘트, GitHub API의 제한 때문에.
리포지토리 코멘트, 릴리스 게시물, 이슈 설명 및 풀 리퀘스트 설명의 Markdown 첨부 파일. 이미지, 텍스트 또는 이진 첨부 파일을 포함할 수 있습니다. 가져오지 않으면 GitHub에서 첨부 파일을 제거한 후에 Markdown에서 첨부 파일에 대한 링크가 끊어집니다.

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

이슈 및 풀 리퀘스트 이벤트 가져오기. github_import_extended_events 기능 플래그가 활성화된 경우, 이 옵션이 사용할 수 없습니다.
대체 코멘트 가져오기 방법 사용. 모든 이슈와 풀 리퀘스트에서 약 30,000개 이상의 코멘트를 가져오는 경우, GitHub API의 제한 때문에 이 방법을 활성화해야 합니다.
Markdown 첨부 파일 가져오기.
협력자 가져오기 (기본으로 선택됨). 이것을 선택하면 그룹이나 이름 공간에서 새로운 사용자가 자리를 차지하거나 프로젝트 소유자만큼의 권한이 부여될 수 있습니다. 직접적인 협력자만 가져옵니다. 외부 협력자는 가져오지 않습니다.

가져올 리포지토리 선택

보류 중이거나 활성화 중인 가져오기를 취소할 수 있는 기능은 GitLab 15.7에서 도입되었습니다.
프로젝트를 다시 가져올 수 있는 기능은 GitLab 15.9에서 도입되었습니다.

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

가져올 리포지토리를 선택하려면 리포지토리 옆에 가져오기 또는 모든 리포지토리 가져오기를 선택하세요.

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

상태 열에는 각 리포지토리의 가져오기 상태가 표시됩니다. 페이지를 열어두고 실시간으로 업데이트를 확인하거나 나중에 돌아와서 확인할 수 있습니다.

보류 중이거나 진행 중인 가져오기를 취소하려면 가져온 프로젝트 옆에 취소를 선택하세요. 가져오기가 이미 시작된 경우, 가져온 파일이 유지됩니다.

가져온 후 GitLab URL에서 리포지토리를 열려면 해당 GitLab 경로를 선택하세요.

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

가져오기 상태 확인

부분적으로 완료된 가져오기의 세부 정보와 가져오기에 실패한 항목 목록은 GitLab 16.1에서 도입되었습니다.

가져오기가 완료된 후, 세 가지 상태 중 하나에 있을 수 있습니다:

완료: GitLab이 모든 리포지토리 항목을 가져왔습니다.
일부 완료: GitLab이 일부 리포지토리 항목을 가져오지 못했습니다.
실패: GitLab이 중대한 오류가 발생한 후 가져오기를 중단했습니다.

세부 정보를 확장하여 가져오지 못한 리포지토리 항목들의 목록을 볼 수 있습니다.

리포지토리를 미러로 설정하고 파이프라인 상태 공유

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

귀하의 GitLab 티어에 따라 리포지토리 미러링을 설정하여 가져온 리포지토리를 GitHub 사본과 동기화할 수 있습니다.

또한, GitHub 프로젝트 통합을 통해 GitLab에서 파이프라인 상태 업데이트를 GitHub에 다시 보낼 수 있습니다.

프로젝트를 외부 리포지토리용 CI/CD를 사용하여 가져오면 위의 두 가지가 자동으로 구성됩니다.

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

자체 호스팅된 인스턴스에서 가져오기 속도 향상

이러한 단계에 대해 관리자 액세스 권한을 가진 GitLab 서버가 필요합니다.

Sidekiq 워커 수 증가

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

github_importer
github_importer_advance_stage

최적의 경험을 위해 각각 CPU 코어 수와 동일한 스레드 수의 적어도 4개의 Sidekiq 프로세스를 가지는 것이 권장됩니다. 또한, 이러한 프로세스는 별도의 서버에서 실행하는 것이 좋습니다. 8코어를 가진 4대의 서버에서는 예를 들어 병렬로 최대 32개의 개체를 가져올 수 있습니다.

저장소를 복제하는 데 소요되는 시간을 줄이려면 네트워크 처리량, CPU 용량, 그리고 디스크 성능 (예: 고성능 SSD 사용)을 높여야 합니다. Sidekiq 워커 수를 늘리는 것은 저장소를 복제하는 데 소요되는 시간을 줄이지 않습니다.

GitHub OAuth를 사용하여 GitHub 엔터프라이즈 클라우드 OAuth 앱 활성화

만일 GitHub 엔터프라이즈 클라우드 조직에 속한다면, 자체 호스팅된 GitLab 인스턴스를 구성하여 더 높은 GitHub API 요청 제한을 얻을 수 있습니다.

GitHub API 요청은 일반적으로 시간당 5,000개의 요청 제한이 있습니다. 아래 단계를 사용하여 시간당 15,000개의 요청 제한을 얻어 전반적인 가져오기 시간을 단축할 수 있습니다.

전제 조건:

GitHub 엔터프라이즈 클라우드 조직에 액세스할 수 있어야 합니다.
GitLab이 GitHub OAuth를 활성화하도록 구성되어 있어야 합니다.

높은 요청 제한을 활성화하려면:

GitHub에서 OAuth 앱을 만듭니다. OAuth 앱이 개인 GitHub 계정이 아닌 엔터프라이즈 클라우드 조직 소유인지 확인하세요.
GitHub OAuth를 사용하여 프로젝트 가져오기를 수행하세요.
선택 사항. 기본적으로 모든 구성된 OAuth 공급자에 대해 로그인이 활성화됩니다. GitHub OAuth를 가져오기에는 활성화하고 GitLab 인스턴스로 GitHub로 로그인하는 기능을 방지하려면 GitHub으로 로그인 비활성화를 선택할 수 있습니다.

가져온 데이터

프로젝트의 다음 항목들이 가져옵니다.

저장소 설명.
Git 저장소 데이터.
모든 프로젝트 브랜치.
오픈 풀 리퀘스트에 관련된 프로젝트의 포크의 모든 브랜치(하지만 닫힌 풀 리퀘스트는 제외). 포크에서의 브랜치는 GH-SHA-username/pull-request-number/fork-name/branch와 유사한 네이밍 방식으로 가져옵니다.
브랜치 Protection 규칙. GitLab 15.4에서 도입됨.
협력자(멤버). GitLab 15.10에서 도입됨. GitLab 16.0부터는 추가 아이템으로 가져올 수 있습니다.
이슈.
풀 리퀘스트.
위키 페이지.
마일스톤.
레이블.
릴리스 노트 내용.
다음에 첨부된 항목:
- 릴리스 노트. GitLab 15.4에서 도입됨.
- 코멘트. GitLab 15.5에서 도입됨.
- 이슈 설명. GitLab 15.5에서 도입됨.
- 풀 리퀘스트 설명. GitLab 15.5에서 도입됨.
모든 첨부 항목 가져오기는 기본적으로 github_importer_attachments_import 기능 플래그로 비활성화됩니다. GitLab 15.5부터는 추가적인 항목으로 가져올 수 있습니다. 이 기능 플래그는 제거되었습니다.
풀 리퀘스트 리뷰 코멘트.
일반적인 이슈 및 풀 리퀘스트 코멘트.
Git Large File Storage (LFS) Objects.
풀 리퀘스트 리뷰.
풀 리퀘스트에 지정된 리뷰어. GitLab 15.6에서 도입됨.
풀 리퀘스트 “merged by” 정보.
풀 리퀘스트 코멘트 답글.
풀 리퀘스트 리뷰 코멘트 제안. GitLab 14.7에서 도입됨.
이슈 이벤트 및 풀 리퀘스트 이벤트. GitLab 15.4에서 github_importer_issue_events_import 기능 플래그로 기본적으로 비활성화된 상태로 소개. GitLab 15.5부터는 추가적인 항목으로 가져올 수 있습니다. 이 기능 플래그는 제거되었습니다.

풀 리퀘스트 및 이슈에 대한 참조가 유지됩니다. 각 가져온 저장소는 가시성 수준을 유지합니다. 제한된 가시성 수준인 경우 기본 프로젝트 가시성으로 기본 설정됩니다.

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

가져올 때, 지원되는 GitHub 브랜치 Protection 규칙은 다음 중 하나에 매핑됩니다:

GitLab 브랜치 Protection 규칙.
프로젝트 전체 GitLab 설정.

GitHub 규칙	GitLab 규칙	소개된 버전
Require conversation resolution before merging for the project’s default branch	프로젝트 설정의 모든 쓰레드가 해결되어야 함 All threads must be resolved	GitLab 15.5
Require a pull request before merging	브랜치 Protection 설정의 Allowed to push and merge 목록에서 No one 옵션	GitLab 15.5
Require signed commits for the project’s default branch	GitLab push rule의 Reject unsigned commits	GitLab 15.5
Allow force pushes - Everyone	브랜치 Protection 설정의 Allowed to force push	GitLab 15.6
Require a pull request before merging - Require review from Code Owners	브랜치 Protection 설정의 Require approval from code owners	GitLab 15.6
Require a pull request before merging - Allow specified actors to bypass required pull requests	브랜치 Protection 설정의 Allowed to push and merge 목록에 나열된 사용자 목록. Premium 구독 없이는 푸시 및 머지가 허용된 사용자 목록이 역할로 제한됩니다.	GitLab 15.8

GitHub 규칙 Require status checks to pass before merging을 외부 상태 확인으로 매핑하는 것은 370948 이슈에서 고려되었습니다. 하지만 이 규칙은 기술적 어려움으로 인해 GitLab으로 프로젝트 가져오는 동안 가져오지 않습니다. 여전히 외부 상태 확인을 수동으로 생성할 수 있습니다.

협력자 (구성원)

GitLab 15.10에서 소개되었습니다.

이 GitHub 협력자 역할은 다음과 같이 매핑됩니다. 이는 GitLab 구성원 역할에 해당됩니다:

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

GitHub Enterprise Cloud에는 사용자 지정 저장소 역할이 있습니다. 이러한 역할은 지원되지 않으며 부분적으로 완료된 가져오기를 유발합니다.

GitHub 협력자를 가져오려면 GitHub 프로젝트에 최소한 Write 역할이 있어야 합니다. 그렇지 않으면 협력자 가져오기가 건너뜁니다.

내부 네트워크에 속한 GitHub 기업에서 가져오기

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

역방향 프록시 구성 샘플

다음 구성은 Apache HTTP 서버를 역방향 프록시로 구성하는 예시입니다.

경고: 단순화를 위해 조각에는 클라이언트와 프록시 간의 연결을 암호화하는 구성이 없습니다. 그러나 보안상의 이유로 해당 구성을 포함해야 합니다. 샘플 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의 발생을 프록시 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는 API 페이지네이션을 위해 응답 헤더 "Link"를 사용합니다
  # 예:
  #   <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의 발생을 프록시 URL로 대체합니다
  Header edit* Link "https://GITHUB_ENTERPRISE_HOSTNAME" "https://PROXY_HOSTNAME"
</VirtualHost>

문제 해결

이전에 실패한 가져오기 프로세스 수동으로 계속하기

일부 경우에는 GitHub 가져오기 프로세스가 리포지토리를 가져오지 못할 수 있습니다. 이로 인해 GitLab은 프로젝트 가져오기 프로세스를 중단시키고 리포지토리를 수동으로 가져와야 합니다. 관리자는 실패한 가져오기 프로세스에 대해 리포지토리를 수동으로 가져올 수 있습니다.

Rails 콘솔을 엽니다.

콘솔에서 다음 명령어 시리즈를 실행합니다:

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 가져오기 도구는 대용량 프로젝트를 가져올 때 오류가 발생할 수 있습니다.

코멘트 누락

GitHub API에는 약 30,000개 이상의 노트 또는 diff 노트를 가져오지 못하게 하는 제한이 있습니다. 이 한계에 도달하면 GitHub API는 대신 다음과 같은 오류를 반환합니다:

In order to keep the API fast for everyone, pagination is limited for this resource. Check the rel=last link relation in the Link response header to see how far back you can traverse.

코멘트가 많은 GitHub 프로젝트를 가져올 때는 Use alternative comments import method 추가 가져오기 항목 확인란을 선택해야 합니다. 이 설정은 가져오기 프로세스를 더 오래 실행시키지만 가져오기를 수행하는 데 필요한 네트워크 요청 수를 늘립니다.

페이지당 GitHub API 요청 객체 감소

일부 GitHub API 엔드포인트는 대형 리포지토리에서 프로젝트를 가져올 때 500 또는 502 오류를 반환할 수 있습니다. 이러한 오류의 가능성을 줄이려면 데이터를 가져올 그룹 프로젝트에서 github_importer_lower_per_page_limit 기능 플래그를 활성화하세요. 활성화되면 기능 플래그는 페이지 크기를 100에서 50으로 줄입니다.

이 기능 플래그를 활성화하려면:

Rails 콘솔을 시작합니다.

다음 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에 연결에 실패하고 로컬 요청을 위한 allowlist에 github.com 및 api.github.com 항목을 추가해야 합니다.

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

전제 조건

권한 및 역할

사용자 기여 매핑용 계정

알려진 문제

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

GitHub OAuth 사용

GitHub 개인 액세스 토큰 사용

API 사용

리포지토리 목록 필터링

추가 가져오기 항목 선택

가져올 리포지토리 선택

가져오기 상태 확인

리포지토리를 미러로 설정하고 파이프라인 상태 공유

자체 호스팅된 인스턴스에서 가져오기 속도 향상

Sidekiq 워커 수 증가

GitHub OAuth를 사용하여 GitHub 엔터프라이즈 클라우드 OAuth 앱 활성화

가져온 데이터

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

협력자 (구성원)

내부 네트워크에 속한 GitHub 기업에서 가져오기

역방향 프록시 구성 샘플

문제 해결

이전에 실패한 가져오기 프로세스 수동으로 계속하기

대용량 프로젝트 가져오기 시 오류

코멘트 누락

페이지당 GitHub API 요청 객체 감소

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

도움말

기능 사용 가능성과 제품 평가판

도움받기