仓库镜像

深入探讨

2018年12月，Tiago Botelho 举办了一次深入探讨（仅限 GitLab 团队成员：https://gitlab.com/gitlab-org/create-stage/-/issues/1），主题是 GitLab 的拉取仓库镜像功能，旨在与他未来可能在这部分代码库中工作的人分享他的领域专业知识。你可以在 YouTube 上找到 录像，以及 PDF 格式的幻灯片。虽然具体细节可能已经改变，但它仍然是一个很好的介绍。

镜像过程说明

当API 调用触发拉取镜像时，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. 更新所有镜像的 worker (update_all_mirrors_worker.rb) 通过调用 project_import_schedule worker 来避免拥塞。
5. 项目导入计划 worker (project_import_schedule_worker.rb) 更新项目状态，并启动一个 Ruby state_machine 来管理导入转换过程。
6. 在更新项目状态时，project.rb 中的这个调用会启动 repository_update_mirror worker。
7. Sidekiq 后台镜像 worker (repository_update_mirror_worker.rb) 跟踪镜像任务的状态，并提供良好的错误状态信息。进程可能会在这里挂起，因为这一步管理着 Git 步骤。
8. 更新镜像服务 (update_mirror_service.rb) 执行 Git 操作。

在更新镜像服务步骤之后，导入和镜像更新过程就完成了。但是，根据包含的更改，可能会触发更多任务（例如提交的流水线）。