문제 해결

GitLab으로 마이그레이션 시 발생하는 일반적인 문제를 해결합니다.

GitLab으로 마이그레이션할 때 다음과 같은 문제가 발생할 수 있습니다. 가져온 저장소에 브랜치가 누락된 경우 # 가져온 저장소에 소스 저장소의 모든 브랜치가 포함되지 않은 경우: 환경 변수 IMPORT_DEBUG=true 를 설정합니다. 다른 그룹, 서브그룹 또는 프로젝트 이름 으로 가져오기를 다시 시도합니다. 일부 브랜치가 여전히 누락된 경우, importer.log 를 검사합니다 (예: jq 사용). 예외: Error Importing repository - No such file or directory @ rb_sysopen - (filename) # 이 오류는 저장소 소스 코드의 tar.gz 파일 다운로드를 가져오려고 시도할 때 발생합니다. 가져오기는 단순한 저장소 다운로드 파일이 아닌 GitLab 내보내기 파일이 필요합니다. 장시간 지연 또는 실패한 가져오기 진단 # 파일 기반 가져오기, 특히 S3를 사용하는 가져오기에서 장시간 지연이나 실패를 경험하는 경우 다음이 문제의 근본 원인을 파악하는 데 도움이 될 수 있습니다: 가져오기 단계 확인 로그 검토 일반적인 문제 식별 가져오기 상태 확인 # 가져오기 상태를 확인합니다: GitLab API를 사용하여 영향받는 프로젝트의 가져오기 상태 를 확인합니다. 오류 메시지나 상태 정보, 특히 status 및 import_error 값에 대한 응답을 검토합니다. 추가 문제 해결에 중요하므로 응답에 있는 correlation_id 를 기록해 둡니다. 로그 검토 # 관련 정보를 위해 로그를 검색합니다: GitLab Self-Managed 인스턴스의 경우: Sidekiq 로그 와 exceptions_json 로그 를 확인합니다. RepositoryImportWorker 와 가져오기 상태 확인 에서 얻은 상관 관계 ID와 관련된 항목을 검색합니다. job_status , interrupted_count , exception 등의 필드를 확인합니다. GitLab.com(GitLab 팀원만 해당)의 경우: Kibana 를 사용하여 다음과 같은 쿼리로 Sidekiq 로그를 검색합니다: 대상: pubsub-sidekiq-inf-gprd* json.class: "RepositoryImportWorker" AND json.correlation_id.keyword: "" 또는 json.class: "RepositoryImportWorker" AND json.meta.project: "<project.full_path>" GitLab Self-Managed 인스턴스와 동일한 필드를 확인합니다. 일반적인 문제 식별 # 로그 검토 에서 수집한 정보를 다음과 같은 일반적인 문제와 대조합니다: 중단된 job: interrupted_count 가 높거나 job_status 가 실패를 나타내는 경우, 가져오기 job이 여러 번 중단되어 데드 큐에 배치되었을 수 있습니다. S3 연결: S3를 사용하는 가져오기의 경우, 로그에서 S3 관련 오류 메시지를 확인합니다. 대형 저장소: 저장소가 매우 큰 경우 가져오기가