GitHub Actions脚本中执行xcrun simctl bootstatus <udid> -b报"invalid device"错误的排查求助

根据你描述的问题，这种同一UDID在单独步骤能正常执行、但在脚本内报错的情况，大概率是环境上下文或变量处理的细微差异导致的。我整理了几个最可能的原因和对应的解决思路：

1. UDID变量包含多余空白字符（最常见） #

你的脚本中获取UDID的命令可能返回了带换行、空格或制表符的结果，导致$udid变量包含多余字符：

• 当你在脚本内执行xcrun simctl bootstatus $udid -b时，这些多余字符会被当作UDID的一部分传递给simctl，自然找不到对应设备；
• 但通过GITHUB_OUTPUT传递到单独步骤时，GitHub Actions会自动修剪变量前后的空白字符，所以此时UDID是干净的，执行成功。

验证方法：在脚本中添加一行输出，查看UDID的实际内容：

udid=$(command that returns udid)
echo "Raw UDID: '$udid'"  # 查看是否有多余的换行或空格
echo "udid=$udid" >> $GITHUB_OUTPUT
xcrun simctl bootstatus $udid -b

如果输出类似Raw UDID: '123456-7890 '（UDID后带换行），就说明有多余字符。

解决办法：获取UDID时直接修剪空白字符：

# 方法1：用xargs自动修剪前后空白
udid=$(command that returns udid | xargs)
# 方法2：用tr删除换行和回车
udid=$(command that returns udid | tr -d '\n\r')
# 方法3：用bash的变量替换去除空白
udid=$(command that returns udid)
udid=${udid//[$'\t\r\n']}

2. 脚本与单独步骤的Xcode环境上下文不一致 #

GitHub Actions的macOS runner可能安装了多个Xcode版本，若脚本内的xcrun指向的Xcode版本与单独步骤的不同，就会出现“设备列表能看到UDID，但bootstatus找不到”的矛盾：

• 单独步骤可能继承了runner的默认Xcode环境（或你通过actions/setup-xcode设置的版本）；
• 脚本内的PATH变量被意外修改，导致调用了其他版本的xcrun，对应的simctl管理的设备池不同。

验证方法：在脚本和单独步骤中分别输出Xcode路径：

# 脚本内添加
echo "Script Xcode path: $(xcode-select -p)"
echo "Script xcrun version: $(xcrun --version)"

# 单独步骤添加
- run: |
    echo "Step Xcode path: $(xcode-select -p)"
    echo "Step xcrun version: $(xcrun --version)"
  shell: bash

如果两者输出的Xcode路径不同，就说明环境不一致。

解决办法：在脚本开头显式设置Xcode路径，与runner环境保持一致：

# 用runner默认的Xcode路径，或你通过setup-xcode设置的版本
sudo xcode-select -s /Applications/Xcode_15.0.app/Contents/Developer
# 或者直接使用绝对路径调用xcrun
/Applications/Xcode_15.0.app/Contents/Developer/usr/bin/xcrun simctl bootstatus $udid -b

3. 脚本执行时设备未完全就绪（小概率） #

虽然你提到simctl list能看到该设备，但获取UDID后立即执行bootstatus，设备可能还处于“未初始化完成”的状态；而单独步骤执行时，设备已经完成就绪，所以能成功启动。

解决办法：在脚本内添加短暂延迟，或先尝试预激活设备：

udid=$(command that returns udid)
echo "udid=$udid" >> $GITHUB_OUTPUT
# 延迟2秒等待设备就绪
sleep 2
# 先尝试boot命令激活设备，再执行bootstatus
xcrun simctl boot $udid
xcrun simctl bootstatus $udid -b

总结 #

优先排查UDID的空白字符问题，这是这类场景下最常见的诱因。如果验证后不是这个问题，再检查Xcode环境的一致性。按照上面的方法调整后，应该能解决脚本内xcrun simctl bootstatus报错的问题。

内容来源于stack exchange