有位同事找我帮忙， 说是好着急哦，很多东西需要发布， 不过之前一直跑的好好的Github Action pipeline却出错了， 而且看起来跟权限有关。大概意思就是， 这问题就是你们搞坏的啦，赶紧帮我去搞定。

我一看这出错信息：

 

ERROR: (gcloud.container.clusters.get-credentials) ResponseError: code=403, message=Required "container.clusters.get" permission(s) for "projects/***/locations/XXXXX/clusters/XXXX-cluster".

 

好家伙，看起来就是由于本部门不小心搞出来的飞机。 虽然查看权限觉得没有任何问题的情况下，还是先简单暴力再赋予了K8S对应的权限。  尝试了一下， 还是不行。

既然加权限行不通， 还不会是workload identity配置有问题了吧， 造成里边的KSA所对应的外边的SA没有匹配起来。花了很长时间坚持，也没发现错误。后来想想，不应该在这方面花费时间， 因为从错误上来看， 还根本没有跑到K8S的运行阶段。人家是获取cluster的credential就出错了。

不得已， 只能是想想为什么会出错，到底是什么改变了才造成这种错误。同时也咨询了同事，他们也根本没有pipeline方面的改动。后来只能是去对比一下之前跑成功的pipeline跟最近失败的pipeline进行对比一下， 不对比不知道，对比起来吓一跳。发现之前成功的build里边都有一个warning:

 

"service_account_key" has been deprecated. Please switch to using google-github-actions/auth which supports both Workload Identity Federation and Service Account Key JSON authentication. For more details, see https://github.com/google-github-actions/setup-gcloud#authorization

 

而失败的那个有两个这样的warning. 就这这样的信息， 我去对应的github仓库去看。乖乖，人家早已经把这个参数给淘汰了 https://github.com/google-github-actions/setup-gcloud/commit/a56ad5fd2c0ec683bcb5eb299ba13820f2be8a0a 我把对应的github Action 换成没有出错前的版本： setup-gcloud@b8f95eb7d716bf9a715eafd169162b93f69ed520  测试一下， 搞定了。

原来， 很多我们认为不变的东西其实就是一个变化的过程。比如说这件事情上使用 latest就是这样的例子。没有最新， 只有更新。你所使用的依赖是不可靠，是会变化的，那我们有什么理由期待不变的结果呢？