Timeout when running xcodebuild tests under Xcode 6 via SSH

Question

It seems I am having problems integrating Xcode6 with jenkins, I currently have this setup and working with Xcode 5.

When xcode 6 works remotely via SSH, the simulator timeout, when I run locally, it succeeds.

Team

xcodebuild -workspace PROJECTNAME.xcworkspace-scheme BGO_Tests -destination 'platform = iOS Simulator, name = iPhone 5s' -derivedDataPath./Build clean test

2014-08-19 10: 46: 36.591 xcodebuild [33966: 381f] iPhoneSimulator: timeout 120 seconds for> simulator to load, the current state is 1.

Test failed: Target test BGO_Tests detected an error (timeout 120 seconds to load the simulator, current state 1

Tested with recent Xcode 6 beta 6

Answer 1

I finally managed to find a good simple solution. JNLP caused numerous problems with our jenkins server.

Workaround for SSH timeout through https://corner.squareup.com/2015/07/ios-build-infrastructure.html

"Mavericks (10.9) and Yosemite (10.10) determine whether a process can access the access hooks through the initial state of the access process. By placing launchd in the list of allowed processes, processes running through SSH or Jenkins have access to intercept the system. For of this, you can modify the TCC database according to this principle: a reboot is required to make changes to the force.

#!/bin/bash # This will add lauchd to the list of allowed processes for accessibility access sudo sqlite3 /Library/Application\ Support/com.apple.TCC/TCC.db "INSERT or REPLACE INTO access VALUES('kTCCServiceAccessibility','/sbin/launchd',1,1,1,NULL)" # This outputs the rows in the TCC database sudo sqlite3 /Library/Application\ Support/com.apple.TCC/TCC.db 'select * from access' echo "Restart is required for these changes to take effect" 

Update 8/02/2016 This is now fixed in Xcode 7.2.1 (The "command line tool" xcodebuild test will no longer wait for Simulator.app to start)

Answer 2

Note: device names are changed in Xcode 7, so you no longer specify them with iPhone 5 (9.1 Simulator) , but rather iPhone 5 (9.1) .

Use xcrun instruments -s to get the current list of devices, and then you can pre-launch it using:

 xcrun instruments -w "iPhone 5 (9.1)" || echo "(Pre)Launched the simulator." 

---

Prelaunching

I got to the point that what I suggested there didn’t work anymore. In addition to making the changes mentioned here, you need to run the simulator. Xcodebuild is waiting BEFORE . Xcodebuild launched:

 # First get the UDID you need xcrun instruments -s # Then launch it open -a "iOS Simulator" --args -CurrentDeviceUDID <sim device UDID> # and wait some time.... sleep 5 # Then launch your unit tests xcodebuild [...] -destination 'platform=iOS Simulator,name=<device name matching the UDID>' 

Old post

This bug is fixed in Xcode 6.3 and above. If you encounter similar problems in the new Xcode, this is probably another mistake.

Apple is tracking error ID # 18001199:

The context provided by LaunchDaemons is not supported to launch the Application GUI. SSH service and default setting for Jenkins: both implemented as LaunchDaemons. In earlier versions of Xcode 5, in this context, xcodebuild can run tests on the iOS simulator, but which was never supported, and as you noticed, it no longer works with Xcode 6.

Unlike LaunchDaemons, LaunchAgents provides a context in which you can run GUI Applications - if the user is logged in at that time, with the server / Aqua window. Converting Jenkins configuration from being LaunchDaemon to becoming LaunchAgent is a question. You can also use launchd to run tests on an iOS simulator from an SSH session, either by creating a LaunchAgent, either manually downloading / launching, or using the "launchctl submit".

Well, after we work a bit around the comments (thanks to Opal ), I found out that running a slave device through JNLP works.

As many people have mentioned, it is currently not possible to run unit test on top of SSH, so you can now contact the JNLP agent until Apple fixes it.

---

If connecting to JNLP still does not solve it, try the solution mentioned in this comment .

ie: Run them at the command prompt:

DevToolsSecurity -enable

sudo dscl. -append / Groups / _developer GroupMembership "user-that-runs-the-sim"

security authorizationdb write system.privilege.taskport is-developer

See links here and here .

I recently found out that if you install a new version of Xcode and do not start it. The simulator can start the countdown again. To solve this problem, I had to manually start Xcode and install the additional tools that it requested.

Answer 3

I ended up solving this problem on Xcode 5 by following the steps here , essentially working:

 sudo security authorizationdb write system.privilege.taskport allow 

This will exclude one class of these pop-ups. You also need to run:

 sudo DevToolsSecurity -enable 

However, as soon as I upgraded to Xcode 6, now I get endless hangs when I try to run xcodebuild tests via SSH. They continue to work fine as I enter the console and launch them from the keyboard.

Answer 4

I ran into the same problem. My theory of operation is that SSH on OSX runs as LaunchDaemon, and LaunchDaemons cannot represent the user interface; Link

I was able to get around this problem using Java Web Start to start a Jenkins subordinate. Then I installed the Jenkins workstation as a startup service.

Unfortunately, a Jenkins subordinate sets himself as "you guessed it" - LaunchDaemon, which leads to the same problem: tests cannot be run; Link

I worked on this issue by moving the Jenkins Slave LaunchDaemon plist and jar files in /System/Library/LaunchDaemons to ~/Library/LaunchAgents and updating the paths inside the plist file.

This allowed me to run XCode6 tests (Beta6) on the OSX slave jenkins.

Answer 5

I saw this error before, one of the possibilities is that since you probably downloaded the beta version of Xcode6 from the Internet (and not in the appstore, since it is not there yet), the machine on which you are trying to run it will show a pop-up a window asking you if you really want to open this application from the Internet.

The same thing happens when xcodebuild tries to launch the iPhone simulator application.

One thing you might want to try is to share the screen with the machine and click "Open" in this pop-up window.

If this still does not work, I would try:

• Reset Simulator Content and Settings
• Restart your computer and make sure that there is no simulator during startup (you may just not have to open the application when you restart)