GitLab CI/CD中如何使用GCP构建的镜像作为测试阶段镜像

一、授权拉取Artifact Registry镜像的可行方案 #

由于GitLab CI的image字段在job启动前就会完成解析拉取，无法直接在该字段中使用动态生成的GCP访问令牌，推荐以下两种非docker-in-docker的方案：

方案1：给GitLab Runner配置GCP服务账号权限 #

• 为运行CI任务的GitLab Runner绑定具备Artifact Registry读取权限的GCP服务账号（例如roles/artifactregistry.reader角色）。
• 若使用GCE虚拟机作为Runner，直接给实例附加对应服务账号；若使用容器化Runner，可通过挂载GCP服务账号密钥文件或借助Workload Identity（GKE环境下）实现身份认证。
• 配置完成后，Runner会自动拥有拉取镜像的权限，无需在job中额外处理认证流程。

方案2：在job内部完成镜像拉取与测试执行 #

放弃将测试镜像直接设为job的image，改为在job脚本中手动完成认证、拉取并运行容器：

1. 在CI变量中配置GCP服务账号密钥（如GCP_SERVICE_ACCOUNT_KEY），或通过Runner环境注入服务账号凭证。
2. 在test job的脚本中执行以下步骤：

   # 激活服务账号身份
   echo "$GCP_SERVICE_ACCOUNT_KEY" > key.json
   gcloud auth activate-service-account --key-file=key.json
   # 获取令牌并登录Artifact Registry
   gcloud auth print-access-token | docker login -u oauth2accesstoken --password-stdin [你的Artifact Registry域名]
   # 拉取镜像并执行测试命令
   docker run [你的Artifact Registry地址]/$CI_PROJECT_NAME:$CI_COMMIT_SHA [你的测试命令，如npm run test]
   

   注：若环境未安装docker，可替换为podman，命令逻辑保持一致。

二、指定具体镜像标签 #

$CI_COMMIT_SHA是GitLab CI的内置变量，在同一流水线的所有阶段中值保持一致，直接复用即可精准拉取build阶段推送的镜像：

• 若使用方案1，直接在image字段中引用变量：

  test:
    stage: test
    image: [你的Artifact Registry地址]/$CI_PROJECT_NAME:$CI_COMMIT_SHA
    script:
      - [你的测试命令]
  

• 若使用方案2，在脚本的容器运行命令中直接使用$CI_COMMIT_SHA作为标签即可。

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