GitLab으로 마이그레이션할 때 다음과 같은 문제가 발생할 수 있습니다.

가져온 저장소에 브랜치가 누락된 경우#

가져온 저장소에 소스 저장소의 모든 브랜치가 포함되지 않은 경우:

1. 환경 변수 IMPORT_DEBUG=true를 설정합니다.
2. 다른 그룹, 서브그룹 또는 프로젝트 이름으로 가져오기를 다시 시도합니다.
3. 일부 브랜치가 여전히 누락된 경우, importer.log를 검사합니다 (예: jq 사용).

예외: Error Importing repository - No such file or directory @ rb_sysopen - (filename)#

이 오류는 저장소 소스 코드의 tar.gz 파일 다운로드를 가져오려고 시도할 때 발생합니다.

가져오기는 단순한 저장소 다운로드 파일이 아닌 GitLab 내보내기 파일이 필요합니다.

장시간 지연 또는 실패한 가져오기 진단#

파일 기반 가져오기, 특히 S3를 사용하는 가져오기에서 장시간 지연이나 실패를 경험하는 경우 다음이 문제의 근본 원인을 파악하는 데 도움이 될 수 있습니다:

• 가져오기 단계 확인
• 로그 검토
• 일반적인 문제 식별

가져오기 상태 확인#

가져오기 상태를 확인합니다:

1. GitLab API를 사용하여 영향받는 프로젝트의 가져오기 상태를 확인합니다.
2. 오류 메시지나 상태 정보, 특히 status 및 import_error 값에 대한 응답을 검토합니다.
3. 추가 문제 해결에 중요하므로 응답에 있는 correlation_id를 기록해 둡니다.

로그 검토#

관련 정보를 위해 로그를 검색합니다:

GitLab Self-Managed 인스턴스의 경우:

1. Sidekiq 로그와 exceptions_json 로그를 확인합니다.
2. RepositoryImportWorker와 가져오기 상태 확인에서 얻은 상관 관계 ID와 관련된 항목을 검색합니다.
3. job_status, interrupted_count, exception 등의 필드를 확인합니다.

GitLab.com(GitLab 팀원만 해당)의 경우:

1. Kibana를 사용하여 다음과 같은 쿼리로 Sidekiq 로그를 검색합니다:

   대상: pubsub-sidekiq-inf-gprd*

   json.class: "RepositoryImportWorker" AND json.correlation_id.keyword: ""
   

   또는

   json.class: "RepositoryImportWorker" AND json.meta.project: "<project.full_path>"
   

2. GitLab Self-Managed 인스턴스와 동일한 필드를 확인합니다.

일반적인 문제 식별#

로그 검토에서 수집한 정보를 다음과 같은 일반적인 문제와 대조합니다:

• 중단된 job: interrupted_count가 높거나 job_status가 실패를 나타내는 경우, 가져오기 job이 여러 번 중단되어 데드 큐에 배치되었을 수 있습니다.
• S3 연결: S3를 사용하는 가져오기의 경우, 로그에서 S3 관련 오류 메시지를 확인합니다.
• 대형 저장소: 저장소가 매우 큰 경우 가져오기가 시간 초과될 수 있습니다. 이 경우 직접 전송 사용을 고려합니다.

지원 지식 베이스#

여전히 문제가 있는 경우 GitLab 지원 지식 베이스를 참조하세요.