仓库镜像

Deep Dive#

2018 年 12 月，Tiago Botelho 主持了一场深入探讨 (仅限极狐GitLab 团队成员：https://jihulab.com/gitlab-cn/create-stage/-/issues/1)，主题是极狐GitLab 拉取仓库镜像功能，旨在向未来可能在此代码库部分工作的任何人分享其领域知识。此后的具体细节可能有所变化，但本文仍可作为良好的入门介绍。

镜像过程说明#

当 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 操作。

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