我之前帮团队排查过一模一样的问题，结合你的情况（本地部署正常、仅Pipelines失败），可以从这几个方向入手解决：

• 检查Pipelines使用的AWS IAM权限
  本地部署用的是你个人的AWS账号，权限通常比较完整，但Bitbucket Pipelines一般用专门的IAM角色，可能缺少读取应用版本的权限。你需要确保这个IAM角色拥有elasticbeanstalk:DescribeApplicationVersions权限，同时也要确认elasticbeanstalk:CreateApplicationVersion和s3:PutObject（上传归档用）的权限已经配置正确。

• 添加上传后的延迟等待
  AWS Elastic Beanstalk的应用版本创建和索引同步可能有几秒延迟，Pipelines的部署流程可能在版本刚上传就立刻发起查询，导致查不到。你可以在上传版本的步骤之后，添加一个简单的延迟命令，比如：

  sleep 15
  

  给AWS足够的时间同步版本信息，再执行后续的部署步骤。

• 修改应用版本的命名规则
  你当前的版本名是基于时间戳的app-f557-180519_203324，虽然概率低，但偶尔会出现Pipelines的时间和AWS服务器时间不一致，或者历史版本名重复的情况。可以在版本名里加入随机字符串或者Git commit哈希值，比如：

  VERSION_NAME="app-f557-$(date +%y%m%d_%H%M%S)-$(git rev-parse --short HEAD)"
  

  确保每个版本名都是唯一的，避免冲突。

• 对齐本地和Pipelines的EB CLI版本
  不同版本的Elastic Beanstalk CLI在处理版本上传和查询的逻辑上可能有差异。你可以在Pipelines的构建脚本里先检查EB CLI版本：

  eb --version
  

  和本地的版本对比，如果不一致，就在Pipelines里添加升级命令（比如用pip升级），确保两者版本一致。

• 通过AWS CloudTrail排查API细节
  去AWS控制台的CloudTrail服务，搜索对应的时间范围和相关API操作（比如CreateApplicationVersion和DescribeApplicationVersions），查看：

  • 创建版本的请求是否返回成功
  • 查询版本的请求里，应用名称、版本名称是否和创建时完全一致
    有时候可能是Pipelines配置里的应用名称写错了，或者参数传递有细微错误，本地没问题但CI环境里出错。

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