Gitlab流水线运行失败但GCP Cloud Run实际部署成功如何修复

你遇到的是典型的本地Gitlab Runner侧gcloud命令状态异常，但GCP Cloud Build侧实际执行成功的问题，核心原因和对应修复方式如下：

1. 移除不必要的Docker依赖配置 #

你当前的.gitlab-ci.yml配置了docker:dind服务和顶层docker:latest镜像，但是你用的是gcloud builds submit把构建任务全量提交到GCP Cloud Build执行，本地Gitlab Runner环境根本不需要Docker能力，多余的配置反而会引发环境冲突导致gcloud命令退出异常。
修复后的.gitlab-ci.yml精简版如下：

# File: .gitlab-ci.yml
stages:
  - deploy-test
  - deploy-prod

deploy-test:
  stage: deploy-test
  image: google/cloud-sdk:alpine # 用alpine版体积更小，运行速度更快
  script:
    # 正确写入带换行的服务账号密钥，避免echo命令吃掉换行符
    - cat > gcloud-service-key.json <<< "$GCP_SERVICE_KEY"
    - gcloud auth activate-service-account --key-file gcloud-service-key.json
    - gcloud config set project $GCP_PROJECT_ID
    # 增加--no-stream-logs参数，不拉取实时构建日志，避免网络波动导致命令失败
    - gcloud builds submit . --config=cloudbuild.yaml --no-stream-logs

2. 修复服务账号密钥写入方式 #

你原来用echo $GCP_SERVICE_KEY > gcloud-service-key.json的写法在多数Shell环境下会自动抹除密钥内容里的换行符，虽然部分情况下gcloud仍然可以成功鉴权，但会产生不可预知的警告导致命令退出码非0，改用cat >的方式可以完整保留密钥的原始格式。

3. 关闭构建日志实时拉取 #

gcloud builds submit默认会实时拉取GCP侧的构建日志，如果Gitlab Runner和GCP之间的网络存在波动、或者防火墙限制了长连接，会导致日志拉取中断，此时即使GCP侧构建部署成功，本地gcloud命令也会返回非0退出码导致流水线报错。添加--no-stream-logs参数可以关闭日志实时拉取，命令只会等待构建最终状态返回，不会因为日志传输中断报错。

4. 可选：添加构建状态校验 #

如果需要严格确认构建确实成功，可以改用异步提交+主动等待的方式，比默认的同步提交更稳定：

script:
  # ... 前面的鉴权、配置步骤保持不变
  - BUILD_ID=$(gcloud builds submit . --config=cloudbuild.yaml --async --format='value(id)')
  - gcloud builds wait $BUILD_ID

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