xcodebuild dit ne contient pas de schéma
J'ai un problème de curiosité.
J'ai un projet sur lequel j'ai travaillé et que j'ai toujours construit à partir de l'EDI XCode, et cela a bien fonctionné. Maintenant, je suis en train de configurer Bamboo pour construire le projet et, en tant que tel, je le construis depuis la ligne de commande.
Le problème est que, si je récupère mon code dans GIT et que je l'utilise ensuite pour le construire, il indique que le schéma est introuvable, mais si j'ouvre le projet, il se construit et si je tente ensuite de le reconstruire à partir de la ligne de commande avec la même commande, ça marche.
Quelle magie fait XCode lorsque j'ouvre le projet ou est-ce que je fais quelque chose de stupide, peut-être en excluant un fichier dans mon .gitignore que je ne devrais pas?
Vous êtes définitivement sur la bonne voie en ce qui concerne le fichier .xcscheme - ce problème est survenu lors de la configuration de mes propres projets!
Pour la postérité, ou du moins pour tous ceux qui viennent ici après une recherche, voici deux versions: la version "je suis occupé, donc juste les faits s'il vous plaît" et une discussion et une justification plus compliquées. Ces deux versions supposent que vous essayez de créer à partir d'un fichier Workspace. si vous ne l'êtes pas, toutes mes excuses, car cela s'applique principalement aux projets basés sur un espace de travail.
Version condensée 'Fix-it'
La cause fondamentale est que le comportement par défaut de Schemes est de garder les schémas 'privés' jusqu'à ce qu'ils soient spécifiquement marqués comme partagés. Dans le cas d'une construction initiée par ligne de commande, l'interface utilisateur Xcode ne s'exécute jamais et l'outil xcoderun ne dispose pas de son propre cache de modèles à utiliser. L'objectif est de générer, partager et valider le schéma que vous souhaitez que Bamboo soit exécuté:
- Sur une copie de travail vierge du code, ouvrez l'espace de travail de votre projet.
- Choisissez Modèle> Gérer les modèles ... dans le menu Produit.
- La liste des schémas définis pour le projet apparaît.
- Localisez le schéma que Bamboo essaie d'exécuter
- Assurez-vous que la case "Partagé" est cochée pour ce modèle et que le paramètre "Conteneur" est défini sur l'espace de travail et non sur le fichier de projet lui-même.
- Cliquez sur 'OK' pour fermer la feuille de gestion des schémas.
- Un nouveau fichier .xcscheme a été créé dans votre projet sous WorkspaceName.xcworkspace/xcshareddata/xcschemes.
- Commettez ce fichier dans votre référentiel et exécutez une construction Bamboo.
Discussion plus approfondie et justification
Xcode 4 a introduit les espaces de travail et les schémas comme moyen d’aider à maîtriser le chaos inhérent à la gestion des mécanismes de câblage de projets Xcode, de construction de cibles et de configurations. L'espace de travail lui-même possède son propre ensemble de données de configuration qui décrit chacune des «boîtes» de données qu'il contient et sert de squelette pour attacher des fichiers .xcodeproj et un ensemble de données de configuration partagées qui sont mises en miroir sur chaque machine de développement ou système CI. . C’est à la fois la puissance et le piège des espaces de travail - il existe 1) de nombreuses façons de configurer les choses à 100% correctement, mais de les placer dans le mauvais conteneur ou 2) de les placer dans le bon conteneur, mais de manière incorrecte. rendre des données inaccessibles par d'autres parties du système!
Le comportement par défaut des schémas Xcode 4 consiste à générer automatiquement de nouveaux schémas à mesure que des projets sont ajoutés au fichier Workspace. Ceux d'entre vous qui ont ajouté plusieurs fichiers .xcodeproj ont peut-être remarqué que votre liste de schémas devient rapidement indisciplinée, en particulier à mesure que les fichiers de projet sont ajoutés, puis supprimés, puis relus dans le même espace de travail. Tous les modèles, générés automatiquement ou créés manuellement, sont par défaut des modèles «privés» visibles uniquement pour l'utilisateur actuel, même lorsque les fichiers .xcuserdata sont validés avec les données et la configuration du projet. C’est la cause première de cette erreur de construction cryptique. Bamboo signale xcodebuild - Parce que Bamboo utilise la construction par le biais de la ligne de commande et non de l’UI Xcode, Schemes n’a pas la possibilité de se générer automatiquement et ne repose que sur ceux qui sont définis dans l'espace de travail lui-même. En supposant que vous ayez configuré Bamboo pour créer à partir d'un espace de travail à l'aide d'une commande comme celle-ci:
xcodebuild -workspace MyWorkspace.xcworkspace -scheme MyApplication -configuration Debug
xcodebuild recherche le fichier <'schéma' Valeur du paramètre> .xcscheme existant dans <espace de travail 'Valeur du paramètre>/xcshareddata/xcschemes.
De toute évidence, il existe de nombreuses façons de configurer à la fois Bamboo et un espace de travail. N'oubliez donc pas que votre configuration unique peut ne pas correspondre à 100% à ce qui est présenté ici. Les points à retenir:
- Certaines tâches automatisées prises en charge par l’interface utilisateur Xcode ne sont pas disponibles via la CLI de Xcodebuild.
- Vous pouvez attacher un schéma et construire des données de configuration à de nombreux endroits dans la «hiérarchie de conteneurs» - Assurez-vous que vos données se retrouvent dans le conteneur approprié (espace de travail, projet et/ou cible de construction).
- Déterminez où, dans la hiérarchie des conteneurs, l’outil xcodebuild peut rechercher des données de configuration; Un excellent indicateur de l'endroit où il commencera à chercher est basé sur l'utilisation d'arguments '-workspace' ou '-project'.
La case 'Partagé' est déjà cochée ... et maintenant?
J'ai rencontré le même problème sur ma propre instance Bamboo; il s'est avéré que le schéma qui avait été validé dans mon référentiel était obsolète et que la dernière version des outils de ligne de commande ne le gérait pas correctement. Depuis que cela existait auparavant, j’ai jeté un coup d’œil dans les paramètres pour vérifier que le schéma n’avait rien de très glanment personnalisé, puis je l'ai supprimé et recréé en veillant à ce que je le marque comme 'Partagé', puis en réengageant le nouveau fichier .xcscheme dans le dossier. dépôt.
Si tout semble aller bien et que le reconstruire ne résout pas le problème, revérifiez ce paramètre de conteneur - il est vraiment facile de lier ce schéma au mauvais conteneur dans la hiérarchie!
Déboguer le problème comme ceci:
xcodebuild -list
ou si vous utilisez un espace de travail (par exemple, des modules)
xcodebuild -workspace MyProject.xcworkspace -list
Si votre schéma ne figure pas dans la liste, corrigez-le comme ceci:
La plupart des réponses suggèrent de partager votre schéma avec Xcode, puis de valider les modifications dans le référentiel. Cela fonctionne, bien sûr, mais seulement si vous avez accès au code source et avez le droit de valider les modifications, ainsi que quelques autres hypothèses.
Mais il y a un certain nombre de "what ifs" à considérer
- Que faire si vous ne pouvez pas modifier le projet Xcode pour une raison quelconque?
- Et si vous créez automatiquement un nouveau schéma sur le serveur CI?
Cela se produit assez souvent. Si vous utilisez une infrastructure d'automatisation des tests, telle que Calabash, vous finirez normalement par dupliquer une cible existante, ce qui duplique également automatiquement un schéma et le nouveau schéma n'est pas partagé, même si le schéma d'origine l'était.
Ruby & xcodeproj gem
Je recommanderais d'utiliser xcodeproj Ruby gem . C'est un outil open source vraiment cool qui peut vous aider à automatiser des tonnes de tâches liées à Xcode.
Btw, c’est la gemme utilisée par CocoaPods pour perdre son temps avec vos projets et espaces de travail Xcode.
Alors installez-le
Sudo gem install xcodeproj
Ensuite, écrivez un simple script Ruby pour partager à nouveau tous les schémas, le gem ayant la méthode recreate_user_schemes à cet effet
#!/usr/bin/env Ruby
require 'xcodeproj'
xcproj = Xcodeproj::Project.open("MyProject.xcodeproj")
xcproj.recreate_user_schemes
xcproj.save
Il ne se contente pas de copier les fichiers de modèle du dossier de l'utilisateur dans xcshareddata/xcschemes, il crée également ces fichiers en analysant d'abord le fichier pbxproj.
Ok, je connais ses 2 minutes plus tard, mais j’ai trouvé un autre débordement de pile indiquant que le schéma doit être défini sur shared ... Où Xcode 4 stocke-t-il les données de schéma?
Une des raisons courantes de l'absence du schéma est l'oubli de pousser les commits à l'origine. Si vous recevez un message de schéma manquant, vous devez d'abord vérifier que le schéma est partagé, puis vérifier que vous avez validé les modifications ET les a transmises au serveur d'origine.
La question ci-dessus est identique à mes problèmes, sauf que j'utilise le propre outil de CI de Gitlab. Vous pouvez vérifier s'il existe un tel fichier dans Bamboo.
Je l'ai résolu en apportant des modifications au fichier gitlab-ci.yml.
Après que vous ayez rendu votre scheme disponible par le partage. Dans Xcode, accédez à Products>Scheme>Manage Scheme et cochez share to share.
Changements
Définir le chemin absolu partout.
par exemple .xcodebuild clean archive -archivePath /path/to/your/project/build/testDemo -scheme testDemo | xcpretty
Ici, vous devez changer/path/to/your/project/avec votre chemin ettestDemoavec votre nom de projet.
J'ai été confronté à ce problème et même si certaines des réponses fournies ici apportent la solution, je ne l'ai pas trouvée très claire. Je vais donc en ajouter un de plus. En un mot, comment partager un schéma à partir d'excode.
Accédez à Product> Scheme> Manage Schemes
Vous verrez ensuite une liste de schémas, chacun étant désigné comme étant partagé ou non. Cochez simplement ceux que vous souhaitez partager (il peut en être différent pour les versions de développement et de prod)
Images tirées de cet article https://developer.nevercode.io/docs/sharing-ios-project-schemes
Vous avez le même problème mais pendant la construction avec xcode en tant que sous-projet du projet principal. Construit sous-projet en autonome xcode - après que cette erreur a disparu.
Je veux ajouter une solution pour mon cas lié à ce fil. Celui-ci est pour vous qui clonez un projet existant, avec tous les schémas dont vous avez besoin déjà partagés:
, avec fastlane lanes, affichez correctement toutes vos voies, y compris tous vos projets:
, mais fastlane gym affiche uniquement les schémas principaux (pas les schémas de développement et de test):
La solution consiste à décocher l'option partagée pour les schémas qui ne sont pas répertoriés par fastlane gym et puis vérifiez à nouveau. Il générera .xcscheme pour les schémas:
Maintenant, si vous vérifiez avec fastlane gym, tous les régimes seront listés:
Ensuite, vous devez valider ces fichiers .xcshemes dans le référentiel afin que les autres développeurs qui clonent le projet obtiennent les fichiers.