Je tente de mettre en place des tests automatisés pour mon application iOS à l'aide de TeamCity. Actuellement, mon agent construit, mais une fois la dernière cible et la dernière codesign, il est suspendu et affiche les éléments suivants:
xcrun simctl shutdown %env.simulator_guid% killall Simulator killall com.apple.CoreSimulator.CoreSimulatorService
6 Réponses :
Cela semble assez étrange, mais il suffit de réinitialiser le simulateur le corrige habituellement. Nous rencontrons souvent la même erreur sur notre propre système CI.
Essayez simulateur-menu -> Réinitialiser le contenu et les paramètres, puis redémarrez le simulateur.
Vous pouvez l'appliquer sur la ligne de commande, mais je ne le recommanderai pas, car il ralentira votre construire remarquablement.
Wow! Merci! Cela a parfaitement fonctionné. Je mettrai à jour mon message avec exactement ce que j'ai fait pour aider tous les futurs visiteurs.
De rien! Votre nettoyage automatisé de simulateur sur la ligne CMD semble très similaire à ce que nous avons essayé il y a quelque temps, mais nous avons rencontré des problèmes de performance majeurs avec cela. Heureux d'entendre que votre approche semble être assez rapide. Je vais essayer aussi!
Ce n'était pas aussi rapide que je pensais initialement. Il a ajouté 4 minutes à mon temps de construction. Cependant, c'est acceptable pour ce projet parce que je suis le seul dev et que l'attention de la machine de construction est indivisée. De plus, depuis que j'ai automatisé Carthage, ça construit un tas de choses de toute façon. C'est également une machine relativement lente, étant un montant minimalement spécifié 2011MBP (bien que 8G RAM et un SSD).
À propos, j'ai écrit un didacticiel de démarrage sur la configuration de TeamCity CI pour un projet IOS Xcode. Vous semblez assez bien informé que vous n'en avez pas besoin, mais si vous connaissez quelqu'un qui le fait peut être agréable de passer le long. De même, cette façon de visiter le thread peut le trouver. sosheskaz.github.io/2017/03/07/xcode- CI-Article.html
Super article, n'a jamais utilisé TeamCity avant le faveur de Hudson / Jenkins. Va essayer bientôt.
juste tuer et Réouverture Le simulateur a fonctionné pour moi.
J'ai eu une erreur similaire lors de la tentative d'exécution d'une application iOS dans le simulateur de Xcode 11.3.1. J'ai trouvé que reproduire le matériel virtuel peut résoudre ce problème un peu plus rapide que les autres solutions mentionnées sur cette page.
Lorsque je reçois le "chronométré en attente de simulator.app est prêt à devenir prêt" erreur dans xcode, le simulator.app a typiquement lancé mais ne montre aucun simulateur réel. Choix de matériel> périphérique> [Version OS] -> [Nom du simulateur] amène que le simulateur apparaisse et lance avec succès mon application lors de la prochaine tentative d'exécution.
Dans XCode 11.4 L'élément de menu Simulator a été déplacé vers Fichier> Ouvrir un périphérique> [Version OS] -> [Nom du simulateur]
Très bonne description. Pouvons-nous déterminer si ce problème est confiné à certains systèmes? Je vois ça seulement sur Mojave.
@matt Je vois cette question de manière fiable après chaque redémarrage sur MacOS 10.15.3 avec Xcode 11.3.1 (une configuration commune pour le moment que j'imagine). La seule chose roman à propos de ma configuration est que j'ai supprimé toutes les simulateurs de stock et a ensuite créé un simulateur unique iPhone 11 iOS 13.3 (aucune montre jumelé) à l'aide de la fenêtre "Périphériques et simulateurs".
J'ai eu un problème similaire. Je l'ai finalement résolu en retirant manuellement l'application à partir du périphérique simulé. Après cela, le simulateur a pu commencer à déboguer normalement.
Ce problème semble avoir été Résolu dans Xcode 11.5 Correction des problèmes où Xcode ne paraîtrait parfois d'exécuter une application dans un périphérique simulé, avec une erreur "chronométrée en attente de simulateur.app de devenir prêt".
Il existe un bogue dans Xcode 11.3 et plus tôt, ce qui pourrait manifester de cette façon si vous avez simulateur.app exécuté d'un autre Xcode. Il y a une petite fenêtre de course dans laquelle cela pourrait arriver. Qui a été corrigé dans Xcode 11.3.1.
mais ...
Il existe un bogue dans Xcode 11.3.1 et ultérieur (via Xcode 11.4.1 à partir de ce commentaire) qui se manifeste également. Pour contourner le problème, vous pouvez cliquer sur simulator.app dans le quai après son lancement (même s'il est au premier plan). Sinon, vous pouvez activer la synchronisation de pâte de pâte dans simulator.app via 'Edit -> Synchroniser automatiquement la carte de pâte'.
Wow, je n'ai jamais deviné la chose de synchronisation automatique de la pâte de pâte, cela a fonctionné pour moi.
Ouais, il y avait une défaillance lors de l'initialisation de la synchronisation de la pâte au lancement qui placez l'application dans un état gênant. Il a été corrigé dans Xcode 11.5+.
Merci Monsieur! "Synchroniser automatiquement la pâte de pâte" a également résolu le problème pour moi aussi.
Je n'ai pas trouvé une bonne solution pour résoudre la cause fondamentale de ce problème, mais j'ai trouvé un travail autour. Si vous ouvrez simplement un simulateur avant de construire votre application en Xcode, ce problème est contourné.
Vous pouvez également vérifier le menu fenêtre de l'application Simulator.
Il pourrait y avoir une ou plusieurs fenêtres simulatoires marquées comme à l'aide d'un Après avoir fermé toutes les fenêtres à l'aide d'un affichage externe, le simulateur commencera à fonctionner correctement.
Je suis incertain de la manière dont on peut sélectionner un écran externe pour un simulateur, mais cela m'est arrivé plusieurs fois et il suffit de quitter l'application Simulator n'a pas aidé. Je devais soit faire ce que je décris ci-dessus, soit redémarrer la machine. [affichage externe] . Lorsque vous sélectionnez une fenêtre dans le menu, rien n'apparaîtra, mais vous pourrez appuyer sur cmd-w pour le fermer.
Veuillez déposer un radar et inclure la sortie de SysDiagNose -q et des journaux de ~ / Bibliothèque / Journaux / Coresimulator.