Repository mirroring
Deep Dive
In December 2018, Tiago Botelho hosted a Deep Dive (GitLab team members only: https://gitlab.com/gitlab-org/create-stage/issues/1
)
on the GitLab Pull Repository Mirroring functionality
to share his domain specific knowledge with anyone who may work in this part of the
codebase in the future. You can find the recording on YouTube,
and the slides in PDF.
Everything covered in this deep dive was accurate as of GitLab 11.6, and while specific
details may have changed since then, it should still serve as a good introduction.
Explanation of mirroring process
GitLab version 14 performs these steps when an API call triggers a pull mirror. Scheduled mirror updates are similar, but do not start with the API call:
- The request originates from an API call, and triggers the
start_pull_mirroring_service
inproject_mirror.rb
. - The pull mirroring service
(
start_pull_mirroring_service.rb
) starts. It updates the project state, and forces the job to start immediately. - The project import state is updated, and then triggers an
update_all_mirrors_worker
inproject_import_state.rb
. - The update all mirrors worker
(
update_all_mirrors_worker.rb
) attempts to avoid stampedes by calling theproject_import_schedule
worker. - The project import schedule worker
(
project_import_schedule_worker.rb
) updates the state of the project, and starts a Rubystate_machine
to manage the import transition process. - While updating the project state,
this call in
project.rb
starts therepository_update_mirror
worker. - The Sidekiq background mirror workers
(
repository_update_mirror_worker.rb
) track the state of the mirroring task, and provide good error state information. Processes can hang here, because this step manages the Git steps. - The update mirror service
(
update_mirror_service.rb
) performs the Git operations.
The import and mirror update processes are complete after the update mirror service step. However, depending on the changes included, more tasks (such as pipelines for commits) can be triggered.