Délai d'attente lors de l'exécution de tests xcodebuild sous Xcode 6 via SSH
Il semble que je rencontre des problèmes avec l’intégration de Xcode6 avec Jenkins, j’ai actuellement cette configuration et travaille avec Xcode 5.
Avec xcode 6 s'exécutant à distance via SSH, le délai d'expiration du simulateur a du succès.
Commande
xcodebuild -workspace PROJECTNAME.xcworkspace -scheme BGO_Tests -destination 'platform = Simulateur iOS, nom = -iPhone 5s' -derivedDataPath ./Build clean test
2014-08-19 10: 46: 36.591 xcodebuild [33966: 381f] iPhoneSimulator: délai d'attente de> 120 secondes pour le> démarrage du simulateur, l'état actuel est 1.
Échec du test: La cible de test BGO_Tests a rencontré une erreur (délai d'attente de 120 secondes pour le démarrage du simulateur, état actuel: 1
Testé avec le récent Xcode 6 beta 6
J'ai finalement réussi à trouver une bonne solution simple. JNLP causait de nombreux problèmes avec notre serveur Jenkins.
Solution de contournement du délai d'attente SSH via https://corner.squareup.com/2015/07/ios-build-infrastructure.html
"Mavericks (10.9) et Yosemite (10.10) déterminent si un processus peut accéder aux points d’accessibilité via la filiation du processus d’accès. En plaçant launchd dans la liste des processus autorisés, les processus lancés via SSH ou Jenkins ont accès à l’accessibilité. Pour ce faire, vous pouvez modifier la base de données TCC, conformément à la présente Gist. Un redémarrage est nécessaire pour que les modifications prennent effet. "
#!/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"
Mise à jour 8/02/2016 Ceci est maintenant corrigé dans Xcode 7.2.1 ("L’outil de ligne de commande‘ xcodebuild test ’n’a plus de temps pour attendre le lancement de Simulator.app")
Remarque: les noms de périphérique ont changé dans Xcode 7, vous ne les spécifiez donc plus avec iPhone 5 (9.1 Simulator) mais plutôt iPhone 5 (9.1).
Utilisez xcrun instruments -s pour obtenir la liste actuelle des périphériques, puis pré-lancez-la en utilisant:
xcrun instruments -w "iPhone 5 (9.1)" || echo "(Pre)Launched the simulator."
Prelaunching
Je suis arrivé au point où ce que je proposais ne fonctionnait plus. En plus des modifications mentionnées ici, vous devez lancer le simulateur que xcodebuild attend AVANT QUE xcodebuild ne soit exécuté:
# 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>'
Ancien post
Ce bogue est corrigé dans Xcode 6.3 et supérieur. Si vous rencontrez des problèmes similaires dans le Xcode plus récent, il s'agit probablement d'un autre bogue.
Suivi Apple concernant l'ID de bogue 18001199:
Le contexte fourni par LaunchDaemons n'est pas pris en charge pour l'exécution de l'interface graphique applications. Le service SSH et la configuration par défaut de Jenkins sont tous deux mis en œuvre comme LaunchDaemons. Dans les versions antérieures de Xcode 5 xcodebuild pourrait exécuter des tests sur le simulateur iOS dans ce contexte, mais cela n'a jamais été une configuration prise en charge, et comme vous l'avez noté ne fonctionne plus à partir de Xcode 6.
Contrairement à LaunchDaemons, LaunchAgents fournit un contexte dans lequel vous pouvez exécuter Applications graphiques - Si l'utilisateur est connecté à ce moment-là, avec une fenêtre serveur/session Aqua. Conversion de votre configuration Jenkins à partir de être un LaunchDaemon être un LaunchAgent éviterait le reporté problème. Vous pouvez également utiliser launchd pour exécuter des tests sur le simulateur iOS depuis une session SSH, soit en créant un LaunchAgent, soit manuellement en chargeant/en commençant ou en utilisant "launchctl submit".
Ok, après avoir approfondi les commentaires (beaucoup grâce à Opal ), j'ai découvert que lancer l'esclave via JNLP fonctionnait plutôt.
Comme beaucoup de personnes l'ont mentionné, il n'est actuellement pas possible d'exécuter le test unitaire sur SSH. Vous pouvez donc vous tourner vers l'agent JNLP pour l'instant jusqu'à ce que Apple le corrige.
Si la connexion avec JNLP ne résout toujours pas le problème, essayez la solution mentionnée dans ce commentaire .
c'est-à-dire: exécutez-les en ligne de commande:
DevToolsSecurity -enable
Sudo dscl. -append/Groups/_developer GroupMembership "utilisateur-qui-court-le-sim"
security autorisationdb write system.privilege.taskport est développeur
Voir les références ici et ici .
J'ai récemment découvert que si vous installez une nouvelle version de Xcode et ne le lancez pas. Le simulateur peut commencer à nouveau à expirer. Pour résoudre ce problème, j'ai dû lancer manuellement Xcode et installer les outils supplémentaires demandés.
J'ai fini par résoudre ceci sur Xcode 5 en faisant les étapes ici , en exécutant essentiellement:
Sudo security authorizationdb write system.privilege.taskport allow
Cela éliminera une classe de ces popups d'authentification. Vous devrez également exécuter:
Sudo DevToolsSecurity -enable
Cependant, une fois que j'ai mis à niveau vers Xcode 6, j'ai maintenant un blocage infini lorsque j'essaie d'exécuter des tests xcodebuild sur SSH. Ils continuent à fonctionner correctement tant que je suis connecté à la console et que je les exécute à partir du clavier.
J'ai rencontré le même problème. Ma théorie de travail est que SSH sur OSX est démarré en tant que LaunchDaemon et que LaunchDaemons n'est pas autorisé à présenter une interface utilisateur; Référence .
J'ai pu contourner le problème en utilisant Java Web Start pour lancer l'esclave Jenkins. J'ai ensuite installé l'esclave Jenkins en tant que service launchd.
Malheureusement, l’esclave Jenkins s’installe lui-même en tant que -vous l’avez deviné - LaunchDaemon, ce qui pose exactement le même problème: ne pas pouvoir lancer les tests; Référence .
J'ai résolu ce problème en déplaçant les fichiers plist et jar du fichier Jenkins Slave LaunchDaemon de /System/Library/LaunchDaemons dans ~/Library/LaunchAgents et mis à jour les chemins d'accès du fichier plist.
Cela m’a finalement permis d’exécuter des tests XCode6 (Beta6) sur un esclave jenkins OSX.
J'ai déjà vu cette erreur auparavant. Une des possibilités est que, puisque vous avez probablement téléchargé la version bêta de Xcode6 à partir d'Internet (et non de l'appstore car il n'est pas encore disponible), la machine sur laquelle vous essayez de l'exécuter affichera un message vous demandant si vous voulez vraiment ouvrir cette application comme sur Internet.
La même chose se produira lorsque xcodebuild essaiera de lancer l'application de simulateur iPhone.
Une chose que vous pouvez essayer est de partager l'écran avec la machine et de cliquer sur "Ouvrir" dans cette fenêtre contextuelle.
Si cela ne fonctionne toujours pas, j'essaierais de:
- Réinitialiser le contenu et les paramètres du simulateur
- Redémarrez la machine et assurez-vous qu'aucun simulateur n'est en cours d'exécution au démarrage (vous pouvez simplement choisir de ne pas rouvrir une application lors du redémarrage)