Deep Dive#

2018년 12월, Tiago Botelho는 GitLab 팀원 전용 딥 다이브 세션(GitLab team members only: https://gitlab.com/gitlab-org/create-stage/-/issues/1)을 진행하며 GitLab 풀 리포지터리 미러링 기능에 대한 도메인 전문 지식을 향후 이 코드베이스에서 작업할 사람들과 공유했습니다. YouTube 녹화본과 PDF 슬라이드를 확인할 수 있습니다. 세부 사항은 그 이후 변경되었을 수 있지만, 여전히 좋은 입문 자료로 활용할 수 있습니다.

미러링 프로세스 설명#

GitLab은 API 호출이 풀 미러를 트리거할 때 다음 단계를 수행합니다. 예약된 미러 업데이트도 유사하지만, API 호출로 시작하지 않습니다:

• 요청이 API 호출에서 시작되어 project_mirror.rb의 start_pull_mirroring_service를 트리거합니다.

• 풀 미러링 서비스(start_pull_mirroring_service.rb)가 시작됩니다. 이 서비스는 프로젝트 상태를 업데이트하고 job을 즉시 강제 시작합니다.

• 프로젝트 임포트 상태가 업데이트되고, project_import_state.rb에서 update_all_mirrors_worker를 트리거합니다.

• 전체 미러 업데이트 워커(update_all_mirrors_worker.rb)는 project_import_schedule 워커를 호출하여 스탬피드(stampede)를 방지하려 시도합니다.

• 프로젝트 임포트 스케줄 워커(project_import_schedule_worker.rb)는 프로젝트의 상태를 업데이트하고, Ruby state_machine을 시작하여 임포트 전환 프로세스를 관리합니다.

• 프로젝트 상태를 업데이트하는 동안, project.rb의 이 호출이 repository_update_mirror 워커를 시작합니다.

• Sidekiq 백그라운드 미러 워커(repository_update_mirror_worker.rb)는 미러링 작업의 상태를 추적하고 오류 상태 정보를 제공합니다. 이 단계는 Git 단계를 관리하므로 프로세스가 여기서 중단될 수 있습니다.

• 미러 업데이트 서비스(update_mirror_service.rb)가 Git 작업을 수행합니다.

임포트 및 미러 업데이트 프로세스는 미러 업데이트 서비스 단계 이후 완료됩니다. 그러나 포함된 변경 사항에 따라 커밋에 대한 파이프라인 등 추가 작업이 트리거될 수 있습니다.