리포지토리 미러링

심층 분석

2018년 12월, Tiago Botelho는 GitLab Pull Repository Mirroring 기능에 대한 심층 분석 회의를 개최했습니다. (GitLab 팀원 전용: https://gitlab.com/gitlab-org/create-stage/-/issues/1)

이 회의는 향후 이 코드베이스의 이 부분에서 작업할 수 있는 anyone에게 도메인 특정 지식을 공유하기 위해 마련되었습니다.

YouTube에서 녹화된 내용과 PDF에서 슬라이드를 찾을 수 있습니다.

특정 세부 사항은 그 이후로 변경되었을 수 있지만, 여전히 좋은 소개 자료로 사용될 수 있습니다.

미러링 프로세스 설명

GitLab은 API 호출로 인해 풀 미러링이 트리거될 때 다음 단계를 수행합니다.

예약된 미러 업데이트는 유사하지만 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 작업자를 호출하여 혼잡을 피하려고 시도합니다.

  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 작업을 수행합니다.

업데이트 미러 서비스 단계를 마친 후 가져오기 및 미러 업데이트 프로세스가 완료됩니다. 그러나 포함된 변경 사항에 따라 여러 작업(예: 커밋을 위한 파이프라인)이 트리거될 수 있습니다.