Swift —在Github上的持续集成

本文是同时介绍TDD和多个CI概念的指南的一部分。 您可以在 此处 查看介绍性文章 。

如介绍性文章所述，对于本指南，我们将使用TravisCI作为CI平台。 它对开源项目是免费的，并且易于使用。

让我们开始工作：

1. 首先在TravisCI网站上创建一个帐户，然后对GitHub帐户进行配对（您也可以使用GitHub凭据直接登录到Travis，从而无需进行配对过程）。
2. 从项目列表中选择所需的项目，以便Travis可以为其生成一个Webhook。
3. TravisCI现在已挂接到您的项目上，并且在您的代码更改时将得到通知（默认情况下，它设置为在每次推送以及合并时都运行。您可以在github的项目配置页面上对其进行编辑。
4. 现在是时候告诉TravisCI每次对代码进行推送更改时要做什么。 为此，我们必须将一个文件添加到项目的根目录，并将其命名为“ .travis.yml”。 它看起来应该像这样：

7. TravisCI现在已经配置好，可以开始使用了！ 提交并推送您的更改（确保包括.yml文件），应通知TravisCI，它将开始构建您的项目并运行测试！ 如果一切顺利，您应该得到一个类似于以下的屏幕：

有些不对劲？ 请在下面发表评论，我将尽力帮助！

8.您可能还需要检查日志，以了解实际情况。 但是， xcodebuild日志可能有些冗长和混乱。 为了解决这个问题，我们将使用另一个名为xcpretty小工具，它将获取构建日志并使其更加用户友好。 这很容易。 我们只需要向.yml配置文件添加几行：

2. SwiftLint的另一个优点是，您可以配置XCode来运行它，以便在每次构建后进行编码时都能得到实时警告！ 为此，我们必须在Xcode的构建过程中添加一个新的“运行脚本阶段”，并包含以下脚本：

尽管非常有用，但SwifLint有时还是会有些干扰。 在某些情况下，您可能会收到您确实不想更改的代码的警告（例如上面的AppDelegate甚至是测试类，它们本来就很长）。 为避免这种情况，您可以配置.yml文件以指定文件排除项。 我希望您更明确一些，并像

// swiftline:disable:next line_length

随着SwiftLint的本地部分得到照顾，现在是时候让TravisCI处理它了。 同样，这是通过travis.yml:完成的travis.yml:

现在该创建一个CodeCov帐户了。 使用您的GitHub帐户注册并从列表中添加您的存储库。 您应该看到类似于此屏幕。 记下令牌ID，因为稍后我们将需要它。

最后，我们现在可以配置TravisCI，以便每次构建项目时也可以检查覆盖范围。 我们必须在yml文件中添加两件事：

• 通过添加标志-enableCodeCoverage YES ，将xcodebuild配置为也启用coverage数据
• 使用after_script选项将覆盖率数据上传到codecov 。

您的Yaml应该如下所示：

已知的错误

xcodebuild目前发生一个已知的错误，其中没有考虑UI测试，这会影响您的覆盖率。 例如，当我想以正确的百分比（在FizzBu​​zz示例中为100％）更新CodeCov时，例如在合并合并请求之前，我直接在XCode中运行整个测试套件，然后手动上载coverage使用相同的命令向codecov报告：

bash <(curl -s https://codecov.io/bash) -t YOUR_TOKEN

猎犬

猎犬执行与SwiftLint相似的任务，但它们都在云中运行并且独立于CI工具。 对于每个警告，它都会直接对您的拉取请求进行注释，因此很容易理解。 您还可以将其配置为在出现警告时失败，这可能会有所帮助。

由于独立于CI，将其添加到项目中非常容易。 只需使用您的GitHub凭证转到Hound网站并注册。 选择项目，就是这样！ 现在，每次提交新代码时，猎犬都会对其进行检查。

在检查代码时，我认为Hound会考虑您的SwiftLint忽略的内容（例如我为AppDelegate函数显示的内容），但目前我不确定100％。

若要将工具配置为在违规时失败，您.hound.yml使用以下命令将.hound.yml添加到项目的根目录：