126 votes

xcodebuild dit qu'il ne contient pas de schéma

J'ai un problème curieux.

J'ai un projet sur lequel j'ai travaillé et que j'ai toujours construit à partir de l'IDE XCode, et cela a bien fonctionné. Maintenant, je configure Bamboo pour construire le projet et, en tant que tel, je le construis à partir de la ligne de commande.

Le problème est le suivant : si j'extrais mon code de GIT et que j'utilise xcodebuild pour le construire, il indique que le schéma ne peut être trouvé, mais si j'ouvre le projet, il se construit et si j'essaie de le construire à nouveau à partir de la ligne de commande avec la même commande, il fonctionne.

Quelle magie fait XCode quand 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 ?

0 votes

Je viens de remarquer que lorsque j'ouvre le projet dans xcode, il crée un fichier .xcscheme, mais dans le dossier xcuserdata/username.xcuserdatad... mais je ne comprends pas pourquoi le schéma est "généré" sous le dossier des utilisateurs... et comment je vais gérer cela dans bamboo...

187voto

Bryan Musial Points 3000

Vous êtes certainement sur la bonne voie en ce qui concerne le fichier .xcscheme - j'ai eu ce problème en mettant en place mes propres projets !

Pour la postérité, ou au moins pour toute personne arrivant ici après une recherche, voici deux versions des choses - la version "Je suis occupé, donc juste les faits s'il vous plaît" et une discussion plus impliquée et un raisonnement. Ces deux versions supposent que vous essayez de construire à partir d'un fichier Workspace ; si ce n'est pas le cas, je vous présente mes excuses car ceci s'applique principalement aux projets basés sur Workspace.

Version condensée du "bricolage".

La cause fondamentale est que le comportement par défaut des schémas 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 lancée en ligne de commande, l'interface utilisateur de Xcode n'est jamais exécutée et l'outil xcoderun ne dispose pas de son propre cache de schémas avec lequel travailler. Le but est de générer, partager et commiter le schéma que vous voulez que Bamboo exécute :

  1. Sur une copie de travail propre du code, ouvrez l'espace de travail de votre projet.
  2. Choisissez Schéma > Gérer les schémas... dans le menu Produit.
  3. La liste des schémas définis pour le projet apparaît.
  4. Localisez le schéma que Bamboo essaie d'exécuter.
  5. Assurez-vous que la case "Shared" est cochée pour ce schéma et que le paramètre "Container" est défini sur l'espace de travail et non sur le fichier de projet lui-même.
  6. Cliquez sur "OK" pour fermer la feuille de gestion des schémas.
  7. Un nouveau fichier .xcscheme a été créé dans votre projet à WorkspaceName.xcworkspace/xcshareddata/xcschemes.
  8. Déposez ce fichier dans votre dépôt et lancez une construction Bamboo.

Discussion approfondie et justification

Xcode 4 a introduit les espaces de travail et les schémas comme un moyen d'essayer d'apprivoiser une partie du chaos inhérent à la mécanique du câblage des projets Xcode, des cibles de construction et des configurations de construction ensemble. L'espace de travail lui-même possède son propre ensemble de données de configuration qui décrit chacune des petites "boîtes" de données qu'il contient et agit comme un squelette pour attacher les fichiers .xcodeproj et un ensemble de données de configuration partagées qui sont reflétées sur chaque machine de développement ou système CI. C'est à la fois la puissance et l'inconvénient des espaces de travail : il existe 1) de nombreuses façons de configurer des éléments de manière 100% correcte, mais de les placer dans le mauvais conteneur ou 2) de les placer dans le bon conteneur, mais de les configurer de manière incorrecte, rendant ainsi les données inaccessibles à d'autres parties du système !

Le comportement par défaut des schémas de Xcode 4 est de générer automatiquement de nouveaux schémas lorsque 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 désordonnée, en particulier lorsque des fichiers de projet sont ajoutés, puis supprimés, et ensuite réinsérés dans le même espace de travail. Tous les schémas, qu'ils soient générés automatiquement ou créés manuellement, deviennent par défaut des schémas "privés" visibles uniquement par l'utilisateur actuel, même si les fichiers .xcuserdata sont livrés avec les données et la configuration du projet. C'est la cause principale de l'erreur de construction énigmatique que Bamboo rapporte à partir de xcodebuild -- Parce que Bamboo opère la construction par la ligne de commande et non par l'interface utilisateur de Xcode, il n'a pas la possibilité de générer automatiquement des schémas et se fie uniquement à ceux qui sont définis dans l'espace de travail lui-même. En supposant que vous avez configuré Bamboo pour construire à partir d'un espace de travail en utilisant une commande comme celle-ci :

xcodebuild -workspace MyWorkspace.xcworkspace -scheme MyApplication -configuration Debug

xcodebuild va chercher le fichier <valeur du paramètre 'schéma'>.xcscheme existant dans <valeur du paramètre 'espace de travail'>/xcshareddata/xcschemes.

Il est évident qu'il existe de nombreuses façons de configurer Bamboo et un espace de travail. Gardez donc à l'esprit que votre configuration unique peut ne pas correspondre à 100% à ce qui est présenté ici. Les points essentiels à retenir :

  1. Certaines tâches automatisées que l'interface utilisateur de Xcode prend magiquement en charge ne sont pas disponibles via la CLI de Xcodebuild.
  2. Vous pouvez attacher des données de configuration de schéma et de construction à de nombreux endroits dans la "hiérarchie des conteneurs" -- Assurez-vous que vos données se retrouvent dans le bon conteneur (espace de travail, projet et/ou cible de construction).
  3. Considérez où dans la hiérarchie du conteneur l'outil xcodebuild peut chercher les données de configuration ; un bon indicateur de l'endroit où il commencera à chercher est basé sur l'utilisation des arguments '-workspace' ou '-project'.

La case "Partagé" est déjà cochée... et maintenant ?

J'ai rencontré ce même problème sur ma propre instance de Bamboo ; il s'est avéré que le schéma qui avait été validé dans mon dépôt était obsolète et que la dernière version des outils de ligne de commande ne le gérait pas de manière satisfaisante. Puisque ce problème existait déjà, j'ai jeté un coup d'œil aux paramètres pour m'assurer qu'il n'y avait rien de trop personnalisé dans le schéma, j'ai supprimé et recréé le schéma en m'assurant de le marquer comme "partagé", et j'ai réenregistré le nouveau fichier .xcscheme dans le référentiel.

Si tout semble correct et que la reconstruction ne résout pas le problème, vérifiez à nouveau le paramètre du conteneur. Il est très facile de rattacher ce schéma au mauvais conteneur dans la hiérarchie !

0 votes

Cela a corrigé une erreur aléatoire de xcodebuild pour moi qui ne retournait AUCUNE erreur mais un code de sortie 65. Il s'avère que le conteneur était défini sur le projet et non sur l'espace de travail lui-même, je l'ai changé et voilà, le problème est résolu. Merci.

0 votes

Merci ! C'est exactement la solution que je cherchais.

0 votes

Mes options de test et d'archivage sont désactivées pour cette raison. J'ai vérifié que mon schéma est partagé, mais je ne peux toujours pas construire avec le robot. Je peux construire localement, mais comme je l'ai mentionné, je ne peux pas l'archiver. Pensez-vous que cela soit lié à ce problème ?

53voto

Robert Points 10822

Déboguez le problème comme ceci :

xcodebuild -list

ou si vous utilisez un espace de travail (par exemple avec des pods)

xcodebuild -workspace MyProject.xcworkspace -list

Si votre régime n'est pas répertorié, procédez comme suit :

enter image description here

0 votes

Le fait de partager les schémas leur permet de se manifester dans xcodebuild -list ... merci !

36voto

i4niac Points 687

La plupart des réponses vous suggèrent de faire votre schéma partagé en utilisant Xcode, puis de commettre les changements dans le dépôt. Cela fonctionne, bien sûr, mais seulement si vous avez accès au code source et si vous avez le droit de livrer les changements, et quelques autres hypothèses.

Mais il y a un certain nombre de " Et si " à considérer

  • Et si vous ne pouvez pas modifier le projet Xcode pour une raison quelconque ?
  • Et si vous créez un nouveau schéma automatiquement sur le serveur CI ?
    Cela arrive en fait assez souvent. Si vous utilisez un cadre d'automatisation des tests, comme Calabash, vous finirez normalement par dupliquer une cible existante, qui duplique automatiquement un schéma également, et le nouveau schéma n'est pas partagé, même si le schéma original l'était.

Ruby & xcodeproj gem

Je recommande d'utiliser xcodeproj Gemme de rubis. Il s'agit d'un outil open source vraiment cool qui peut vous aider à automatiser des tonnes de tâches liées à Xcode.

A propos, c'est la gemme utilisée par CocoaPods pour manipuler vos projets et espaces de travail Xcode.

Alors, installez-le

sudo gem install xcodeproj

Ensuite, écrire un simple script Ruby pour re-partager tous les schémas, la gemme a recréer des schémas d'utilisateur méthode à 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 schéma depuis le dossier de l'utilisateur jusqu'à xcshareddata/xcschemes il crée également ces fichiers en premier lieu en analysant le fichier pbxproj fichier.

1 votes

Au cas où quelqu'un d'autre tomberait sur ce sujet, il semble que recreate_user_schemes ne gère pas correctement les cibles de test. J'ai déposé un rapport de bogue à ce sujet .

0 votes

J'en ai parlé sur mon blog. nsbogan.com/xcode/2014/05/29/partager-xcode-schémas . Malheureusement, le problème des tests unitaires n'est toujours pas résolu.

0 votes

J'ai essayé cette solution. Mais quand je lance xcodebuild -project Finance.xcodeproj -scheme "Finance" -configuration Release clean archive CODE_SIGN_IDENTITY="My Identity" J'ai obtenu 'Scheme <IDEScheme:0x7fc9ea5e5fd0:'Finance'> a été invité à construire et à archiver, mais la destination d'exécution <IDERunDestination:0x7fc9eb47c6c0:'iPad 2'> n'est pas une plateforme de déploiement et cette action n'aurait pas dû être autorisée'. Mais lorsque j'ouvre XCode tout fonctionne bien

9voto

Zac Tolley Points 356

Ok je sais que c'est 2 minutes plus tard mais j'ai trouvé un autre stack overflow qui dit que le schéma doit être défini comme partagé.... Où Xcode 4 stocke-t-il les données de schéma ?

3voto

Eric Points 41

Une raison fréquente de l'absence du schéma est l'oubli de pousser les commits vers l'origine. Si vous obtenez un message de schéma manquant, vous devez d'abord vérifier que le schéma est partagé, puis que vous avez validé les changements ET les avez poussés vers le serveur d'origine.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X