У меня любопытная проблема.
У меня есть проект, над которым я работал и всегда строил из XCode IDE, и он отлично работал. Теперь я настраиваю Bamboo для сборки проекта и, как таковой, создаю его из командной строки.
Проблема в том, что если я проверю свой код из GIT, а затем использую xcodebuild для его сборки, он говорит, что схема не может быть найдена, но если я открою проект, он будет построен, и если я затем попытаюсь построить его снова из командной строки с той же командой он работает.
Какую магию делает XCode, когда я открываю проект или делаю что-то глупое, возможно, исключая файл из моего .gitignore, которого мне не следует делать?
xcode
xcodebuild
bamboo
Зак Толли
источник
источник
Ответы:
Вы определенно на правильном пути в отношении файла .xcscheme - у меня возникла эта проблема при настройке моих собственных проектов!
Для потомков или, по крайней мере, тех, кто попадает сюда в результате поиска, есть две версии - версия «Я занят, так что просто факты, пожалуйста» и более активное обсуждение и обоснование. Обе эти версии предполагают, что вы пытаетесь выполнить сборку из файла Workspace; Если нет, то приношу свои извинения, поскольку это в основном применимо к проектам на основе рабочей области.
Краткая версия Fix-it
Основная причина заключается в том, что поведение схем по умолчанию заключается в том, чтобы сохранять схемы «частными» до тех пор, пока они не будут специально отмечены как общие. В случае сборки, инициированной командной строкой, пользовательский интерфейс Xcode никогда не запускается, а инструмент xcoderun не имеет собственного кеша схем для работы. Цель состоит в том, чтобы сгенерировать, поделиться и зафиксировать схему, которую вы хотите запустить в Bamboo:
Более глубокое обсуждение и обоснование
Xcode 4 представил рабочие области и схемы как способ помочь попытаться приручить некоторый хаос, присущий работе с механизмами объединения связанных проектов Xcode, целей сборки и сборки конфигураций вместе. Само рабочее пространство имеет свой собственный набор данных конфигурации, который описывает каждый из меньших `` блоков '' данных, которые он содержит, и действует как каркас для прикрепления файлов .xcodeproj и набора общих данных конфигурации, которые зеркалируются на каждой машине разработчика или системе CI. , В этом и сила, и ловушка рабочих пространств - есть 1) множество способов, с помощью которых можно настроить все на 100% правильно, но поместить в неправильный контейнер, или 2) поместить в правильный контейнер, но настроенный неправильно, таким образом, отображая данные недоступен для других частей системы!
По умолчанию схемы Xcode 4 автоматически создают новые схемы по мере добавления проектов в файл рабочей области. Те из вас, кто добавил несколько файлов .xcodeproj, возможно, заметили, что ваш список схем быстро становится неуправляемым, особенно когда файлы проекта добавляются, затем удаляются, а затем считываются в ту же рабочую область. Все схемы, созданные автоматически или вручную, по умолчанию являются «частными» схемами, видимыми только текущему пользователю, даже если файлы .xcuserdata зафиксированы вместе с данными и конфигурацией проекта. Это основная причина той загадочной ошибки сборки, которую Bamboo сообщает из xcodebuild - поскольку Bamboo управляет сборкой через командную строку, а не через пользовательский интерфейс Xcode, у него нет возможности для автоматического создания схем и полагается только на те, которые определены в самой рабочей области.
xcodebuild ищет файл <'scheme' Parameter Value> .xcscheme, существующий в <'workspace' Parameter Value> / xcshareddata / xcschemes.
Очевидно, что существует множество способов настройки как Bamboo, так и рабочего пространства, поэтому имейте в виду, что ваша уникальная конфигурация может не на 100% соответствовать тому, что представлено здесь. Основные выводы:
Поле "Shared" уже отмечено ... что теперь?
Я столкнулся с той же проблемой на моем собственном экземпляре Bamboo; Оказалось, что схема, зафиксированная в моем репозитории, устарела, и последняя версия инструментов командной строки не справлялась с ней корректно. Поскольку это существовало ранее, я просмотрел настройки, чтобы убедиться, что в схеме нет ничего явно нестандартного, удалил и воссоздал схему, убедившись, что я пометил ее как `` Общий доступ '', и повторно загрузил новый файл .xcscheme в репозиторий.
Если все выглядит хорошо и перестройка не решает проблему, дважды проверьте настройку этого контейнера - очень легко привязать эту схему к неправильному контейнеру в иерархии!
источник
Отлаживайте проблему следующим образом:
или если вы используете рабочее пространство (например, с модулями)
Если вашей схемы нет в списке, исправьте это так:
источник
xcodebuild -list
... спасибо!В большинстве ответов предлагается сделать вашу схему общей с помощью Xcode, а затем зафиксировать изменения в репо. Это, конечно, работает, но только если у вас есть доступ к исходному коду и права на фиксацию изменений, а также несколько других предположений.
Но есть ряд вопросов, которые следует учитывать.
На самом деле это случается довольно часто. Если вы используете платформу автоматизации тестирования, такую как Calabash, вы обычно в конечном итоге дублируете существующую цель, которая также автоматически дублирует схему, и новая схема не используется совместно, даже если исходная схема была.
Ruby & xcodeproj gem
Я бы рекомендовал использовать xcodeproj Ruby gem. Это действительно крутой инструмент с открытым исходным кодом, который может помочь вам автоматизировать множество задач, связанных с Xcode.
Кстати, это жемчужина, используемая CocoaPods, чтобы возиться с вашими проектами и рабочими пространствами Xcode.
Так что установите это
Затем написать простой скрипт на Ruby для повторного использования всех схем, драгоценный камень имеет recreate_user_schemes метод для этой цели
Он не просто копирует файлы схемы из папки пользователя в xcshareddata / xcschemes , он также сначала создает эти файлы, анализируя файл pbxproj .
источник
recreate_user_schemes
он неправильно обрабатывает тестовые цели. Я отправил отчет об ошибке .xcodebuild -project Finance.xcodeproj -scheme "Finance" -configuration Release clean archive CODE_SIGN_IDENTITY="My Identity"
мне было предложено построить и заархивировать «Scheme <IDEScheme: 0x7fc9ea5e5fd0:« Finance »>, но место назначения запуска <IDERunDestination: 0x7fc9eb47c6c0: 'iPad 2'> не является платформой развертывания, и это действие не должно иметь было разрешено ». Но когда я открываю XCode, все работает нормальноarchive
действие всегда подразумевает подписание, а в качестве пункта назначения должно быть указано реальное устройство. В вашем случае пункт назначенияiPad 2
, который, я думаю, является симулятором, поэтому архивирование невозможно. В вашей команде отсутствует одна важная опция:-sdk iphoneos
сначала попробуйте и посмотрите, как это получится. Когда вы запускаете его из Xcode IDE, у вас, вероятно, установлен пункт назначенияiOS Device
или, возможно, у вас подключено реальное устройство, поэтому оно установлено в качестве пункта назначения. Поэтому архивирование работает из IDE. Командная строка более «тупая» и иногда может использовать «неправильные» параметры по умолчанию, поэтому вам нужно быть более конкретным.Хорошо, я знаю, что это через 2 минуты, но я нашел другое переполнение стека, в котором говорится, что схема должна быть настроена на общий доступ ... Где Xcode 4 хранит данные схемы?
источник
Одна из частых причин отсутствия схемы - это забыть отправить коммиты в источник. Если вы получили сообщение об отсутствии схемы, вам следует сначала убедиться, что схема является общедоступной, а затем убедиться, что вы зафиксировали изменения и отправили их на исходный сервер.
источник
У меня была эта ошибка при реализации CI. Вопрос выше идентичен моим проблемам, за исключением того, что я использую собственный инструмент CI Gitlab. Вы можете проверить, есть ли такой файл в Bamboo.
Я решил это, внеся некоторые изменения в
gitlab-ci.yml
файл.После того, как вы сделали свой
scheme
доступ, поделившись. В Xcode перейдите кProducts>Scheme>Manage Scheme
и отметьте поделиться, чтобы поделиться.изменения
источник
Возникла та же проблема, но во время сборки с xcode в качестве подпроекта основного. Встроенный подпроект в автономном режиме xcode - после этого ошибка исчезла.
источник
Я столкнулся с этой проблемой, и даже если некоторые ответы здесь действительно предоставляют решение, я не нашел его очень ясным. Так что я просто добавлю еще один. Вкратце, как поделиться схемой из excode.
Перейдите к
Product
>Scheme
>Manage Schemes
Затем вам будет показан список схем, каждая из которых обозначена как совместно используемая или нет. Просто отметьте те, которыми вы хотите поделиться (они могут быть разными для сборок dev и prod)
Изображения взяты из этой статьи https:// developer. Nevercode.io/docs/sharing-ios-project-schemes
источник
Я хочу добавить решение для своего дела, связанного с этой веткой. Это для вас, кто клонирует существующий проект, и все необходимые вам схемы уже доступны:
, с
fastlane lanes
правильным отображением всех ваших полос, включая все ваши схемы:, но
fastlane gym
показывать только основные схемы (а не схемы разработки и тестирования):Решение состоит в том, чтобы снять отметку с опции общего доступа для схем , не указанных в списке,
fastlane gym
а затем проверить ее снова . Он сгенерирует .xcscheme для схем:Теперь, если вы проверите
fastlane gym
, все схемы будут перечислены:Затем вы должны зафиксировать этот файл .xcshemes в репозитории, чтобы другой разработчик, клонировавший проект, получил файлы.
источник
Для тех, кто с Xcode 11.4 пытается найти кнопку «Shared» на схеме, теперь она перемещена в индивидуальную схему.
источник