리포지토리 미러링

심층 탐구

2018년 12월, Tiago Botelho가 Deep Dive를 주최했습니다(이벤트는 GitLab 팀 멤버 전용: https://gitlab.com/gitlab-org/create-stage/-/issues/1). 이 이벤트에서는 GitLab 풀 레포지토리 미러링 기능에 대한 도메인 특화 지식을 가진 사용자들과 나누고자 했습니다. 이후 이 코드베이스를 다룰 수 있는 누군가에게 도움이 되길 바라며 녹화된 비디오는 YouTube에서 확인할 수 있습니다 그리고 PDF로 슬라이드를 볼 수 있습니다. 그 이후에도 특정 세부 사항이 변경되었을 수 있지만, 여전히 좋은 소개 자료일 것입니다.

미러링 프로세스 설명

GitLab에서 풀 미러링이 트리거되면 아래의 단계를 수행합니다. 예약된 미러링 업데이트는 유사하지만 API 호출로 시작되지는 않습니다:

  1. 요청은 API 호출에서 발생하며, project_mirror.rb의 start_pull_mirroring_service가 트리거됩니다.
  2. 풀 미러링 서비스(start_pull_mirroring_service.rb)가 시작됩니다. 프로젝트 상태를 업데이트하고 작업을 즉시 시작하도록 강제합니다.
  3. 프로젝트 가져오기 상태가 업데이트되며 project_import_state.rb의 update_all_mirrors_worker가 트리거됩니다.
  4. 모든 미러 업데이트 워커(update_all_mirrors_worker.rb)는 project_import_schedule 워커를 호출하여 stampedes를 피하려고 시도합니다.
  5. 프로젝트 가져오기 스케쥴 워커(project_import_schedule_worker.rb)는 프로젝트 상태를 업데이트하고 가져오기 전환 프로세스를 관리하는 Ruby state_machine을 시작합니다.
  6. 프로젝트 상태를 업데이트하는 동안, 이 호출은 project.rb에서 repository_update_mirror 워커를 시작합니다.
  7. Sidekiq 백그라운드 미러 워커(repository_update_mirror_worker.rb)는 미러링 작업의 상태를 추적하며 좋은 오류 상태 정보를 제공합니다. 여기서 프로세스가 멈출 수 있습니다. 이 단계에서 Git 단계를 관리하기 때문입니다.
  8. 업데이트 미러 서비스(update_mirror_service.rb)는 Git 작업을 수행합니다.

업데이트 미러 서비스 단계 이후에 가져오기 및 미러 업데이트 프로세스가 완료됩니다. 그러나 포함된 변경 사항에 따라 커밋을 위한 파이프라인과 같은 더 많은 작업들이 트리거될 수 있습니다.