xcodebuildにはスキームが含まれていません
キュリオスの問題があります。
私が取り組んできたプロジェクトがあり、常にXCode IDEからビルドしましたが、うまくいきました。現在、プロジェクトをビルドするためにBambooをセットアップしています。そのため、コマンドラインからビルドしています。
問題は、GITからコードをチェックアウトし、xcodebuildを使用してビルドすると、スキームが見つからないということですが、プロジェクトを開くとビルドされ、コマンドラインから再度ビルドしようとすると同じコマンドで動作します。
プロジェクトを開いたときや、.gitignoreにあるべきではないファイルを除外するなど、愚かなことをしているとき、XCodeはどんな魔法をしているのでしょうか？
.xcschemeファイルに関して、あなたは間違いなく正しい軌道に乗っています。私自身のプロジェクトをセットアップしているときに、この問題が現れました。
後世、または少なくとも検索からここにたどり着く人のために、2つのバージョンがあります。「忙しいので、事実だけをお願いします」バージョンと、より複雑な議論と理論的根拠です。これらのバージョンは両方とも、ワークスペースファイルからビルドしようとしていることを前提としています。あなたがそうでない場合、これはワークスペースベースのプロジェクトにほとんど当てはまるので私の謝罪。
凝縮された「修正」バージョン
根本的な原因は、Schemesのデフォルトの動作が、特に共有としてマークされるまでスキームを「プライベート」に保つことです。コマンドラインで開始されたビルドの場合、Xcode UIは決して実行されず、xcoderunツールには動作するスキームの独自のキャッシュがありません。目標は、Bambooで実行するスキームを生成、共有、およびコミットすることです。
- コードのクリーンな作業コピーで、プロジェクトのワークスペースを開きます。
- [製品]メニューから[スキーム]> [スキームの管理...]を選択します。
- プロジェクトに定義されているスキームのリストが表示されます。
- Bambooが実行しようとしているスキームを見つける
- そのスキームの[共有]ボックスがオンになっていること、および[コンテナ]設定がプロジェクトファイル自体ではなくワークスペースに設定されていることを確認します。
- [OK]をクリックして、[スキームの管理]シートを閉じます。
- WorkspaceName.xcworkspace/xcshareddata/xcschemesのプロジェクトに新しい.xcschemeファイルが作成されました。
- このファイルをリポジトリにコミットし、Bambooビルドを実行します。
詳細な議論と根拠
Xcode 4は、関連するXcodeプロジェクトの配線、ターゲットの構築、および構成の構築のメカニズムに対処するための固有の混乱を試して飼いならす方法としてワークスペースとスキームを導入しました。ワークスペース自体には、含まれるデータの小さな「ボックス」のそれぞれを記述する独自の構成データセットがあり、.xcodeprojファイルと各開発者マシンまたはCIシステムにミラーリングされる共有構成データセットをアタッチするためのスケルトンとして機能します。 これはワークスペースのパワーと落とし穴の両方です-1）物事を100％正しく設定し、間違ったコンテナに入れる、または2）正しいコンテナに入れるが、構成する多くの方法がありますしたがって、システムの他の部分がアクセスできないデータを不適切にレンダリングします！
Xcode 4スキームのデフォルトの動作では、プロジェクトがワークスペースファイルに追加されると、新しいスキームが自動的に生成されます。いくつかの.xcodeprojファイルを追加した人は、特にプロジェクトファイルが追加、削除、および同じワークスペースに追加されると、スキームリストがすぐに手に負えなくなることに気付いたかもしれません。自動生成または手動で作成されたすべてのスキームは、.xcuserdataファイルがプロジェクトのデータと構成でコミットされている場合でも、現在のユーザーにのみ表示される「プライベート」スキームにデフォルト設定されます。これは、Bambooがxcodebuildから報告する暗号化ビルドエラーの根本的な原因です-BambooはXcode UIではなくコマンドラインを介してビルドを操作するため、Schemesが自動的に生成され、それに依存するもののみに依存する機会はありませんワークスペース自体で定義されます。次のようなコマンドを使用してワークスペースからビルドするようにBambooを構成したと仮定します。
xcodebuild -workspace MyWorkspace.xcworkspace -scheme MyApplication -configuration Debug
xcodebuildは、<'workspace' Parameter Value>/xcshareddata/xcschemesにあるファイル<'scheme' Parameter Value> .xcschemeを探します。
明らかに、Bambooとワークスペースの両方を構成できる方法がたくさんあるので、独自の構成がここに示されているものに100％マッピングされない可能性があることに注意してください。重要なポイント：
- Xcode UIが魔法のように処理する特定の自動化されたタスクは、Xcodebuild CLIを介して利用できません。
- 「コンテナ階層」の多くの場所にスキームと構成データをアタッチできます-データが正しいコンテナ（ワークスペース、プロジェクト、ビルドターゲット）に収まることを確認してください
- コンテナ階層のどこでxcodebuildツールが構成データを探しているかを検討してください。どこで検索を開始するかを示す優れた指標は、「-workspace」または「-project」引数の使用に基づいています。
「共有」ボックスはすでにチェックされています...今何？
私は自分のBambooインスタンスでこの同じ問題に遭遇しました。私のリポジトリでコミットされたスキームは時代遅れであり、コマンドラインツールの最新バージョンはそれを適切に処理していなかったことが判明しました。これは以前から存在していたので、設定を見て、スキームに関する明白なカスタムがないことを確認し、スキームを削除して再作成し、「共有」としてマークし、新しい.xcschemeファイルを倉庫。
すべてがよさそうで、再構築しても問題が解決しない場合は、そのコンテナ設定を再確認してください。階層内の間違ったコンテナにそのスキームをアタッチするのは本当に簡単です！
このような問題をデバッグします。
xcodebuild -list
またはワークスペースを使用している場合（ポッドなど）
xcodebuild -workspace MyProject.xcworkspace -list
スキームがリストにない場合は、次のように修正します。
ほとんどの答えは、Xcodeを使用してスキームを共有し、次にリポジトリに変更をコミットすることを示唆しています。もちろん動作しますが、ソースコードにアクセスでき、変更をコミットする権限、および他のいくつかの仮定がある場合に限ります。
しかし、考慮すべき多くの「what ifs」があります
- 何らかの理由でXcodeプロジェクトを変更できない場合はどうなりますか？
- CIサーバーで新しいスキームを自動的に作成するとどうなりますか？
これは実際に頻繁に発生します。 Calabashなどのテスト自動化フレームワークを使用する場合、通常は既存のターゲットを複製することになり、スキームも自動的に複製されます。元のスキームがあったとしても、新しいスキームは共有されません。
Ruby＆xcodeproj gem
xcodeproj Ruby gemを使用することをお勧めします。これは、Xcode関連の大量のタスクを自動化するのに役立つ、本当にクールなオープンソースツールです。
ところで、これは CocoaPods がXcodeプロジェクトとワークスペースをいじるために使用するgemです。
それをインストールする
Sudo gem install xcodeproj
次に、単純なRubyスクリプトを記述して、すべてのスキームを再共有します。gemには、そのためのrecreate_user_schemesメソッドがあります
#!/usr/bin/env Ruby
require 'xcodeproj'
xcproj = Xcodeproj::Project.open("MyProject.xcodeproj")
xcproj.recreate_user_schemes
xcproj.save
ユーザーのフォルダーからスキームファイルをxcshareddata/xcschemesにコピーするだけでなく、pbxprojファイル。
わかりましたが、その2分後、スキームを共有に設定する必要があるという別のスタックオーバーフローが見つかりました... Xcode 4はスキームデータをどこに保存しますか？
スキームが欠落している一般的な理由の1つは、コミットをオリジンにプッシュすることを忘れていることです。不足しているスキームメッセージが表示された場合は、まずスキームが共有されていることを確認してから、変更をコミットし、それらをOriginサーバーにプッシュしたことを確認する必要があります。
CIの実装中にこのエラーが発生しました。上記の質問は、GitlabのCIツールを使用していることを除いて、私の問題と同じです。Bambooにそのようなファイルがあるかどうかを確認できます。gitlab-ci.ymlファイルにいくつかの変更を加えることで解決しました。
共有してscheme使用可能にした後。 XcodeでProducts>Scheme>Manage Schemeに移動し、共有する共有を確認します。
変更
どこでも絶対パスを設定します。
eg .xcodebuild clean archive -archivePath /path/to/your/project/build/testDemo -scheme testDemo | xcpretty
ここで、/path/to/your/project/をパスで、testDemoをプロジェクト名で変更する必要があります。
私はこの問題に直面し、ここでの回答のいくつかが実際に解決策を提供したとしても、私はそれをあまり明確に見つけませんでした。そこで、もう1つだけ追加します。簡単に言えば、excodeからスキーマを共有する方法。
Product> Scheme> Manage Schemesに移動します
その後、スキームのリストが表示され、それぞれが共有されているかどうかが示されます。共有したいものをチェックするだけです（devビルドとprodビルドでは異なる場合があります）
この記事から撮影した画像 https://developer.nevercode.io/docs/sharing-ios-project-schemes
同じ問題が発生しましたが、メインコードのサブプロジェクトとしてxcodeを使用してビルドしています。 Xcodeスタンドアロンでビルドされたサブプロジェクト-その後、このエラーは消えました。
このスレッドに関連する私のケースの解決策を追加したいと思います。これは、必要なすべてのスキームが既に共有されている既存のプロジェクトを複製するユーザー向けです。
、fastlane lanesで、すべてのスキームを含むすべてのレーンを正しく表示します。
、しかしfastlane gymはメインスキームのみを表示します（devおよびtestスキームは表示しません）：
解決策は、スキームの共有オプションのチェックを外すことですfastlane gymでリストされていない、およびそれからもう一度チェックします。スキームの.xcschemeを生成します。
ここで、fastlane gymでチェックすると、すべてのスキームがリストされます。
次に、これらの.xcshemesファイルをリポジトリにコミットする必要があります。これにより、プロジェクトを複製する他の開発者がファイルを取得します。