Gitlab 构建设计:从本地图像进行测试?

Ber*_*aug 5 gitlab gitlab-ci

I\xe2\x80\x99m 使用 docker-in-docker (通过服务)构建管道,docker:20.10-dind应该:

\n
    \n
  • 从基础镜像+插件文件构建docker镜像
  • \n
  • 使用该映像运行单元和集成测试(需要 mariadb 服务,因此我\xe2\x80\x99d 喜欢将其干净地分离到测试阶段)
  • \n
  • 如果测试成功,则将图像推送到注册表来发布图像
  • \n
\n

在构建过程中,我将图像标记为以下全部:

\n
    \n
  • 名称:最新
  • \n
  • 注册表/项目ID/名称:最新
  • \n
  • 注册表/projectid/名称:基本映像版本
  • \n
\n

在测试阶段,我告诉它使用image: name:latest标签(即没有远程注册表信息)作为运行作业的映像。

\n

我希望它使用本地 D-in-D 服务中存在的图像,但它没有 \xe2\x80\x99t,并且出现以下错误:

\n
ERROR: Job failed (system failure): failed to pull image "name:latest" with specified policies [always]: Error response from daemon: pull access denied for name, repository does not exist or may require 'docker login' (manager.go:205:0s)\n
Run Code Online (Sandbox Code Playgroud)\n

有没有什么方法可以仅更改一个管道的拉取策略,或者甚至更好地仅更改管道中的一个阶段/作业的拉取策略?

\n

我能找到的唯一地方是config.toml整个构建运行程序,这实际上不是我正在寻找的粒度。

\n

如果它\xe2\x80\x99s绝对不可能,我可以将图像标记为registry/project/name:candidate构建中的图像并推送它+然后再次拉取它进行测试。

\n

然而,这偶尔会留下损坏的图像,而且会非常浪费,并使我的构建速度变慢,所以我\xe2\x80\x99d真的不喜欢拉取已经存在于docker服务中的图像来进行构建。

\n

Dat*_*atz 2

抱歉,答案是否定的。

唯一的方法是标记图像并将其推送到注册表,然后再次拉取以进行测试。

测试后,您可以从注册表中删除这个标签。或者您设置一个清理策略,偶尔删除这些标签。

  • 我最终通过在一个阶段中进行构建和测试来“修复”它,因为我无论如何都不需要推送损坏的图像 (2认同)