히스토리

• Imported badge introduced in GitLab 17.2.

GitHub.com 또는 GitHub Enterprise에서 GitHub 프로젝트를 임포트할 수 있습니다. 프로젝트 임포트는 GitHub에서 GitLab으로 어떤 유형의 그룹이나 조직도 마이그레이션하거나 임포트하지 않습니다.

임포트된 이슈, 머지 리퀘스트, 댓글, 이벤트는 GitLab에서 임포트됨 배지가 있습니다.

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

GitLab UI를 사용하면 GitHub 임포터는 항상 github.com 도메인에서 임포트합니다. 자체 호스팅된 GitHub Enterprise Server 도메인에서 임포트하는 경우 api 범위가 있는 GitLab 액세스 토큰과 함께 임포트 API GitHub 엔드포인트를 사용하세요.

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

임포트 프로세스에 대한 개요를 보려면 액션을 포함하여 GitHub에서 GitLab으로 마이그레이션하는 방법을 참조하세요.

임포트 기간 예상#

GitHub에서의 모든 임포트는 다르므로 수행하는 임포트의 기간에 영향을 미칩니다. 그러나 테스트에서 GitLab은 76시간 만에 https://github.com/kubernetes/kubernetes를 임포트했습니다. 테스트에서 프로젝트는 다음으로 구성되어 있었습니다:

• 80,000개의 풀 리퀘스트.
• 45,000개의 이슈.
• 약 150만 개의 댓글.

사전 요구 사항#

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

권한 및 역할#

GitHub 임포터를 사용하려면:

• 소스 GitHub 프로젝트에 대한 액세스 권한
• 대상 GitLab 그룹에 대한 유지 관리자 또는 소유자 역할 (GitLab 16.0에서 도입)

또한 GitHub 저장소가 속한 조직은 임포트할 GitLab 인스턴스에 대한 타사 애플리케이션 액세스 정책의 제한을 부과해서는 안 됩니다.

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

히스토리

• Preparation requirement removed on GitLab.com in GitLab 17.8.

알려진 문제#

• 2017년 이전에 생성된 GitHub 풀 리퀘스트 댓글(GitLab에서 차이 노트로 알려진)은 별도의 스레드로 임포트됩니다. 이는 2017년 이전의 댓글에 대해 in_reply_to_id를 포함하지 않는 GitHub API의 제한 때문입니다.

• GitLab 18.3 이하에서, GitHub Enterprise Server 인스턴스 저장소의 Markdown 첨부 파일은 임포트되지 않습니다. GitLab 18.4 이상에서:

  • Markdown 첨부 파일의 동영상 및 이미지 파일만 임포트됩니다.
  • 다른 파일 첨부 파일은 임포트되지 않습니다.

• 알려진 문제 때문에 GitHub 자동 머지를 사용한 프로젝트를 임포트할 때, 커밋이 GitHub 내부 GPG 키로 서명된 경우 GitLab의 임포트된 프로젝트에 unverified로 표시된 머지 커밋이 있을 수 있습니다.

• GitLab은 2023-05-09 이전에 비공개 저장소에 업로드된 GitHub Markdown 이미지 첨부 파일을 임포트할 수 없습니다. 이 문제가 발생하고 샘플 저장소를 제공할 의향이 있으면 이슈 424046에 댓글을 추가하면 GitLab이 연락드립니다.

• GitLab 특정 참조의 경우, GitLab은 이슈에 # 문자를, 머지 리퀘스트에 ! 문자를 사용합니다. 그러나 GitHub는 이슈와 풀 리퀘스트 모두에 # 문자만 사용합니다. 임포트 시:

  • 댓글 노트의 경우 GitLab은 이슈에 대한 링크만 생성합니다. GitLab이 참조가 이슈를 가리키는지 머지 리퀘스트를 가리키는지 결정할 수 없기 때문입니다.
  • 이슈 또는 머지 리퀘스트 설명의 경우, GitLab은 임포트된 대응물이 대상에서 아직 생성되지 않았을 수 있으므로 어떤 참조에 대해서도 링크를 만들지 않습니다.

• SAML 싱글 사인온(SSO)이 활성화된 GitHub 계정에서 임포트할 때 Markdown 첨부 파일이 임포트에 실패할 수 있습니다. 이 문제는 SSO가 적용될 때 개인 액세스 토큰을 사용하여 자산을 다운로드할 수 없는 GitHub API 제한으로 인해 발생합니다. 이 문제를 해결하려면 임포트를 수행하는 GitLab 사용자를 GitHub 저장소에 외부 협업자로 추가하세요. 이를 통해 임포트 중에 비공개 첨부 파일에 액세스할 수 있습니다.

GitHub 저장소를 GitLab으로 임포트#

GitHub 저장소는 다음 방법으로 임포트할 수 있습니다:

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

github.com에서 임포트하는 경우 어떤 방법이든 사용할 수 있습니다. 자체 호스팅 GitHub Enterprise Server 고객은 API를 사용해야 합니다.

GitHub OAuth 사용#

GitLab.com으로 임포트하거나 GitHub OAuth가 구성된 GitLab Self-Managed로 임포트하는 경우 GitHub OAuth를 사용하여 저장소를 임포트할 수 있습니다.

이 방법은 백엔드가 적절한 권한으로 액세스 토큰을 교환하기 때문에 개인 액세스 토큰(PAT) 사용보다 유리합니다.

1. 오른쪽 상단에서 새로 만들기 (+) 및 새 프로젝트/저장소를 선택합니다.
2. 프로젝트 임포트 및 GitHub를 선택합니다.
3. GitHub로 인증을 선택합니다.
4. 임포트할 저장소 선택으로 진행합니다.

이전에 이 단계를 수행한 후 다른 방법으로 임포트하려면 GitLab 계정에서 로그아웃하고 다시 로그인하세요.

GitHub 개인 액세스 토큰 사용#

GitHub 개인 액세스 토큰을 사용하여 GitHub 저장소를 임포트하려면:

1. GitHub 개인 액세스 토큰을 생성합니다. 클래식 개인 액세스 토큰만 지원됩니다.
   1. https://github.com/settings/tokens/new로 이동합니다.
   2. Note 필드에 토큰 설명을 입력합니다.
   3. repo 범위를 선택합니다.
   4. 선택 사항. 협업자를 임포트하거나 프로젝트에 Git LFS 파일이 있는 경우 read:org 범위를 선택합니다.
   5. Generate token을 선택합니다.
2. 오른쪽 상단에서 새로 만들기 (+) 및 새 프로젝트/저장소를 선택합니다.
3. 프로젝트 임포트 및 GitHub를 선택합니다.
4. GitHub로 인증을 선택합니다.
5. 개인 액세스 토큰 필드에 GitHub 개인 액세스 토큰을 붙여넣습니다.
6. 인증을 선택합니다.
7. 임포트할 저장소 선택으로 진행합니다.

이전에 이 단계를 수행한 후 다른 토큰으로 임포트하려면 GitLab 계정에서 로그아웃하고 다시 로그인하거나 GitHub에서 이전 토큰을 취소하세요.

API 사용#

임포트 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. Note 필드에 토큰 설명을 입력합니다.
   3. repo 범위를 선택합니다.
   4. 선택 사항. 협업자를 임포트하거나 프로젝트에 Git LFS 파일이 있는 경우 read:org 범위를 선택합니다.
   5. Generate token을 선택합니다.
2. 임포트 API를 사용하여 GitHub 저장소를 임포트합니다.

저장소 목록 필터링#

히스토리

• Introduced in GitLab 16.0.

GitHub 저장소에 대한 액세스를 인증한 후, GitLab은 임포터 페이지로 리디렉션하고 GitHub 저장소가 나열됩니다.

다음 탭 중 하나를 사용하여 저장소 목록을 필터링합니다:

• 소유자 (기본값): 소유자인 저장소로 목록을 필터링합니다.
• 협업: 기여한 저장소로 목록을 필터링합니다.
• 조직: 구성원인 조직에 속하는 저장소로 목록을 필터링합니다.

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

임포트할 추가 항목 선택#

히스토리

• Introduced in GitLab 16.8 with a flag named github_import_extended_events. Disabled by default.
• Enabled on GitLab.com, GitLab Self-Managed, and GitLab Dedicated in GitLab 16.9.
• Generally available in GitLab 16.11. Feature flag github_import_extended_events removed.

임포트를 최대한 빠르게 하기 위해 다음 항목은 기본적으로 GitHub에서 임포트되지 않습니다:

• GitHub API 제한으로 인해 약 30,000개 이상의 댓글.
• 저장소 댓글, 릴리스 게시물, 이슈 설명, 풀 리퀘스트 설명의 Markdown 첨부 파일. 이는 이미지, 텍스트 또는 바이너리 첨부 파일을 포함할 수 있습니다. 임포트되지 않으면 GitHub에서 첨부 파일을 제거한 후 첨부 파일의 Markdown 링크가 끊어집니다.

이러한 항목을 임포트하도록 선택할 수 있지만 이로 인해 임포트 시간이 크게 증가할 수 있습니다. 이러한 항목을 임포트하려면 UI에서 적절한 필드를 선택합니다:

• 대체 댓글 임포트 방법 사용. 모든 이슈와 풀 리퀘스트에 걸쳐 약 30,000개 이상의 댓글이 있는 GitHub 프로젝트를 임포트하는 경우 GitHub API 제한으로 인해 이 방법을 활성화해야 합니다.
• Markdown 첨부 파일 임포트.
• 협업자 임포트 (기본적으로 선택됨). 선택된 상태로 두면 새 사용자가 그룹이나 네임스페이스에서 좌석을 사용하고 프로젝트 소유자만큼 높은 권한을 부여받을 수 있습니다. 직접 협업자만 임포트됩니다. 외부 협업자는 절대 임포트되지 않습니다. GitLab 18.4 이상에서, 협업자를 임포트할 때 사용자를 이 그룹의 프로젝트에 추가할 수 없음 설정이 준수됩니다.

임포트할 저장소 선택#

기본적으로 제안된 저장소 네임스페이스는 GitHub에 존재하는 이름과 일치하지만, 권한에 따라 임포트 전에 이러한 이름을 편집하도록 선택할 수 있습니다.

임포트할 저장소를 선택하려면 여러 저장소 옆에 있는 임포트를 선택하거나 모든 저장소 임포트를 선택합니다.

또한 이름으로 프로젝트를 필터링할 수 있습니다. 필터가 적용된 경우 모든 저장소 임포트는 일치하는 저장소만 임포트합니다.

상태 열은 각 저장소의 임포트 상태를 보여줍니다. 페이지를 열어두고 실시간 업데이트를 볼 수도 있고 나중에 돌아올 수도 있습니다.

대기 중이거나 진행 중인 임포트를 취소하려면 임포트된 프로젝트 옆에서 취소를 선택합니다. 임포트가 이미 시작된 경우 임포트된 파일은 유지됩니다.

임포트된 후 GitLab URL에서 저장소를 열려면 GitLab 경로를 선택합니다.

완료된 임포트는 재임포트를 선택하고 새 이름을 지정하여 다시 임포트할 수 있습니다. 이렇게 하면 소스 프로젝트의 새 복사본이 만들어집니다.

임포트 상태 확인#

히스토리

• Details of partially completed imports with a list of entities that failed to import introduced in GitLab 16.1.

임포트가 완료된 후 세 가지 상태 중 하나일 수 있습니다:

• 완료: GitLab이 모든 저장소 엔터티를 임포트했습니다.
• 부분적으로 완료: GitLab이 일부 저장소 엔터티를 임포트하지 못했습니다.
• 실패: GitLab이 치명적인 오류가 발생한 후 임포트를 중단했습니다.

임포트에 실패한 저장소 엔터티 목록을 보려면 세부 사항을 펼칩니다.

사용자 이름 멘션#

히스토리

• Introduced in GitLab 17.5.

GitLab은 이슈, 머지 리퀘스트, 노트의 사용자 이름 멘션에 백틱을 추가합니다. 이 백틱은 GitLab 인스턴스에서 동일한 사용자 이름을 가진 잘못된 사용자로의 링크를 방지합니다.

사용자 기여 및 구성원 매핑#

히스토리

• Changed on GitLab.com to user contribution and membership mapping in GitLab 17.8.
• Enabled on GitLab.com, GitLab Self-Managed, and GitLab Dedicated in GitLab 17.8.

GitHub 임포터는 GitLab.com, GitLab Self-Managed, GitLab Dedicated에 대해 사용자 기여를 매핑하는 마이그레이션 후 방법을 사용합니다.

대체 매핑 방법#

GitLab 18.7 이하에서는 github_user_mapping 기능 플래그를 비활성화하여 임포트에 대한 대체 사용자 기여 매핑 방법을 사용할 수 있습니다.

요구 사항:

• 저장소의 각 GitHub 작성자 및 담당자는 공개 이메일 주소가 있어야 합니다. GitHub Enterprise는 공개 이메일 주소를 요구하지 않으므로 기존 계정에 추가해야 할 수도 있습니다.
• GitHub 사용자의 이메일 주소는 GitLab 이메일 주소와 일치해야 합니다.
• GitHub에서 사용자의 이메일 주소가 GitLab의 보조 이메일 주소로 설정된 경우 확인해야 합니다.

이 방법을 사용하면 사용자 계정이 올바르게 프로비저닝된 경우 사용자가 임포트 중에 매핑됩니다.

요구 사항이 충족되지 않으면 임포터가 해당 사용자의 기여를 매핑할 수 없습니다. 이 경우:

• 프로젝트 생성자가 이슈와 머지 리퀘스트의 작성자 및 담당자로 설정됩니다. 프로젝트 생성자는 일반적으로 임포트 프로세스를 시작한 사용자입니다. 풀 리퀘스트, 이슈, 노트와 같은 설명이나 노트가 있는 일부 기여의 경우 임포터는 원래 기여를 만든 사람에 대한 세부 사항으로 텍스트를 수정합니다.
• GitHub 풀 리퀘스트에 추가된 검토자 및 승인은 임포트할 수 없습니다. 이 경우 임포터는 존재하지 않는 사용자가 검토자 및 승인자로 추가되었음을 설명하는 댓글을 만듭니다. 그러나 실제 검토자 상태와 승인은 GitLab의 머지 리퀘스트에 적용되지 않습니다.

저장소 미러링 및 파이프라인 상태 공유#

GitLab 티어에 따라 저장소 미러링을 설정하여 임포트된 저장소를 GitHub 복사본과 동기화할 수 있습니다.

또한 GitHub 프로젝트 통합을 사용하여 파이프라인 상태 업데이트를 다시 GitHub로 보내도록 GitLab을 구성할 수 있습니다.

외부 저장소용 CI/CD를 사용하여 프로젝트를 임포트하면 두 기능이 자동으로 구성됩니다.

GitLab Self-Managed 인스턴스에서 임포트 속도 향상#

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

Sidekiq 작업자 수 늘리기#

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

• github_importer
• github_importer_advance_stage

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

저장소 복제에 소요되는 시간을 줄이려면 GitLab 인스턴스의 Git 저장소를 저장하는 디스크의 네트워크 처리량, CPU 용량, 디스크 성능(고성능 SSD 사용 등)을 높이면 됩니다. Sidekiq 작업자 수를 늘려도 저장소 복제에 소요되는 시간은 줄어들지 않습니다.

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

GitHub Enterprise Cloud 조직에 속해 있으면 GitLab Self-Managed를 구성하여 더 높은 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를 활성화하되 사용자가 GitHub로 GitLab 인스턴스에 로그인하는 기능을 방지하려면 GitHub로의 로그인을 비활성화할 수 있습니다.

임포트된 데이터#

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

• 오픈 풀 리퀘스트와 관련된 프로젝트의 모든 포크 브랜치

  [!note] 포크 브랜치는 GH-SHA-username/pull-request-number/fork-name/branch와 유사한 명명 체계로 임포트됩니다.

• 모든 프로젝트 브랜치

• 다음에 대한 첨부 파일:

  • 댓글
  • 이슈 설명
  • 풀 리퀘스트 설명
  • 릴리스 노트

• 브랜치 보호 규칙

• 협업자(구성원)

• Git LFS 객체

• Git 저장소 데이터

• 이슈 및 풀 리퀘스트 댓글

• 이슈 및 풀 리퀘스트 이벤트 (추가 항목으로 임포트 가능)

• 이슈

• 레이블

• 마일스톤

• 풀 리퀘스트 할당된 검토자

• 풀 리퀘스트 머지 정보

• 풀 리퀘스트 리뷰

• 풀 리퀘스트 리뷰 댓글

• 풀 리퀘스트 리뷰의 토론 답글

• 풀 리퀘스트 리뷰 제안

• 풀 리퀘스트

• 릴리스 노트 내용

• 저장소 설명

• 위키 페이지

풀 리퀘스트와 이슈에 대한 참조는 보존됩니다. 임포트된 각 저장소는 해당 공개 여부 수준이 제한되지 않는 한 공개 여부 수준을 유지하며, 제한된 경우 기본 프로젝트 공개 여부로 기본값이 설정됩니다.

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

임포트된 GitHub 브랜치 보호 규칙은 다음 중 하나에 매핑됩니다:

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

머지 전에 상태 확인 통과 요구 GitHub 규칙은 임포트되지 않습니다. 수동으로 외부 상태 확인을 만들 수 있습니다. 자세한 내용은 이슈 370948을 참조하세요.

협업자(구성원)#

히스토리

• Importing collaborators as an additional item introduced in GitLab 16.0.

다음 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 " "https://{PROXY_HOSTNAME}/user"

### URLs in the response body should use the proxy hostname

{
  "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 " "https://{PROXY_DOMAIN}/api/v3/repos/{repository_path}/pulls?states=all&sort=created&direction=asc"

### Link header should use the proxy hostname

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를 역방향 프록시로 구성하는 방법의 예입니다

# Required modules
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


  ServerName GITHUB_ENTERPRISE_HOSTNAME

  # Enables reverse-proxy configuration with SSL support
  SSLProxyEngine On
  ProxyPass "/" "https://GITHUB_ENTERPRISE_HOSTNAME/"
  ProxyPassReverse "/" "https://GITHUB_ENTERPRISE_HOSTNAME/"

  # Replaces occurrences of the local GitHub Enterprise URL with the Proxy URL
  # GitHub Enterprise compresses the responses, the filters INFLATE and DEFLATE needs to be used to
  # decompress and compress the response back
  AddOutputFilterByType INFLATE;SUBSTITUTE;DEFLATE application/json
  Substitute "s|https://GITHUB_ENTERPRISE_HOSTNAME|https://PROXY_HOSTNAME|ni"
  SubstituteMaxLineLength 50M

  # GitHub API uses the response header "Link" for the API pagination
  # For example:
  #   <https://example.com/api/v3/repositories/1/issues?page=2>; rel="next", <https://example.com/api/v3/repositories/1/issues?page=3>; rel="last"
  # The directive below replaces all occurrences of the GitHub Enterprise URL with the Proxy URL if the
  # response header Link is present
  Header edit* Link "https://GITHUB_ENTERPRISE_HOSTNAME" "https://PROXY_HOSTNAME"
</VirtualHost>

관련 항목#

• 임포트 및 내보내기 설정.
• 임포트를 위한 Sidekiq 구성.
• 여러 Sidekiq 프로세스 실행.
• 특정 작업 클래스 처리.