직접 이전을 사용하여 GitLab 그룹 및 프로젝트 이전하기

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated
  • GitLab 13.7에서 소개, 기본적으로 사용하지 않는 bulk_import이라는 플래그를 통해 그룹 리소스에 대한 이전이 가능해졌습니다.
  • 그룹 아이템은 GitLab 14.3에서 GitLab.com 및 자체 관리로 활성화되었습니다.
  • GitLab 14.4에서 프로젝트 리소스에 대해, 기본적으로 사용하지 않는 bulk_import_projects라는 플래그를 통해 이전이 가능하게 되었습니다.
  • GitLab 15.6에서 GitLab.com에서 활성화되었습니다.
  • GitLab 15.8에서 새로운 응용 프로그램 설정 bulk_import_enabled소개되었습니다. bulk_import 기능 플래그가 제거되었습니다.
  • GitLab 15.10에서 bulk_import_projects 기능 플래그가 제거되었습니다.

GitLab 그룹을 다음과 같이 이전할 수 있습니다:

  • 자체 관리 GitLab에서 GitLab.com으로.
  • GitLab.com에서 자체 관리 GitLab으로.
  • 하나의 자체 관리 GitLab 인스턴스에서 다른 인스턴스로.
  • 동일한 GitLab 인스턴스 내의 그룹 간.

두 가지 방법으로 그룹을 이전할 수 있습니다:

GitLab.com에서 자체 관리 GitLab으로 이전하는 경우, 관리자는 자체 관리 GitLab 인스턴스에서 사용자를 생성할 수 있습니다.

자체 관리 GitLab에서는 기본적으로 그룹 아이템의 이전을 사용할 수 없습니다. 이 기능을 표시하려면 관리자가 응용 프로그램 설정에서 활성화할 수 있습니다.

직접 전송을 통해 그룹을 이전하면 해당 그룹을 한 곳에서 다른 곳으로 복사할 수 있습니다. 다음을 수행할 수 있습니다:

  • 한 번에 여러 그룹 복사.
  • GitLab UI에서 최상위 그룹을 다른 최상위 그룹또는 기존 최상위 그룹의 하위 그룹 또는 다른 GitLab 인스턴스(포함하여 GitLab.com)로 복사.
  • API를 통해 최상위 그룹 및 하위 그룹을 이러한 위치로 복사.
  • 프로젝트와 함께 그룹 복사(베타) 또는 프로젝트 없이 그룹 복사. 프로젝트와 함께 그룹 복사는 다음에서 사용 가능합니다:
    • 기본적으로 GitLab.com에서.

모든 그룹 및 프로젝트 리소스가 복사되는 것은 아닙니다. 아래 목록에서 복사된 리소스를 확인하세요:

경고: 프로젝트가 포함된 그룹을 가져오는 것은 베타 상태입니다. 이 기능은 실제 운영에 사용하기에 적합하지 않습니다.

우리는 당신이 직접 전송을 통해 이전하는데 대한 피드백을 피드백 이슈에 남기도록 초대합니다.

그룹을 복사하는 대신 이동하려면, 만약 그룹이 동일한 GitLab 인스턴스에 있는 경우 그룹을 전송할 수 있습니다. 그룹을 전송하는 것이 더 빠르고 완전한 옵션입니다.

알려진 문제

  • 문제 406685 때문에 파일 이름이 255자보다 긴 파일은 이전되지 않습니다.
  • GitLab 16.1 이전에는 예약된 스캔 실행 정책을 사용하지 마십시오.
  • 다른 알려진 문제 목록은 에픽 6629을 참조하세요.
  • GitLab 16.9 이전에는 문제 438422로 인해 DiffNote::NoteDiffFileCreationError 오류가 발생할 수 있습니다. 이 오류가 발생하면 병합 요청의 차이가 없지만, 노트와 병합 요청은 여전히 가져와집니다.

이전 기간 추정

직접 전송을 통한 이전 기간을 정확하게 추정하는 것은 어렵습니다. 다음과 같은 요소가 이전 기간에 영향을 미칩니다:

  • 소스 및 대상 GitLab 인스턴스에서 사용 가능한 하드웨어 및 데이터베이스 리소스. 소스 및 대상 인스턴스의 더 많은 리소스는 다음과 같은 이유로 이전 기간이 짧아질 수 있습니다:
    • 소스 인스턴스에서 API 요청을 받고 내보낼 엔티티를 추출하고 직렬화합니다.
    • 대상 인스턴스에서 작업을 실행하고 엔티티를 데이터베이스에 생성합니다.
  • 내보낼 데이터의 복잡성과 크기. 예를 들어, 각각 1000개의 병합 요청을 가진 두 개의 다른 프로젝트를 이전하려고 합니다. 병합 요청에 첨부 파일, 댓글 및 기타 항목이 훨씬 많은 프로젝트의 이전 기간이 훨씬 다를 수 있습니다. 따라서 프로젝트의 병합 요청 수는 프로젝트를 이전하는 데 얼마나 오래 걸릴지 예측하는 데 부적합합니다.

신뢰할 수있는 이전을 신뢰할 수있는 정확한 공식은 없습니다. 그러나 각 파이프라인 작업자가 프로젝트 관계를 가져오는 평균 기간을 통해 프로젝트 가져오는 데 얼마나 오래 걸릴지에 대한 감을 얻을 수 있습니다:

프로젝트 리소스 유형 레코드를 가져오는 평균 시간(초)
빈 프로젝트 2.4
리포지토리 20
프로젝트 속성 1.5
멤버 0.2
레이블 0.1
마일스톤 0.07
배지 0.1
이슈 0.1
스니펫 0.05
스니펫 리포지토리 0.5
보드 0.1
병합 요청 1
외부 풀 리퀘스트 0.5
보호된 브랜치 0.1
프로젝트 기능 0.3
컨테이너 만료 정책 0.3
서비스 데스크 설정 0.3
릴리스 0.1
CI 파이프라인 0.2
커밋 노트 0.05
위키 10
업로드 0.5
LFS 객체 0.5
디자인 0.1
Auto DevOps 0.1
파이프라인 일정 0.5
참조 5
푸시 규칙 0.1

큰 프로젝트를 이전하거나 이전 기간의 시간 초과나 이슈가 발생하는 경우 이전 기간을 줄이는 방법을 참조하세요.

제한

  • GitLab 16.7에서 제거함에 따라 이주에 대한 8시간 제한 시간이 적용됩니다.

직접 전송에는 이주에 대한 하드 코딩된 제한이 적용됩니다.

제한 설명
6 사용자당 대상 GitLab 인스턴스에서 허용되는 최대 마이그레이션 수 1분당. GitLab 15.9에서 도입되었습니다.
210초 아카이브 파일을 압축 해제하는 데 대기할 수 있는 최대 초 단위 수.
50MB NDJSON 행이 가질 수 있는 최대 길이.
5분 소스 인스턴스에서 빈 내보내기 상태가 발생하는 까지의 최대 초 단위 수.

구성 가능한 제한도 있습니다.

GitLab 16.3 이후, 다음과 같이 이전에 하드 코딩된 설정이 구성 가능하게 되었습니다:

  • 소스 인스턴스에서 다운로드할 수 있는 최대 관계 크기 (5 GiB로 설정).
  • 압축 해제된 아카이브의 최대 크기 (10 GiB로 설정).

다음 API를 사용하여 최대 관계 크기 제한을 테스트할 수 있습니다:

두 API 중 어느 하나라도 최대 관계 크기 제한보다 큰 파일을 생성하면, 그룹 이주가 직접 전송으로 실패합니다.

가시성 규칙

이주 후:

  • 비공개 그룹 및 프로젝트는 비공개 상태를 유지합니다.
  • 내부 그룹 및 프로젝트:
    • 내부 그룹에 복사된 경우 내부 상태를 유지하고 내부 가시성이 제한될 때만 비공개 상태가 됩니다. 그 경우, 그룹 및 프로젝트는 비공개가 됩니다.
    • 비공개 그룹에 복사된 경우 비공개 상태가 됩니다.
  • 공개 그룹 및 프로젝트:
    • 공개 그룹에 복사된 경우 공개 상태를 유지하고 공개 가시성이 제한될 때만 내부 상태가 됩니다. 그 경우, 그룹 및 프로젝트는 비공개가 됩니다.
    • 내부 그룹에 복사된 경우 내부 가시성이 제한될 때만 비공개 상태가 됩니다. 그 경우, 그룹 및 프로젝트는 비공개가 됩니다.
    • 비공개 그룹에 복사된 경우 비공개 상태가 됩니다.

소스 인스턴스에서 일반 대중에게 콘텐츠를 숨기기 위해 비공개 네트워크를 사용한 경우, 대상 인스턴스에서 비슷한 설정을 갖거나 비공개 그룹으로 가져오도록해야합니다.

요구 사항

  • 개발자 역할 대신 메인테이너 역할에 대한 요구 사항은 GitLab 16.0에 도입되었으며, GitLab 15.11.1 및 GitLab 15.10.5로 백포팅되었습니다.

직접 전송을 사용하여 이주하기 전에 다음 요구 사항을 확인하십시오.

네트워크

  • 인스턴스 또는 GitLab.com 간의 네트워크 연결은 HTTPS를 지원해야 합니다.
  • 방화벽은 소스 및 대상 GitLab 인스턴스 간의 연결을 차단해서는 안됩니다.

버전

소스 GitLab 인스턴스는 그룹을 가져오려면 GitLab 14.0 또는 이후 버전을 실행해야 하며, 프로젝트를 가져오려면 GitLab 14.4 이상을 실행해야합니다. 그러나 성공적이고 효율적인 마이그레이션의 가능성을 극대화하려면 다음을 해야합니다:

  • 관계의 일괄 내보내기 및 가져오기를 활용하려면, 소스 및 대상 인스턴스를 GitLab 16.2 이상으로 업데이트하십시오.
  • 가능한 새로운 버전 간에 마이그레이션하십시오. 시간이 흐름에 따라 추가된 버그 수정 및 개선 사항을 활용하려면 소스 및 대상 인스턴스를 가능한 최신 버전으로 업데이트하십시오.

우리는 GitLab 16.2를 실행하는 소스 인스턴스와 GitLab 16.8을 실행하는 대상 인스턴스 간의 마이그레이션을 성공적으로 테스트했습니다.

구성

  • 양쪽 GitLab 인스턴스에서 인스턴스 관리자에 의해 직접 전송에 대한 그룹 마이그레이션을 활성화해야합니다.
  • 소스 GitLab 인스턴스에 대한 개인 액세스 토큰이 있어야합니다:
    • GitLab 15.1 이상의 소스 인스턴스의 경우, 개인 액세스 토큰에는 api 범위가 있어야합니다.
    • GitLab 15.0 및 이전 소스 인스턴스의 경우, 개인 액세스 토큰에는 apiread_repository 범위가 모두 있어야합니다.
  • 마이그레이션할 소스 그룹의 소유자 역할이 있어야합니다.
  • 그 네임 스페이스에서 서브그룹을 생성할 수 있는 역할이 있는 대상 인스턴스의 역할이 있어야합니다.
  • 객체 저장소에 저장된 항목을 가져오려면 다음 중 하나를 해야합니다:
    • proxy_download을 구성.
    • 대상 GitLab 인스턴스가 소스 GitLab 인스턴스의 객체 저장소에 액세스할 수 있도록 보장합니다.
  • 기본 프로젝트 생성 보호아무도로 설정한 경우 소스 인스턴스 또는 그룹에서 프로젝트를 가져올 수 없습니다. 필요한 경우 다음과 같이이 설정을 변경할 수 있습니다:

사용자 계정

GitLab은 사용자 및 그들의 기여를 정확하게 매핑하기 위해 다음을 수행합니다:

  1. 대상 GitLab 인스턴스에 필요한 사용자를 생성합니다. API를 사용하여 사용자를 생성할 수 있는 경우가 있습니다. 이는 관리자 액세스가 필요하기 때문에 자체 관리형 인스턴스에서만 가능합니다. GitLab.com 또는 자체 관리형 GitLab 인스턴스로 이관하는 경우 다음을 수행할 수 있습니다:
  2. 사용자가 소스 GitLab 인스턴스에서 공개 이메일을 가지고 있어야 하며, 이는 대상 GitLab 인스턴스에서 확인된 이메일 주소와 일치해야 합니다. 대부분의 사용자는 이메일 주소 확인을 요청받습니다.
  3. 사용자가 이미 대상 인스턴스에 존재하고 SAML SSO를 GitLab.com 그룹에서 사용하는 경우 모든 사용자는 SAML ID를 GitLab.com 계정에 연결해야 합니다.

소스 GitLab 인스턴스 연결

가져오려는 그룹을 생성하고 소스 GitLab 인스턴스를 연결합니다:

  1. 다음 중 하나를 생성합니다:
    • 새 그룹. 왼쪽 사이드바에서 맨 위에서 새로 만들기 () 및 새 그룹을 선택합니다. 그런 다음 그룹 가져오기를 선택합니다.
    • 새 하위 그룹. 기존 그룹 페이지에서 다음 중 하나를 수행합니다:
      • 새 하위 그룹을 선택합니다.
      • 왼쪽 사이드바에서 맨 위에서 새로 만들기 () 및 새 하위 그룹을 선택합니다. 그런 다음 기존 그룹 가져오기 링크를 선택합니다.
  2. GitLab 14.0 이상을 실행하는 GitLab 인스턴스의 기본 URL을 입력합니다.
  3. 소스 GitLab 인스턴스의 개인 액세스 토큰을 입력합니다.
  4. 인스턴스 연결을 선택합니다.

가져올 그룹 및 프로젝트 선택

소스 GitLab 인스턴스에 대한 액세스 권한을 승인한 후, GitLab 그룹 가져오기 페이지로 리디렉션됩니다. 여기서 Owner 역할을 가진 연결된 소스 인스턴스의 최상위 그룹 목록을 볼 수 있습니다.

  1. 기본적으로 제안된 그룹 네임스페이스는 소스 인스턴스에 있는 것과 동일한 이름과 일치하지만 권한에 따라 진행하기 전에 이러한 이름을 편집할 수 있습니다.
  2. 가져오려는 그룹 옆에 다음 중 하나를 선택합니다:
    • 프로젝트와 함께 가져오기. 사용할 수 없는 경우 사전 요구 사항을 확인하세요.
    • 프로젝트 없이 가져오기.
  3. 상태 열에는 각 그룹의 가져오기 상태가 표시됩니다. 페이지를 닫지 않고 두면 실시간으로 업데이트됩니다.
  4. 그룹이 가져온 후 해당 GitLab 경로를 선택하여 GitLab URL을 엽니다.

경고: 프로젝트를 포함하여 그룹을 가져오는 기능은 Beta 상태입니다. 이 기능은 운영 환경에 사용하기에 적합하지 않습니다.

그룹 가져오기 기록

  • GitLab 16.7에 부분 완료 상태 도입됨(https://gitlab.com/gitlab-org/gitlab/-/issues/394727)..

직접 전송하여 이전되었거나 일부 완료된 그룹을 모두 볼 수 있습니다. 이 목록에는 다음이 포함됩니다:

  • 소스 그룹의 경로
  • 대상 그룹의 경로
  • 각 가져오기의 시작 날짜
  • 각 가져오기의 상태
  • 발생한 모든 오류의 세부 정보

그룹 가져오기 기록을 보려면:

  1. GitLab에 로그인합니다.
  2. 왼쪽 사이드바에서 맨 위에서 새로 만들기 () 및 새 그룹을 선택합니다.
  3. 그룹 가져오기를 선택합니다.
  4. 오른쪽 상단 모서리에서 기록을 선택합니다.
  5. 특정 가져오기에 오류가 있는 경우 해당 세부 정보를 확인하려면 실패 항목 보기를 선택합니다.

가져오기 결과 검토

  • GitLab 16.6에 bulk_import_details_page라는 플래그가 추가됨(https://gitlab.com/gitlab-org/gitlab/-/issues/429109). 기본적으로 활성화됨.
  • GitLab 16.8에서 bulk_import_details_page 기능 플래그가 제거됨.
  • 부분 완료 상태 및 완료된 가져오기에 대한 세부 정보는 GitLab 16.9에서 추가됨(https://gitlab.com/gitlab-org/gitlab/-/issues/437874).

가져오기의 결과를 검토하려면:

  1. 그룹 가져오기 기록 페이지로 이동합니다.
  2. 실패한 가져오기의 세부 정보를 보려면 실패 또는 부분 완료 상태인 가져오기 중에서 세부 정보를 선택합니다.
  3. 가져오기가 부분 완료 또는 완료 상태인 경우 가져온 항목과 가져오지 않은 항목을 확인하려면 세부 정보를 선택합니다.

실행 중인 가져오기 취소

실행 중인 가져오기를 취소하려면:

  1. 대상 GitLab 인스턴스에서 레일즈 콘솔 세션을 시작합니다.

  2. 다음 명령을 실행하여 마지막 가져오기를 찾습니다. USER_ID를 가져오기를 시작한 사용자의 ID로 대체합니다:

    bulk_import = BulkImport.where(user_id: USER_ID).last
    
  3. 다음 명령을 실행하여 가져오기와 관련된 모든 항목을 실패시킵니다:

    bulk_import.entities.each do |entity|
      entity.trackers.each do |tracker|
        tracker.batches.each(&:fail_op!)
      end
      entity.trackers.each(&:fail_op!)
      entity.fail_op!
    end
    bulk_import.fail_op!
    

bulk_import를 취소해도 소스 인스턴스에서 프로젝트를 내보내는 작업자들을 중지시키지는 않지만:

  • 대상이 더 많은 프로젝트를 내보내도록 요청하는 것을 방지합니다.
  • 대상이 소스로부터 더 많은 API 호출을 하지 못하도록 합니다.

이전된 그룹 항목

이전된 그룹 항목은 대상에서 사용 중인 GitLab 버전에 따라 다릅니다. 특정 그룹 항목이 이전되었는지 확인하려면:

  1. 모든 버전에 대한 groups/stage.rb 파일 및 대상 버전에 대한 Enterprise Edition의 groups/stage.rb 파일을 확인합니다. 예를 들어, 버전 15.9의 경우:
  2. 대상 버전에 대한 그룹용 group/import_export.yml 파일을 확인합니다. 예를 들어, 버전 15.9의 경우: https://gitlab.com/gitlab-org/gitlab/-/blob/15-9-stable-ee/lib/gitlab/import_export/group/import_export.yml.

다른 그룹 항목은 이전되지 않습니다.

대상 GitLab 인스턴스로 이전되는 그룹 항목은 다음과 같습니다:

그룹 항목 소개된 버전
뱃지 GitLab 13.11
보드 GitLab 13.7
보드 목록 GitLab 13.7
이픽스 1 GitLab 13.7
그룹 레이블 2 GitLab 13.9
이터레이션 GitLab 13.10
이터레이션 케이던스 GitLab 15.4
멤버 3 GitLab 13.9
그룹 마일스톤 GitLab 13.10
네임 스페이스 설정 GitLab 14.10
릴리즈 마일스톤 GitLab 15.0
서브그룹 GitLab 13.7
업로드 GitLab 13.7
  1. GitLab 15.4에서 소개된 에픽 리소스 상태 이벤트, GitLab 13.12에서 소개된 레이블 연관, GitLab 13.7에서 소개된 상태 및 상태 ID, GitLab 14.0에서 소개된 시스템 노트 메타데이터가 포함됩니다.
  2. 그룹 레이블은 가져올 때 연결된 레이블 우선 순위를 유지할 수 없습니다. 해당 프로젝트가 대상 인스턴스로 마이그레이션된 후에는 이러한 레이블을 수동으로 다시 우선 순위를 지정해야 합니다.
  3. 그룹 멤버는 사용자가 다음 중 하나에 해당하는 경우 가져온 그룹과 연결됩니다:
    • 대상 GitLab 인스턴스에 이미 존재합니다.
    • 소스 GitLab 인스턴스에서 공개 이메일을 가지고 대상 GitLab 인스턴스에서 확인된 이메일과 일치합니다.

제외된 항목

일부 그룹 항목은 다음과 같은 이유로 이관에서 제외됩니다:

  • 민감한 정보를 포함할 수 있습니다: CI/CD 변수, 웹훅 및 배포 토큰.
  • 지원되지 않음: 푸시 규칙.

이관된 프로젝트 항목

상태: 베타

만약 이관할 그룹을 선택할 때 프로젝트를 이관하기로 선택하면, 프로젝트 항목이 해당 프로젝트와 함께 이관됩니다.

이관된 프로젝트 항목은 대상에서 사용하는 GitLab 버전에 따라 다릅니다. 특정 프로젝트 항목이 이관되는지 확인하려면:

  1. 모든 버전을 위한 projects/stage.rb 파일 및 Enterprise Edition을 위한 projects/stage.rb 파일을 대상 버전에 맞춰 확인하세요. 예를 들어, 15.9 버전의 경우:
  2. 대상 버전에 대한 프로젝트를 위한 project/import_export.yml 파일을 확인하세요. 예를 들어, 15.9 버전의 경우: https://gitlab.com/gitlab-org/gitlab/-/blob/15-9-stable-ee/lib/gitlab/import_export/project/import_export.yml.

다른 프로젝트 항목은 이관되지 않습니다.

그룹과 함께 프로젝트를 이관하지 않거나 프로젝트 이관을 재시도하려면, API를 사용하여 프로젝트만 이관을 시작할 수 있습니다.

경고: 직접 이관하는 경우 그룹과 함께 프로젝트를 이관하는 것이 베타 상태이며, 상용으로 사용할 준비가 되지 않았습니다.

대상 GitLab 인스턴스로 이관되는 프로젝트 항목은 다음과 같습니다:

프로젝트 항목 도입 버전
프로젝트 GitLab 14.4
Auto DevOps GitLab 14.6
뱃지 GitLab 14.6
브랜치 (보호된 브랜치 포함) 1 GitLab 14.7
CI 파이프라인 GitLab 14.6
커밋 댓글 GitLab 15.10
디자인 GitLab 15.1
이슈 GitLab 14.4
이슈 보드 GitLab 14.4
레이블 GitLab 14.4
LFS 객체 GitLab 14.8
멤버 GitLab 14.8
머지 요청 GitLab 14.5
푸시 규칙 GitLab 14.6
마일스톤 GitLab 14.5
외부 풀 요청 GitLab 14.5
파이프라인 이력 GitLab 14.6
파이프라인 스케줄 GitLab 14.8
프로젝트 피쳐 GitLab 14.6
릴리즈 GitLab 15.1
릴리즈 증거 GitLab 15.1
저장소 GitLab 14.4
스니펫 GitLab 14.6
설정 GitLab 14.6
업로드 GitLab 14.5
위키 GitLab 14.6
각주:
  1. 이관된 브랜치는 대상 그룹의 기본 브랜치 보호 설정을 준수하며, 이로 인해 보호되지 않은 브랜치가 보호된 상태로 이관될 수 있습니다.

이슈 관련 항목

목적지 GitLab 인스턴스로 이관된 이슈 관련 프로젝트 항목은 다음과 같습니다:

이슈 관련 프로젝트 항목 도입된 버전
이슈 반복 GitLab 15.4
이슈 리소스 상태 이벤트 GitLab 15.4
이슈 리소스 마일스톤 이벤트 GitLab 15.4
이슈 리소스 반복 이벤트 GitLab 15.4
병합 요청 URL 참조 GitLab 15.6
시간 추적 GitLab 14.4

병합 요청 관련 항목

목적지 GitLab 인스턴스로 이관된 병합 요청 관련 프로젝트 항목은 다음과 같습니다:

병합 요청 관련 프로젝트 항목 도입된 버전
병합 요청 담당자 다수 지정 GitLab 15.3
병합 요청 리뷰어 GitLab 15.3
병합 요청 승인자 GitLab 15.3
병합 요청 리소스 상태 이벤트 GitLab 15.4
병합 요청 리소스 마일스톤 이벤트 GitLab 15.4
이슈 URL 참조 GitLab 15.6
시간 추적 GitLab 14.5

설정 관련 항목

목적지 GitLab 인스턴스로 이관된 설정 관련 프로젝트 항목은 다음과 같습니다:

설정 관련 프로젝트 항목 도입된 버전
아바타 GitLab 14.6
컨테이너 만료 정책 GitLab 14.6
프로젝트 속성 GitLab 14.6
서비스 데스크 GitLab 14.6

제외된 항목

일부 프로젝트 항목은 다음과 같은 이유로 이관에서 제외되었습니다:

  • 민감한 정보가 포함될 수 있음:
    • CI/CD 변수
    • 배포 키
    • 배포 토큰
    • 파이프라인 일정 변수
    • 파이프라인 트리거
    • 웹훅
  • 지원되지 않음:
    • 에이전트
    • 컨테이너 레지스트리
    • 환경
    • 기능 플래그
    • 인프라 레지스트리
    • 패키지 레지스트리
    • 페이지 도메인
    • 원격 미러

문제 해결

rails console 세션에서 그룹 가져오기 시도의 실패 또는 오류 메시지를 찾을 수 있습니다:

# 관련 가져오기 레코드 가져오기
import = BulkImports::Entity.where(namespace_id: Group.id).map(&:bulk_import).last

# 사용자별 대체 조회
import = BulkImport.where(user_id: User.find(...)).last

# 가져오기 엔티티 목록 가져오기. 각 엔티티는 그룹 또는 프로젝트를 나타냄
entities = import.entities

# 엔티티 실패 목록 가져오기
entities.map(&:failures).flatten

# 대체로 상태를 찾아 실패 조회
entities.where(status: [-1]).pluck(:destination_name, :destination_namespace, :status)

그리고 API 엔드포인트를 사용하여 모든 가져오기된 엔티티 및 관련 실패를 확인할 수도 있습니다.

만료된 가져오기

그룹 이관을 문제 해결할 때, 가져오기 워커가 실행하는 시간이 8시간을 초과하여 완료되지 않을 수 있습니다. 이 경우, BulkImport 또는 BulkImport::Entitystatus3 (timeout)임:

# 관련 가져오기 레코드 가져오기
import = BulkImports::Entity.where(namespace_id: Group.id).map(&:bulk_import)

import.status #=> 3은 가져오기가 시간 초과되었음을 의미.

오류: 404 그룹을 찾을 수 없음

숫자만으로 구성된 경로를 가진 그룹(예: 5000)을 가져오려고 시도하면, GitLab은 경로 대신 그룹 ID를 사용하여 그룹을 찾으려고 합니다. 이는 GitLab 15.4 이전 버전에서 404 그룹을 찾을 수 없음 오류를 발생시킵니다.

해결책으로는 소스 그룹 경로를 비숫자 문자를 포함하도록 변경해야 합니다. 변경하는 방법은 다음과 같습니다:

  • GitLab UI를 사용하는 경우:

    1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
    2. 설정 > 일반을 선택합니다.
    3. 고급을 확장합니다.
    4. 그룹 URL 변경 아래에서 그룹 URL을 숫자 이외의 문자를 포함하도록 변경합니다.
  • 그룹 API를 사용하는 경우.

기타 404 오류

그룹을 가져올 때 다른 404 오류를 받을 수도 있습니다. 예를 들어:

"exception_message": "[FILTERED] Bo...에서의 404 응답이 실패했습니다.",
"exception_class": "BulkImports::NetworkError",

이 오류는 소스 인스턴스에서의 전송 문제를 나타냅니다. 이를 해결하기 위해 나열된 전제 조건이 소스 인스턴스에서 충족되었는지 확인하세요.

마이그레이션 기간 축소

단일 직접 전송 마이그레이션은 목적지 인스턴스에서 사용 가능한 작업자 수와 상관없이 한 번에 5개의 엔티티(그룹 또는 프로젝트)를 가져옵니다. 따라서 목적지 인스턴스에서 사용 가능한 작업자수를 늘리면 각 엔티티를 가져오는 데 걸리는 시간을 단축시켜 마이그레이션을 가속화할 수 있습니다.

이에 따라 목적지 인스턴스의 작업자 수를 늘리면 소스 인스턴스의 하드웨어 리소스가 포화될 때까지 마이그레이션 기간을 단축하는 데 도움이 됩니다. 물론 epic 9036에서 제안된 대로 일괄적으로 관계를 내보내고 가져오는 것이 목적지 인스턴스에서 사용 가능한 작업자수를 더욱 유용하게 만듭니다.

소스 인스턴스의 작업자 수는 병렬로 5개의 엔티티를 내보내기 충분해야 합니다. 그렇지 않으면 목적지가 내보낸 데이터를 기다리는 지연 및 잠재적인 시간 초과가 발생할 수 있습니다.

다른 그룹에 프로젝트를 분산하는 것은 시간 초과를 피하는 데 도움이 됩니다. 동일한 그룹에 여러 대형 프로젝트가 있는 경우 다음을 수행할 수 있습니다:

  1. 대형 프로젝트를 다른 그룹이나 하위 그룹으로 이동합니다.
  2. 각 그룹 및 하위 그룹마다 별도의 마이그레이션을 시작합니다.

GitLab UI는 최상위 그룹만 마이그레이션할 수 있습니다. API를 사용하면 서브그룹도 마이그레이션할 수 있습니다.