GitLab CI含需凭证Git子模块的镜像构建方案问询

方案1：GitLab CI 临时注入Git凭证（无需自定义镜像） #

利用GitLab预定义的CI_JOB_TOKEN，在CI构建阶段临时配置Git凭证，无需永久存储：

• 在CI脚本中，构建镜像前执行以下命令配置Git：

  git config --global credential.helper '!f() { echo "username=gitlab-ci-token"; echo "password=$CI_JOB_TOKEN"; }; f'
  

• 随后执行git submodule update --init --recursive拉取所有子模块，再将完整目录作为Docker上下文传入构建工具。
• 该配置仅在当前CI作业周期内生效，作业结束后自动失效，无需额外清理步骤。

方案2：切换子模块URL为SSH格式，用CI SSH密钥认证 #

若子模块仓库支持SSH访问，可通过SSH密钥完成无交互认证：

1. 在GitLab项目的Settings > CI/CD > Variables中添加SSH私钥（命名为SSH_PRIVATE_KEY），并勾选Protected和Masked选项。
2. 在CI脚本中启动SSH代理并加载密钥：

   eval $(ssh-agent -s)
   echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add -
   mkdir -p ~/.ssh
   echo -e "Host gitlab.example.com\n\tStrictHostKeyChecking no\n" >> ~/.ssh/config
   

3. 修改主仓库中子模块的URL：执行git submodule set-url <子模块路径> git@gitlab.example.com:<用户名>/<子模块仓库>.git，提交修改到主仓库。
4. 后续拉取子模块或构建镜像时，Git会自动通过SSH密钥完成认证，无需输入用户名密码。

方案3：CI预拉取子模块，传递完整上下文给构建工具 #

在CI作业中提前拉取主仓库及所有子模块，将完整目录作为构建上下文传入Docker或Kaniko，避免构建阶段重复克隆子模块：

• CI脚本示例：

  git submodule update --init --recursive
  # Kaniko构建
  kaniko --context . --dockerfile Dockerfile --destination $IMAGE_TAG
  # Docker-in-Docker构建
  docker build -t $IMAGE_TAG .
  

• 优势：构建镜像过程无需处理Git认证，所有子模块已在CI环境中准备完成。

对现有方案的优化 #

针对PyPI包方案的优化 #

若坚持使用PyPI包方式，可通过以下方式降低测试与调试成本：

• 本地开发时，用pip install -e /本地子模块路径以可编辑模式安装子模块，修改子模块代码后无需重新打包即可生效。
• CI流程中将子模块打包到GitLab私有PyPI仓库，Dockerfile从私有仓库拉取安装包，确保测试环境与生产环境依赖一致。
• 部署调试阶段，可临时通过容器挂载替换包目录：docker run -v /本地子模块目录:/容器内子模块路径 ...，快速验证修改效果。

针对自定义Kaniko镜像方案的优化 #

若必须使用自定义镜像，可简化工作量：

• 基于官方Kaniko镜像，仅添加Git工具：

  FROM gcr.io/kaniko-project/executor:latest
  RUN apt-get update && apt-get install -y git && rm -rf /var/lib/apt/lists/*
  

• 在CI脚本中通过--build-arg传入CI_JOB_TOKEN，在Dockerfile中临时配置Git凭证：

  ARG CI_JOB_TOKEN
  RUN git config --global credential.helper '!f() { echo "username=gitlab-ci-token"; echo "password=$CI_JOB_TOKEN"; }; f'
  

内容的提问来源于stack exchange，提问作者rbaleksandar