CloudBuild构建完成后GitHub PR工作流仍排队运行是什么原因？

• 回调链路故障：CloudBuild执行完成后，需要通过绑定的GitHub App授权向GitHub API发起状态回调，同步PR检查项的运行结果。如果回调过程中出现GCP到GitHub的网络波动、GitHub API临时限流、绑定的GitHub App权限过期/缺少「检查状态写入」权限，都会导致同步失败，GitHub收不到完成信号就会一直展示任务处于运行/排队状态。
• 配置缺失回调逻辑：如果你的cloudbuild.yaml仅配置了镜像构建、Cloud Run部署步骤，没有额外配置主动向GitHub上报检查状态的步骤，且触发路径为GitHub Actions主动调用CloudBuild，GitHub侧的工作流Job会默认等待CloudBuild返回的执行结果信号，缺少主动轮询CloudBuild状态并回写的逻辑时，Job会一直挂起直到达到账号配置的最大运行时长。
• 分支保护规则不匹配：如果你的仓库dev分支配置了分支保护规则，要求指定名称的检查项通过，但CloudBuild上报的检查项名称和规则要求的名称不一致，GitHub会一直等待不存在的检查项完成，导致PR状态持续卡在运行中。
• GitHub工作流配额不足：当你的账号/组织同时运行的工作流任务超过配额上限时，新提交的工作流任务会进入全局排队队列，此时就算触发的CloudBuild已经执行完成，GitHub侧的工作流任务本身还没有被调度分配到运行器，因此会持续显示排队状态，未被调度的任务不会出现在Actions的运行任务列表中，因此你找不到取消入口。
• 触发器配置错误：如果你的CloudBuild PR触发器仅配置了监听PR创建/更新事件触发构建，未配置构建结束后同步状态回GitHub的规则，也会导致两端状态断连。

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