同一Shell脚本在GitHub Actions与Bitbucket Pipeline运行结果差异咨询

• Git检出阶段的标签同步逻辑差异（最高概率诱因）
  两个平台的默认代码拉取策略存在本质区别：
  • GitHub Actions 为了缩短流水线启动时间，默认的checkout逻辑只会拉取当前触发分支的最近一次提交快照，不会主动把远程仓库的所有Git标签同步到本地工作目录。检测脚本在本地执行版本标签查询操作时，哪怕远程仓库已经存在对应版本的标签，本地查询结果也会为空，脚本会错误判定标签不存在，返回退出码0，完全无法触发预期的失败逻辑。
  • Bitbucket Pipeline 的默认代码拉取逻辑会同步完整的Git引用，包括全量提交历史和所有远程标签，脚本在本地执行标签查询时拿到的结果和远程仓库完全一致，自然可以正确识别已存在的版本标签，按预期返回退出码1。
• 管道操作吞掉脚本退出码
  如果GitHub Actions的工作流配置中，调用检测脚本的方式存在管道逻辑，比如通过./scripts/check-release.sh | tee run.log这类命令执行脚本，默认Shell只会返回管道链路中最后一个命令（也就是tee）的退出码，会把脚本本身返回的退出码1直接覆盖为0，导致平台判定步骤运行成功，不触发预期的失败。
• 执行路径不匹配
  如果GitHub Actions的工作流步骤默认路径和脚本预期的仓库根目录存在偏差，会导致脚本读取pom.xml失败、在非仓库路径下执行Git标签查询，最终拿到完全错误的检测结果。

快速排查方式：在GitHub Actions的对应执行步骤前增加调试命令，依次执行git tag -l、pwd、echo "上一步命令退出码: $?"，即可直接定位具体问题点。

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