【问题标题】:Jenkins with Xcode 8 and iOS Simulators: "Timed out waiting 120 seconds for simulator to boot, current state is 1"Jenkins 与 Xcode 8 和 iOS 模拟器:“超时等待 120 秒模拟器启动,当前状态为 1”
【发布时间】:2017-04-03 22:36:45
【问题描述】:

在将配置推送到我们的 CI 构建之前,我在我的机器上安装了一个本地版本的 Jenkins,一个带有 El Capitan 的 Macbook Pro,用于开发和调试目的。

最近,我认为自从升级到 Xcode 8 后,我们开始收到这个超时错误

iOSSimulator: 等待模拟器启动 120 秒超时,当前状态为 1。

测试的命令很简单xcodebuild,

xcodebuild clean test -scheme UnitTests -destination OS=9.3,name='iPhone 6' -sdk iphonesimulator -configuration Release ONLY_ACTIVE_ARCH=YES GCC_INSTRUMENT_PROGRAM_FLOW_ARCS=YES GCC_GENERATE_TEST_COVERAGE_FILES=YES -enableCodeCoverage=YES

但由于某种原因,最近开始出现此错误,这确实影响了能够运行此环境的本地版本。

【问题讨论】:

  • 该特定错误消息的潜在原因有很多。 Xcode 的核心是启动 Simulator.app,等待分布式通知,然后发送分布式通知,然后等待来自 CoreSimulator.framework 的 XPC 消息。此错误消息意味着它要么从未收到该 distnote,要么从未收到来自 CoreSimulatorService 的消息。如果您可以使用 sysdiagnose (sudo sysdiagnose -q) 并使用它和 ~seaders/Library/Logs/CoreSimulator 归档雷达,我很乐意看看。
  • 请注意,Xcode 8.2 进行了一些修复,以使 CI 更顺畅地解决此类问题。我们花了一些时间对模拟器中 CI 测试结果不可靠的一些原因进行分类和修复(包括对错误的真正修复以及为其他问题添加解决方法)。请注意,有一个问题(构建期间 ibtool 挂起)是 El Cap 中的一个内核错误,需要将主机操作系统升级到 Sierra 才能解决。
  • 嗨@JeremyHuddlestonSequoia,非常感谢您的回复,我们目前正在将我们的 CI 流程重新设计为更加分布式的方法,如果我们再次遇到这种情况,我肯定会得到一个系统诊断并归档一个雷达与日志。

标签: xcode jenkins ios-simulator xcode8 xcodebuild


【解决方案1】:

在我的情况下,这几乎与我安装 Jenkins 的方式有关。

我最初将 Jenkins 作为根进程安装在 /Library/LaunchDaemons/org.jenkins.plist 中。在该配置中,我的用户名在 UserName 键下,运行 whoami 表明这是正确的,但 OSX 如何运行 DaemonsLaunchAgents 是这里的关键。

在那个 plist 中,我还将 SessionCreate 设置为 true,这在这种情况下会导致问题。

这需要编辑/明确设置为“false”以确保<key>SessionCreate</key><false/>,还应检查用户和组名键是否是正确的登录用户,在我的情况下,一起开始我的 plist 看起来像,

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>UserName</key>
    <string>seaders</string>
    <key>GroupName</key>
    <string>staff</string>
    <key>SessionCreate</key>
    <false/>
    <key>EnvironmentVariables</key>
    <dict>
      <key>JENKINS_HOME</key>
      <string>/Users/Shared/Jenkins/Home</string>
    </dict>
    ...

对于我的情况,我需要将 Jenkins 配置 plist 从 root 的 LaunchDaemons 移动到我自己用户的 LaunchAgent 目录中,

$ # If jenkins is currently loaded from root, it needs unloading
$ sudo launchctl unload /Library/LaunchDaemons/org.jenkins.plist
$ sudo mv /Library/LaunchDaemons/org.jenkins.plist ~/Library/LaunchAgents/
$ # If jenkins had run under root, and used the regular log paths, we need to change the ownerships of a few places, my full command is
$ sudo chown -R seaders:staff ~/Library/LaunchAgents/org.jenkins.plist /var/log/jenkins/ /Users/Shared/Jenkins/Home
$ launchctl load ~/Library/LaunchAgents/org.jenkins.plist

这样做的总体效果是 Jenkins 真正以您的当前登录用户身份运行,进程是你的,用户名和组名是你的,并且你明确告诉它不要创建一个新的会话。

最重要的是,当用 iOS 签名,以这种方式运行时,你应该不再需要解锁钥匙串,但如果你这样做了,这是我们使用的过于偏执的脚本詹金斯,

$ security unlock-keychain -p ${USERPASS} ${HOME}/Library/Keychains/login.keychain
$ security list-keychains -s ${HOME}/Library/Keychains/login.keychain
$ security -v list-keychains -s ${HOME}/Library/Keychains/login.keychain
$ security list-keychains # so we can verify that it was added if it fails again
$ security -v unlock-keychain -p ${USERPASS} ${HOME}/Library/Keychains/login.keychain

但同样,如果您在将机器正确设置为允许签署应用程序的开发盒后遇到密钥签名错误,并且 Jenkins 真正以您的用户身份运行,您应该'实际上不再需要解锁钥匙串。

希望这可以帮助那些经历过移动 CI 地狱的其他人。

【讨论】:

  • 将其设为 LaunchAgent 意味着该作业仅在您的用户登录时才会加载(并因此运行)。另外请注意,将其设为 LaunchAgent 时不需要 UserName/GroupName。您应该能够将 jenkins 作为 LaunchDaemon 运行,我知道很多人都做得很好,但我个人不会。
  • 我们曾经将一些东西设置为 LaunchDaemons,但这就是我们在运行模拟器和访问 UI 层时遇到权限问题的地方。解锁钥匙链是解决其中一些问题的一件事,但不是我们遇到的所有问题,如果我们可以帮助它,我们宁愿不必解锁钥匙链,即使它确实解决了问题。
猜你喜欢
  • 2015-01-18
  • 2016-01-05
  • 2019-02-25
  • 2023-02-05
  • 1970-01-01
  • 2021-08-31
  • 1970-01-01
  • 2017-02-27
  • 2018-03-07
相关资源
最近更新 更多