web-dev-qa-db-de.com

Timeout beim Ausführen von xcodebuild-Tests unter Xcode 6 über SSH

Ich habe Probleme mit der Integration von Xcode6 mit Jenkins. Derzeit habe ich dieses Setup und arbeite mit Xcode 5.

Mit xcode 6, das per Fernzugriff über SSH ausgeführt wird, läuft der Simulator Timeout ab. Wenn ich lokal laufe, ist er erfolgreich.

Befehl

xcodebuild -workspace PROJECTNAME.xcworkspace -scheme BGO_Tests -destination 'platform = iOS-Simulator, Name = abgelaufeneDataPath./Build-Bereinigung des iPhone 5s

19.08.2014 10: 46: 36.591 xcodebuild [33966: 381f] iPhoneSimulator: Zeitüberschreitung beim Warten von> 120 Sekunden für den> Simulator>, der aktuelle Status ist 1.

Test fehlgeschlagen: Das Testziel BGO_Tests hat einen Fehler festgestellt (Zeitüberschreitung beim Warten des Simulators auf 120 Sekunden, der aktuelle Status ist 1.)

Getestet mit der letzten Xcode 6 Beta 6

39
StackRunner

Ich habe endlich eine gute einfache Lösung gefunden. JNLP verursachte zahlreiche Probleme mit unserem Jenkins-Server.

Problemumgehung für SSH-Zeitüberschreitung über https://corner.squareup.com/2015/07/ios-build-infrastructure.html

"Mavericks (10.9) und Yosemite (10.10) legen fest, ob ein Prozess über die Abstammung des Zugriffsprozesses auf Zugänglichkeits-Hooks zugreifen kann. Wenn Sie" launchd "in die Liste der zulässigen Prozesse aufnehmen, haben über SSH oder Jenkins gestartete Prozesse Zugriff auf die Zugriffsmöglichkeit Über dieses System können Sie die TCC-Datenbank ändern. Dazu müssen Sie die GCC-Datenbank ändern. Ein Neustart ist erforderlich, damit die Änderung wirksam wird. "

#!/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 Dieses Problem wurde in Xcode 7.2.1 behoben ("Das Befehlszeilentool" xcodebuild test "wartet nicht länger auf den Start von Simulator.app, wenn es gestartet wird").

1
StackRunner

Hinweis: Die Gerätenamen wurden in Xcode 7 geändert, sodass Sie sie nicht mehr mit iPhone 5 (9.1 Simulator) angeben, sondern mit iPhone 5 (9.1)

Verwenden Sie xcrun instruments -s, um die aktuelle Liste der Geräte abzurufen. Anschließend können Sie sie mit folgendem Befehl starten:

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

Prelaunching

Ich kam an einen Punkt, an dem das, was ich unten vorgeschlagen hatte, nicht mehr funktionierte. Zusätzlich zu den hier genannten Änderungen müssen Sie den Simulator starten. Xcodebuild erwartet , BEVOR xcodebuild ausgeführt wird:

# 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>' 

Alte Post

Dieser Fehler wurde in Xcode 6.3 und höher behoben. Wenn bei neueren Xcode ähnliche Probleme auftreten, handelt es sich wahrscheinlich um einen weiteren Fehler.

Apple-Follow-up bezüglich Bug-ID # 18001199:

Der von LaunchDaemons bereitgestellte Kontext wird für die Ausführung der GUI .__ nicht unterstützt. Anwendungen. Der SSH-Dienst und die Standardeinstellung für Jenkins sind beide als LaunchDaemons implementiert. In früheren Versionen von Xcode 5 xcodebuild konnte in diesem Zusammenhang Tests auf dem iOS-Simulator ausführen, jedoch das war nie eine unterstützte Konfiguration, und wie Sie bemerkt haben funktioniert nicht mehr ab Xcode 6.

Im Gegensatz zu LaunchDaemons bieten LaunchAgents einen Kontext, in dem Sie .__ ausführen können. GUI-Anwendungen - wenn der Benutzer zu diesem Zeitpunkt angemeldet ist, mit einem Fenster Server/Aqua-Sitzung. Konvertierung Ihrer Jenkins-Konfiguration von ein LaunchDaemon zu sein, um ein LaunchAgent zu sein, würde das gemeldete .__ vermeiden. Problem. Sie können launchd auch zum Ausführen von Tests auf dem iOS-Simulator verwenden von einer SSH-Sitzung aus, entweder durch Erstellen eines LaunchAgent und manuell laden/starten oder mit "launchctl submit".

Ok, nachdem ich die Kommentare hier herumgegraben hatte (vielen Dank an Opal ), fand ich heraus, dass das Starten des Slaves über JNLP stattdessen funktioniert.

Wie bereits erwähnt wurde, ist es derzeit nicht möglich, den Unit-Test über SSH auszuführen. Daher sollten Sie sich zunächst an den JNLP-Agenten wenden, bis Apple ihn repariert.


Wenn die Verbindung mit JNLP immer noch nicht gelöst werden kann, versuchen Sie die in diesem Kommentar genannte Lösung. 

rufen Sie diese in der Befehlszeile auf:

DevToolsSecurity -fähig

Sudo dscl. -append/Groups/_developer GroupMembership "Benutzer, der die Sims ausführt"

sicherheit Authorizationdb schreiben system.privilege.taskport ist-Entwickler

Siehe Referenzen hier und hier .

Ich habe kürzlich herausgefunden, dass wenn Sie eine neue Version von Xcode installieren und sie nicht starten. Der Simulator startet möglicherweise wieder ab. Um dieses Problem zu lösen, musste ich Xcode manuell starten und die zusätzlichen Tools installieren, die es angefordert hat.

31
Michael Loo

Letztendlich löste ich das auf Xcode 5 durch hier die Schritte und lief im Wesentlichen: 

Sudo security authorizationdb write system.privilege.taskport allow

Dadurch wird eine Klasse dieser Authentifizierungs-Popups entfernt. Sie müssen auch ausführen:

Sudo DevToolsSecurity -enable

Nach dem Upgrade auf Xcode 6 bekomme ich jedoch einen unendlichen Hang, wenn ich versuche, xcodebuild-Tests über SSH auszuführen. Sie laufen einwandfrei weiter, solange ich an der Konsole angemeldet bin und sie von der Tastatur aus ausführen. 

5
Tad

Ich bin auf die gleiche Ausgabe gestoßen. Meine Theorie ist, dass SSH unter OSX als LaunchDaemon gestartet wird und LaunchDaemons keine UI präsentieren dürfen. Referenz .

Ich konnte das Problem umgehen, indem ich Jenkins Slave mit Java Web Start startete. Ich habe dann den Jenkins-Slave als Launchd-Dienst installiert. 

Leider installiert sich der Jenkins-Sklave dann als LaunchDaemon, wie Sie es sich gedacht haben, was zu demselben Problem führt, dass die Tests nicht gestartet werden können. Referenz .

Ich habe dieses Problem umgangen, indem ich die Plenk- und JAR-Dateien von Jenkins Slave LaunchDaemon in /System/Library/LaunchDaemons in ~/Library/LaunchAgents verschoben und die Pfade in der Plist-Datei aktualisiert habe.

Das erlaubte mir schließlich, XCode6 (Beta6) Tests auf einem OSX-Jenkins-Slave auszuführen.

3
Mark

Ich habe diesen Fehler schon einmal gesehen. Eine Möglichkeit ist, dass Sie wahrscheinlich die Xcode6-Betaversion aus dem Internet heruntergeladen haben (nicht im Appstore, da sie noch nicht verfügbar ist), und die Maschine, auf der Sie sie ausführen möchten, zeigt ein Popup an, in dem Sie gefragt werden, ob Sie möchten diese App wirklich aus dem Internet öffnen.

Dasselbe wird passieren, wenn xcodebuild versucht, die iPhone-Simulator-App zu starten.

Eine Sache, die Sie vielleicht ausprobieren möchten, ist, den Bildschirm mit dem Computer zu teilen und in diesem Popup auf "Öffnen" zu klicken.

Wenn das immer noch nicht funktioniert, würde ich versuchen:

  1. Setzen Sie den Inhalt und die Einstellungen des Simulators zurück
  2. Starten Sie den Computer neu und stellen Sie sicher, dass beim Starten kein Simulator ausgeführt wird (Sie können beim Neustart einfach keine App öffnen.)
0
Michael Loo