Cloud Run从GitHub部署时未执行构建且无日志，Cloud Build触发器执行失败

遇到这种连日志都找不到的部署问题真的太头疼了！我之前帮朋友排查过类似的情况，给你整理几个针对性的排查方向，应该能帮你找到根因：

• 先确认GitHub私有仓库的授权状态
  因为你用的是私有GitHub仓库，Cloud Build要拉取代码必须有仓库的访问权限。建议你重新走一遍「连接仓库」的流程，在GitHub授权环节，务必确认勾选了当前要部署的私有仓库——有时候首次授权时可能只选了组织，没选具体仓库，或者后续仓库的权限设置被改动了，导致GCP拿不到代码。

• 检查Cloud Build服务账号的核心权限
  找到你的Cloud Build默认服务账号（格式一般是[项目编号]@cloudbuild.gserviceaccount.com），给它配置以下关键权限：

  • Cloud Run Admin：确保它有部署到Cloud Run的权限
  • Storage Object Admin：构建过程需要把中间镜像存到GCS，这个权限不能少
  • Source Repository Reader：保证它能正常读取外部源码仓库的内容
    另外要注意，别给错了账号！很多人会误操作给其他服务账号加权限，反而忽略了Cloud Build的默认账号。还要检查有没有组织政策限制了这个账号的权限继承。

• 排查Cloud Build触发器的触发条件
  虽然你选了Dockerfile构建，但要确认触发器的分支/标签是否和仓库实际分支匹配？比如你仓库默认是master分支，但触发器选的是main？或者有没有设置错误的路径过滤规则，导致代码变更根本没触发构建？另外Dockerfile的路径也要确认，比如你填的是./Dockerfile但实际在app/Dockerfile目录下，也可能导致触发异常。

• 去Cloud Logging里挖深层日志
  既然Cloud Build构建历史里看不到日志，直接去Cloud Logging搜索resource.type="cloud_build"，说不定能找到触发器尝试启动时的错误日志——比如权限不足、无法连接GitHub这类前置错误，这些日志不会出现在构建历史里，但会留在Cloud Logging中。

• 试试用CLI手动触发构建
  要是Web控制台一直没反应，不妨用gcloud CLI跑一次手动构建，命令大概是这样：

  gcloud builds submit --tag gcr.io/你的项目ID/自定义镜像名 --project 你的项目ID
  

  终端会直接输出错误信息，比Web控制台更直观，能快速定位是代码拉取、权限还是Dockerfile的问题。

备注：内容来源于stack exchange，提问作者timbeau