준비 사항
- 권한 및 역할
- 사용자 기여 매핑을 위한 계정
알려진 문제
GitHub 리포지터리를 GitLab로 가져오기
리포지터리를 미러로 설정하고 파이프라인 상태 공유하기
Self-Managed 인스턴스의 가져오기 속도 향상
- Sidekiq 워커 수 증가
- GitHub Enterprise Cloud OAuth 앱을 사용하여 GitHub OAuth 활성화
가져온 데이터
- 브랜치 보호 규칙과 프로젝트 설정
- 공동 작업자 (멤버)
내부 네트워크의 GitHub Enterprise에서 가져오기
- 샘플 역방향 프록시 구성
문제 해결

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

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

GitLab 15.8에 도입된 것으로, GitLab은 더 이상 존재하지 않는 네임스페이스나 그룹을 자동으로 생성하지 않습니다. GitLab은 또한 네임스페이스나 그룹 이름이 사용 중이면 사용자의 개인 네임스페이스를 기본적으로 사용하지 않습니다.
GitLab 15.10에 도입된 것으로, Merge Request 전에 풀 요청 필요 - 지정된 액터가 필요한 풀 요청을 우회할 수 있음 브랜치 보호 규칙을 성공적으로 가져오기 위해 GitLab의 부모 그룹에 사용자를 추가할 필요가 더 이상 없습니다.

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

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

GitLab UI를 사용하여 GitHub 가져오기는 항상 github.com 도메인에서 가져옵니다. 만약 self-hosted GitHub Enterprise Server 도메인에서 가져오려면, GitLab Import API GitHub 엔드포인트를 사용하세요.

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

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

준비 사항

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

권한 및 역할

GitLab 16.0에 요구되는 개발자 역할 대신 Maintainer 역할과 함께 도입되었으며, GitLab 15.11.1 및 GitLab 15.10.5로 백포트되었습니다.

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

가져오기 대상인 GitHub 프로젝트에 액세스할 수 있어야 합니다.
가져오기 대상인 GitLab 그룹에서 적어도 Maintainer 역할을 가져야 합니다.

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

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

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

해당 리포지터리의 각 GitHub 작성자 및 지정된 사용자는 공개적으로 표시되는 이메일 주소를 가져야 합니다.
GitHub 사용자의 이메일 주소가 GitLab의 이메일 주소와 일치해야 합니다.
GitHub의 사용자 이메일 주소가 GitLab에서 두 번째 이메일 주소로 설정된 경우, 확인해야 합니다.

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

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

프로젝트 생성자가 이슈 및 Merge Request의 작성자 및 지정됨을 설정합니다. 프로젝트 생성자는 보통 가져오기 프로세스를 시작한 사용자입니다. 일부 설명 또는 메모가 있는 기여의 경우, 가져오기 도구가 기여를 최초로 생성한 사용자의 세부 정보로 텍스트를 수정합니다.
GitHub에서 Pull Request에 추가된 리뷰어 및 승인이 가져오기되지 않습니다. 이 경우, 가져오기 도구는 실제 리뷰 상태 및 승인을 GitLab의 Merge Request에 적용하지 않지만, 리뷰어를 추가한 코멘트가 생성됩니다.

알려진 문제

2017년 이전에 만들어진 GitHub Pull Request 코멘트(또는 GitLab에서의 diff notes)는 별도의 스레드로 가져오기됩니다. 이는 2017년 이전의 GitHub API가 in_reply_to_id를 포함하지 않기 때문에 발생합니다.
알려진 문제 때문에 GitHub Enterprise Server 인스턴스의 리포지터리에서의 Markdown 첨부 파일은 가져오기되지 않습니다.
알려진 문제 때문에 GitHub 자동 Merge을 사용한 프로젝트를 가져올 때, 가져온 GitLab 프로젝트에는 “unverified”로 레이블이 지정된 Merge 커밋이 있을 수 있습니다. 만약 커밋이 GitHub의 내부 GPG 키로 서명되었다면 GitLab는 여기에 문제가 있다고 볼 것 입니다.
GitLab은 2023년 05월 09일 이전에 개인 리포지터리에 업로드된 GitHub Markdown 이미지 첨부 파일을 가져올 수 없습니다. 만약 이 문제를 겪고, 문제를 해결하는 데 도움을 주고자 하며, 우리에게 샘플 리포지터리를 제공해 주시려면, issue 424046에 코멘트를 추가하면 연락 드리겠습니다.

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

시작하기 전에, GitHub 사용자를 GitLab 사용자에 매핑하려면 GitHub 사용자의 공개적으로 표시되는 이메일 주소와 일치하는 GitLab 이메일 주소가 있어야 합니다.

GitHub 사용자의 공개적으로 표시되는 이메일 주소와 일치하는 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를 사용하여 리포지터리를 가져올 수 있습니다.

이 방법은 GitHub 개인 액세스 토큰(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. 협업자를 가져오려는 선택적으로, 프로젝트에 Git LFS 파일이 있는 경우 read:org 범위를 선택합니다.
5. Generate token을 선택합니다.
왼쪽 사이드바에서 맨 위에 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 리포지터리를 가져오는 데 사용할 수 있습니다.
Self-hosted인 GitHub Enterprise Server에서 가져오는 데 사용할 수 있습니다.
UI에서 제공되지 않는 timeout_strategy 옵션을 설정하는 데 사용될 수 있습니다.

REST API는 GitLab 개인 액세스 토큰으로 인증이 제한됩니다.

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

GitHub 개인 액세스 토큰을 생성합니다. classic 개인 액세스 토큰만 지원됩니다.
1. https://github.com/settings/tokens/new로 이동합니다.
2. 노트 필드에 토큰 설명을 입력합니다.
3. repo scope를 선택합니다.
4. 선택 사항. 협력자를 가져오려면 또는 프로젝트에 Git LFS 파일이 있는 경우 read:org 스코프를 선택합니다.
5. 토큰 생성을 선택합니다.
GitLab REST API를 사용하여 GitHub 리포지터리를 가져옵니다.

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

GitLab 16.0에서 도입됨.

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 및 Self-Managed에서 활성화되었습니다.
개선된 가져오기 성능이 GitLab 16.11에서 일반적으로 제공되었습니다. 피처 플래그 ‘github_import_extended_events’가 제거되었습니다.

가능한 빠른 가져오기를 위해 다음 항목은 기본적으로 GitHub에서 가져오지 않습니다:

GitHub API의 제한 때문에 대략 30,000개 이상의 코멘트.
리포지터리 코멘트, 릴리스 포스트, 이슈 설명 및 풀 리퀘스트 설명에서의 Markdown 첨부 파일. 이미지, 텍스트 또는 바이너리 첨부 파일을 포함할 수 있습니다. 이러한 항목을 가져오지 않으면 GitHub에서 첨부 파일을 제거한 후 Markdown에서 첨부 파일 링크가 끊어집니다.

이러한 항목을 가져오도록 선택할 수 있지만, 이는 가져오는 시간을 크게 증가시킬 수 있습니다. 이러한 항목을 가져오려면 UI에서 해당 필드를 선택합니다:

대체 코멘트 가져오기 방법 사용. GitHub 프로젝트를 가져올 때 약 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 사본과 동기화할 수 있습니다.

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

만약 외부 리포지터리용 CI/CD를 사용하여 프로젝트를 가져오는 경우, 위의 기능 모두 자동으로 구성됩니다.

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

Self-Managed 인스턴스의 가져오기 속도 향상

이러한 단계에는 GitLab 서버의 관리자 액세스가 필요합니다.

Sidekiq 워커 수 증가

큰 프로젝트의 경우 모든 데이터를 가져오는 데 시간이 오래 걸릴 수 있습니다. 시간을 단축하기 위해 다음 큐를 처리하는 Sidekiq 워커의 수를 증가시킬 수 있습니다:

github_importer
github_importer_advance_stage

최적의 경험을 위해 이러한 큐를 처리하는 적어도 4개의 Sidekiq 프로세스(각각 CPU 코어 수와 동일한 수의 스레드를 실행)를 실행하는 것이 좋습니다. 또한 이러한 프로세스는 별도의 서버에서 실행하는 것이 좋습니다. 8코어에 4대의 서버가 있는 경우 예를 들어 병렬로 32개 객체(이슈 등)를 가져올 수 있습니다.

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

GitHub Enterprise Cloud OAuth 앱을 사용하여 GitHub OAuth 활성화

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

GitHub API 요청은 보통 시간당 5,000개의 요청 제한이 있습니다. 아래 단계를 따라 수행하면 더 높은 시간당 15,000개의 요청 제한을 얻어 전체 가져오기 시간을 단축시킬 수 있습니다.

필수 조건:

GitHub Enterprise Cloud 조직에 액세스할 수 있어야 합니다.
GitLab이 GitHub OAuth를 활성화하도록 구성되어 있어야 합니다.

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

GitHub에서 OAuth 앱을 생성합니다. OAuth 앱이 개인 GitHub 계정이 아닌 Enterprise Cloud 조직에 속해 있는지 확인하세요.
GitHub OAuth를 사용하여 프로젝트 가져오기를 수행합니다.
선택 사항. 기본적으로 모든 구성된 OAuth 제공자에 대해 로그인이 활성화되어 있습니다. GitHub OAuth를 가져오기에는 활성화하지만 GitLab에서 GitHub로 로그인할 수 없도록 하려면 GitHub로의 로그인 비활성화를 할 수 있습니다.

가져온 데이터

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

리포지터리 설명.
Git 리포지터리 데이터.
모든 프로젝트 브랜치.
오픈 풀 리퀘스트 관련 프로젝트의 포크 모든 브랜치. 닫힌 풀 리퀘스트가 아닙니다. 포크에서의 브랜치는 GH-SHA-username/pull-request-number/fork-name/branch와 같은 이름 구성으로 가져옵니다.
브랜치 보호 규칙. 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 대용량 파일 리포지터리 (LFS) 오브젝트.
풀 리퀘스트 리뷰.
풀 리퀘스트 지정된 리뷰어. GitLab 15.6에 도입되었습니다.
풀 리퀘스트 “Merge자” 정보.
풀 리퀘스트 코멘트 논의에서의 답글. GitLab 14.5에 도입되었습니다.
풀 리퀘스트 리뷰 코멘트 제안. GitLab 14.7에 도입되었습니다.
이슈 이벤트 및 풀 리퀘스트 이벤트. GitLab 15.4에 github_importer_issue_events_import 피처 플래그로 기본적으로 비활성화되어 있습니다. GitLab 15.5부터 추가 항목으로 가져올 수 있습니다. 이 피처 플래그는 사라졌습니다.

풀 리퀘스트 및 이슈에 대한 참조가 유지됩니다. 가져온 각 리포지터리는 시각화 수준을 유지하며, 시각화 수준이 제한될 경우 기본 프로젝트 시각화 수준으로 설정됩니다.

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

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

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

GitHub 규칙	GitLab 규칙	도입된 날짜
Merge 전에 대화 해결이 필요함 (프로젝트의 기본 브랜치)	모든 스레드가 해결되어야 함 프로젝트 설정	GitLab 15.5
Merge 전에 풀 리퀘스트가 필요함	푸시 및 머지할 권한이 있는 사람 없음 디렉터리에서 아무도 옵션	GitLab 15.5
서명된 커밋 필요 - 프로젝트의 기본 브랜치	Unsigned commits의 거부 GitLab 푸시 규칙	GitLab 15.5
힘 주입 허용 - 모두	보호된 브랜치 설정에서 강제 푸시 허용	GitLab 15.6
Merge 전에 풀 리퀘스트가 필요함 - 코드 소유자의 확인 필요	코드 소유자의 승인이 필요 브랜치 보호 설정	GitLab 15.6
Merge 전에 풀 리퀘스트가 필요함 - 지정된 사용자가 필요함	사용자 디렉터리: 보호된 브랜치 설정의 푸시 및 Merge할 권한이 허용된 사용자 디렉터리. Premium 구독하지 않은 경우, 푸시 및 Merge이 허용되는 사용자 디렉터리은 역할로 제한됩니다.	GitLab 15.8

GitHub 규칙 Merge 전에 상태 확인이 필요함을 외부 상태 확인에 매핑할 것이 이미 고려되었습니다. 그러나 기술적인 어려움으로 인해 프로젝트 가져오기 중에 GitLab으로 가져오지 않습니다. 여전히 외부 상태 확인을 매뉴얼으로 생성할 수 있습니다.

공동 작업자 (멤버)

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

이러한 GitHub 공동 작업자 역할은 이러한 GitLab 멤버 역할에 매핑됩니다:

GitHub 역할	매핑된 GitLab 역할
읽기	게스트
트리아지	리포터
쓰기	개발자
유지보수	관리자
관리	소유자

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

샘플 역방향 프록시 구성

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

간단함을 위해 이 스니펫에는 클라이언트와 프록시 간의 연결을 암호화하기 위한 구성이 포함되어 있지 않습니다. 그러나 보안상의 이유로 해당 구성을 포함해아 합니다. 샘플 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이 프로젝트 가져오기 프로세스를 중단하고 리포지터리를 매뉴얼으로 가져와야 합니다.

관리자는 다음과 같이 이전에 실패한 가져오기 프로세스를 매뉴얼으로 계속할 수 있습니다:

레일 콘솔을 엽니다.

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

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개의 노트 또는 차이 노트를 가져오는 것을 방지하는 제한이 있습니다. 이 한계에 도달하면 대신 GitHub API는 다음과 같은 오류를 반환합니다:

모든 사용자에게 빠른 API를 유지하기 위해이 리소스에 대한 페이지네이션은 제한됩니다. Link 응답 헤더에서 rel=last 링크 관계를 확인하여 얼마나 멀리 거슬러 올라갈 수 있는지 확인하십시오.

댓글이 많은 GitHub 프로젝트를 가져올 때, 대체 댓글 가져오기 방법 사용 추가 항목 가져오기 체크박스를 선택해야 합니다. 이 설정은 가져오기 프로세스에 더 많은 네트워크 요청을 필요로 하므로 가져오는 데 더 많은 시간이 걸립니다.

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 또는 이전 버전을 실행하고 프록시 뒤에 있는 Self-Managed 인스턴스는 github.com 또는 api.github.com의 DNS를 해석할 수 없습니다. 이 상황에서 GitLab 인스턴스는 가져오는 동안 GitHub에 연결에 실패하며, 로컬 요청을 위한 허용 디렉터리에 github.com 및 api.github.com 항목을 추가해야 합니다.

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

준비 사항

권한 및 역할

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

알려진 문제

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

GitHub OAuth 사용

GitHub 개인 액세스 토큰 사용

API 사용

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

추가 가져오기 항목 선택

가져올 리포지터리 선택

가져오기 상태 확인

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

Self-Managed 인스턴스의 가져오기 속도 향상

Sidekiq 워커 수 증가

GitHub Enterprise Cloud OAuth 앱을 사용하여 GitHub OAuth 활성화

가져온 데이터

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

공동 작업자 (멤버)

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

샘플 역방향 프록시 구성

문제 해결

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

대형 프로젝트를 가져올 때의 오류

누락된 댓글

GitHub API 요청 오브젝트 수 줄이기

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

도움말

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

도움받기