AzureDevOps中Fastlane上传TestFlight报错：软件资产已成功交付

我们在AzureDevOps流水线中使用fastlane将.ipa文件上传至TestFlight，此前运行正常，但近期部分构建未出现在TestFlight中。从日志发现，未显示的构建会出现如下日志：

2022-10-25T03:41:38.0866400Z [03:41:38]: The software asset has already been successfully delivered.
而成功显示的构建无该日志。我们每次运行都会自动递增构建号，不会出现重复版本，使用的fastlane命令如下（部分ID已混淆）：

[command]/usr/local/lib/ruby/gems/2.7.0/bin/fastlane pilot upload -u *** -i /Users/runner/work/r1/a/output/myapplication.ipa -q XXXXXXXXX -a com.myapplication.app --skip_submission true --skip_waiting_for_build_processing true -p 0123456899 -asc_provider XXXXXXXX

尽管每次都递增了构建号，但苹果后台判定当前上传的IPA与已存在的某一构建资产完全一致，这是触发该日志的核心原因，具体场景包括：

• 打包环节生成了重复二进制：代码无实际变更时，重新打包仅修改构建号，但IPA的签名哈希、资源文件哈希等核心标识未变，苹果服务器会判定为同一资产。
• --skip_waiting_for_build_processing true参数引发时序冲突：该参数让fastlane上传后立即结束流程，若前一次上传的构建仍在苹果后台处理中，后续同内容构建会被误判为重复。
• 苹果后台缓存或同步异常：TestFlight服务器偶尔会出现资产识别缓存问题，将新构建错误判定为已存在的旧资产。

• 优化打包流程：确保每次构建有代码/资源的实际变更；或在打包时强制更新Info.plist中的唯一标识（如添加构建哈希），让IPA的二进制哈希值真正唯一。
• 移除--skip_waiting_for_build_processing true参数：让fastlane等待苹果后台完成构建处理后再结束流水线，避免同内容构建在处理阶段重复上传。
• 验证IPA唯一性：使用命令codesign -dv --verbose=4 your.ipa查看IPA的签名哈希，对比已上传构建的对应信息，确认二进制是否真的不同。
• 清理TestFlight旧构建：若为苹果后台缓存问题，可在App Store Connect中删除疑似重复的旧构建后重新上传。

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