xcode - xcodebuild 说不包含方案

Question

我有一个古玩问题。

我有一个我一直在使用 XCode IDE 构建的项目，它运行良好。现在我正在设置 Bamboo 来构建项目，因此我正在从命令行构建它。

问题是，如果我从 GIT 中检查我的代码，然后使用 xcodebuild 构建它，它会说找不到该方案，但是如果我打开项目，它会构建，然后如果我尝试从命令行再次构建它使用相同的命令，它可以工作。

当我打开项目时，XCode 有什么魔力，或者我在做一些愚蠢的事情，也许在我的 .gitignore 中排除了一个我不应该做的文件？

score 189 · Accepted Answer

关于 .xcscheme 文件，您绝对走在正确的轨道上——我在设置自己的项目时出现了这个问题！

对于后代，或者至少任何从搜索中得到这里的人，这里有两个版本的东西——“我很忙，所以请提供事实”版本和一个更复杂的讨论和理由。这两个版本都假定您正在尝试从 Workspace 文件构建；如果您不是，那么我很抱歉，因为这主要适用于基于工作空间的项目。

精简的“修复”版本

根本原因是方案的默认行为是将方案保持为“私有”，直到它们被明确标记为共享。在命令行启动构建的情况下，Xcode UI 永远不会运行，并且 xcoderun 工具没有自己的 Schemes 缓存可以使用。目标是生成、共享和提交您希望 Bamboo 运行的方案：

在代码的干净工作副本上，打开项目的工作区。
从产品菜单中选择方案 > 管理方案...。
出现为项目定义的方案列表。
定位 Bamboo 尝试运行的 Scheme
确保为该方案选中“共享”框，并将“容器”设置设置为工作区，而不是项目文件本身。
单击“确定”关闭“管理方案”表。
一个新的 .xcscheme 文件已在您的项目中创建，位于 WorkspaceName.xcworkspace/xcshareddata/xcschemes。
将此文件提交到您的存储库并运行 Bamboo 构建。

更深入的讨论和理由

Xcode 4 引入了 Workspaces 和 Schemes 作为一种方法来帮助尝试和驯服一些在处理连接相关 Xcode 项目、构建目标和构建配置的机制时所固有的混乱。工作区本身有自己的一组配置数据，描述了它包含的每个较小的数据“盒子”，并充当附加 .xcodeproj 文件的骨架和一组共享配置数据，这些数据镜像到每个开发人员机器或 CI 系统. 这既是工作区的强大之处，也是陷阱——有 1) 有很多方法可以让事情 100% 正确配置，但放入错误的容器中；或者 2) 放入正确的容器中，但配置不正确，从而呈现数据系统的其他部分无法访问！

Xcode 4 方案的默认行为是在将项目添加到工作区文件时自动生成新方案。那些添加了多个 .xcodeproj 文件的人可能已经注意到，您的方案列表很快就会变得不规则，尤其是在添加项目文件、然后删除、然后再将其读取到同一个工作区时。所有方案，自动生成或手动创建，默认为仅对当前用户可见的“私有”方案，即使 .xcuserdata 文件与项目的数据和配置一起提交也是如此。这是 Bamboo 从 xcodebuild 报告的那个神秘的构建错误的根本原因——因为 Bamboo 通过命令行而不是 Xcode UI 操作构建，所以它没有机会自动生成 Schemes 并且只依赖于那些在工作区本身中定义。

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

xcodebuild 去寻找文件 <'scheme' Parameter Value>.xcscheme 存在于 <'workspace' Parameter Value>/xcshareddata/xcschemes。

显然，有很多方法可以同时配置 Bamboo 和工作空间，因此请记住，您的独特配置可能不会 100% 映射到此处显示的内容。关键要点：

Xcode UI 神奇地处理的某些自动化任务无法通过 Xcodebuild CLI 获得。
您可以将方案和构建配置数据附加到“容器层次结构”中的许多地方——确保您的数据在正确的容器中结束（工作区、项目和/或构建目标）
考虑 xcodebuild 工具可能在容器层次结构中的哪个位置查找配置数据；一个很好的指示它将从哪里开始寻找是基于“-workspace”或“-project”参数的使用。

“共享”框已被选中……现在怎么办？

我在自己的 Bamboo 实例上遇到了同样的问题；事实证明，在我的存储库中提交的方案已经过时，最新版本的命令行工具并没有很好地处理它。由于这之前存在，我查看了设置以确保该方案没有任何明显的自定义，删除并重新创建了该方案，确保我将其标记为“共享”，并将新的 .xcscheme 文件重新提交到存储库。

如果一切看起来都很好并且重建它并不能解决问题，请仔细检查容器设置——很容易将该方案附加到层次结构中的错误容器！

score 55 · Accepted Answer

像这样调试问题：

xcodebuild -list

或者如果您使用的是工作区（例如使用 pod）

xcodebuild -workspace MyProject.xcworkspace -list

如果您的方案未列出，则修复如下：

在此处输入图像描述

score 36 · Accepted Answer

大多数答案会建议您使用 Xcode 共享您的方案，然后将更改提交到 repo。当然，这可行，但前提是您有权访问源代码并有权提交更改，以及其他一些假设。

但是有许多“假设”需要考虑

如果你因为某种原因不能修改 Xcode 项目怎么办？
如果你在 CI 服务器上自动创建一个新方案怎么办？
这实际上经常发生。如果您使用测试自动化框架，如 Calabash，通常最终会复制现有目标，该目标也会自动复制方案，并且不会共享新方案，即使原始方案是。

红宝石和 xcodeproj 宝石

我会推荐使用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文件首先创建这些文件。

score 9 · Accepted Answer

好的，我知道它 2 分钟后，但我发现另一个堆栈溢出说该方案必须设置为共享... Xcode 4 在哪里存储方案数据？

score 3 · Accepted Answer

缺少该方案的一个常见原因是忘记将提交推送到源。如果您收到缺少方案消息，您应该首先验证方案是共享的，然后验证您已提交更改并将它们推送到源服务器。

score 1 · Accepted Answer

我在实施 CI 时遇到了这个错误。上面的问题与我的问题相同，只是我使用的是 Gitlab 自己的 CI 工具。您可以检查 Bamboo 中是否有任何此类文件。我通过对文件
进行一些更改来解决它。在您通过共享使您可用之后。在 Xcode 中转到并检查共享以共享。变化gitlab-ci.yml
schemeProducts>Scheme>Manage Scheme

到处设置绝对路径。
例如。xcodebuild clean archive -archivePath /path/to/your/project/build/testDemo -scheme testDemo | xcpretty
在这里，您需要更改/path/to/your/project/路径和testDemo项目名称。