跨项目从Cloud Source Repository部署Cloud Function报错：获取源码失败

可能的原因 #

• 遗漏Cloud Functions专属服务代理账号权限：Project-A启用Cloud Functions API后会自动生成格式为service-{Project-A项目号}@gcf-admin-robot.iam.gserviceaccount.com的服务代理账号，该账号才是实际负责跨项目拉取Cloud Source Repository（CSR）源码的主体，你之前配置的权限列表中未包含该账号，是这类问题最常见的诱因。
• CSR访问路径配置错误：从NOTICE日志提取的源码路径https://source.developers.google.com/projects/Project-B/repos/my-repo/moveable-aliases/master/paths/my-folder可能存在拼写错误，比如分支名实际为main而非master、仓库名/Project-B项目ID拼写错误、my-folder路径不存在等。
• Project-B配置了VPC服务控制拦截：如果Project-B开启了VPC Service Controls且将CSR纳入服务边界，未将Project-A的相关服务账号/项目纳入访问允许列表时，跨项目拉取请求会被拦截。
• 权限生效延迟：刚配置的IAM权限最长可能需要2分钟才能全局生效，部署操作早于权限生效时间也会触发拉取失败。

排查方向 #

• 首先补全Cloud Functions服务代理账号权限：在Project-B的对应CSR仓库权限配置中，添加Project-A的service-{Project-A项目号}@gcf-admin-robot.iam.gserviceaccount.com账号，授予Source Repository Reader权限即可，无需更高权限，等待2分钟后重新尝试部署。
• 验证CSR路径有效性：直接将部署使用的CSR路径复制到浏览器访问，确认可以正常打开对应目录下的源码文件，排除分支、路径、项目ID、仓库名的拼写错误。
• 排查VPC服务控制限制：查看Project-B的VPC Service Controls配置，若存在针对CSR服务的边界策略，将Project-A的项目号、Cloud Functions服务代理账号、Cloud Build服务账号添加到策略的允许访问列表中。
• 模拟拉取验证权限：使用Project-A的Cloud Build服务账号身份，执行测试命令gcloud builds submit --repo=https://source.developers.google.com/projects/Project-B/repos/my-repo --branch=master，如果该命令报错则说明Cloud Build账号的跨项目CSR访问权限存在问题，可重新单独为该账号配置仓库级的读取权限。
• 检查源码路径合规性：确认目标路径下存在对应运行时要求的入口文件，比如Python运行时需要存在main.py，文件缺失也会触发源码拉取相关报错。

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