GitLab CI跨仓库镜像复用包含两方面：一是通过include复用他人CI模板YAML配置，支持版本控制与extends组合；二是复用他人构建的容器镜像，需配置registry认证，或通过镜像仓库同步、xpull工具搬运实现。
GitLab CI 实现跨仓库的镜像复用，核心在于两个层面：一是复用他人或团队维护的 CI 模板定义（即 YAML 配置逻辑），二是复用他人构建并推送的 容器镜像（如 Docker 镜像）。两者目标不同、技术路径不同，但都服务于“避免重复建设”。下面分清楚讲：
复用其他仓库的 CI 模板（YAML 配置）
这是最常用、也最推荐的跨项目复用方式，本质是把通用的 job、stage、变量等抽离成独立配置文件，再被多个项目 include。
- 在专用模板仓库（如
ci-templates）中存放标准化 YAML 文件，例如：
•base-job.yml：定义基础环境、缓存、超时等
•php-test.yml：含 composer install、phpunit 运行逻辑
•deploy-staging.yml：extends 自 base-job，追加部署脚本和环境变量 - 目标项目中通过
include:引入远程仓库文件：include:<br> - project: 'group/ci-templates'<br> file: '/php/php-test.yml'<br> ref: 'v1.2'
支持指定分支或 tag，实现版本控制 - 配合
extends可进一步组合复用，比如一个部署 job 继承基础校验逻辑，再叠加灰度参数，无需重复写 shell 脚本
复用其他仓库构建并托管的容器镜像
指在自己的 CI job 中拉取并运行别人已构建好的镜像，常见于工具类镜像（如自定义 linter、扫描器、部署 CLI）或基础应用镜像。
- 确保目标镜像已推送到 GitLab Container Registry 或其他公开/私有 registry（如 Harbor、Docker Hub）
- 在 .gitlab-ci.yml 的 job 中直接指定
image:：job-name:<br> image: registry.example.com/group/toolbox:latest<br> script:<br> - my-lint-tool --fix
- 若镜像是私有的，必须配置认证：
• 项目级：在 Settings → CI/CD → Variables 中添加DOCKER_AUTH_CONFIG，值为 base64 编码的 ~/.docker/config.json 内容
• Runner 级：在 gitlab-runner 的 config.toml 中全局设置 environment 变量
同步源代码仓库以支撑镜像构建
当你要复用的镜像尚未存在，但其构建源在另一个 GitLab 仓库中，可通过镜像仓库（Mirroring）机制自动同步代码，再触发本地 CI 构建。
- 进入当前项目 Settings → Repository → Mirroring repositories
• 填写上游仓库 URL（如https://user:token@gitlab.example.com/group/app-base.git）
• 方向选 Push 或 Pull（Push 表示你向它同步；Pull 表示你从它同步）
• 勾选 “Only mirror protected branches” 提高稳定性 - 同步后，可配置 CI 在检测到 upstream/main 更新时自动触发构建，生成新镜像并推送到你的 registry
- 注意：镜像仓库功能在 GitLab CE 15.6+ 已稳定支持 HTTPS 推送，LFS 文件也能同步
用 xpull 等工具同步已有容器镜像
适用于跨 registry（如 Docker Hub → 私有 Harbor）批量搬运镜像，尤其适合离线环境或多云部署场景。
- 安装轻量工具 xpull（单二进制，无依赖）
- 执行同步命令：
xpull --src docker.io/library/nginx:alpine --dst harbor.example.com/myproj/nginx:alpine - 可集成进 CI 流水线，在部署前预热镜像，避免生产环境拉取超时
