4. 为什么我们用 .gitlab-ci.yml 文件替换 GitLab CI 作业

原文链接：https://about.gitlab.com/2015/05/06/why-were-replacing-gitlab-ci-jobs-with-gitlab-ci-dot-yml/

如果你还不知道：安装 GitLab 会自动附带一个强大的持续集成工具：GitLab CI。阅读如何在2分钟内启用它。使用GitLab CI，您可以轻松地运行项目测试并轻松触发构建和部署，因为它与 GitLab 深度集成。

到目前为止，要设置 build/deploy 命令，您必须进入 GitLab CI 并在表单中编辑脚本。这使得设置门槛非常低，但感觉总有不足。

我们很高兴地告诉您，我们将根据 Travis CI 的原则和库获得更好的解决方案：.gitlab-ci.yml。

将来，您可以将 .gitlab-ci.yml 文件添加到存储库，而不是编辑表单，您可以在其中为 GitLab CI 指定构建。这对 GitLab CI 构建有重大积极的影响：

目前，脚本只是表单中的一个字段：

image

这意味着你没有充分发挥 git 的优点：没有版本控制。通过将其移动到存储库中，您可以获得 git 和 GitLab 的所有功能。

将作业脚本存储在存储库之外意味着它对于每次提交都是相同的。这意味着对脚本的任何更改都将影响任何提交的构建，即使您正在处理可能与新构建脚本不兼容的旧分支/提交。

通过将构建放在存储库中，旧的提交仍然可以通过较旧版本的构建脚本进行测试，而较新的工作可以安全地对构建进行更改。

使用最新版本的 GitLab CI 分割项目也将复制作业设置的内容，从而可以使用 fork 构建测试。但是，这仅在项目和分支具有相同的所有者并且能够使用相同的运行者时才有效。

使用存储库中的脚本，这使得此过程更加透明。最重要的是，fork 可以轻松地将依赖项添加到其 .gitlab-ci.yml 文件中。

目前，您无法轻松地为不同的分支运行不同的脚本。

通过将脚本移动到存储库，这为某些分支打开了一个全新的特定构建世界。例如，您可以将时间密集型集成测试设置为仅在推送到生产分支时运行。

并且在测试成功时，立即部署您的代码。

目前，只有 GitLab 中具有主访问权限或更高权限的人才能够在 GitLab CI 中查看和编辑作业设置。这使得很难看到所有其他开发人员正在发生的事情。

使用存储库中的单个文件，具有读访问权限的每个人都可以看到内容，从而使其更有吸引力地改进和查看构建脚本。

目前，您可以定义多个作业，但您必须自己定义每个作业。

如果您有多个版本的编程语言，多个环境和多个依赖项列表，您最终会为每个版本创建一个工作。

使用 .gitlab-ci.yml，您将能够运行构建矩阵，为您生成这些作业。如果定义每个维度，则将生成组合。这样可以更轻松地设置需要此功能的复杂测试套件。

您可以通过将 job.sh 放在存储库的根目录并在 .gitlab-ci.yml文件的：script:./job.sh 中引用它来运行当前作业。

我们从哪里获得灵感

令人敬畏的 Travis CI 有一个好的思想，即使用 .yml 文件进行构建，然后是受欢迎的 CircleCI。我们很高兴遵循这种方法，我们认为这种方法优于任何其他方法。相反，Jenkins 的工作并没有解决引言中提到的问题。

像往常一样，我们这个惊人的社区已经充分意识到这一点，我们已经在我们的反馈页面上看到了对此的需求，甚至实现了这一点！

我们将使用免费提供的一些伟大的 Travis CI 项目来构建它。

此更改将弃用现有作业，因为我们希望 GitLab CI 易于使用和开发。多种做事方式使新用户感到困惑，它使文档更难以使开发和调试变得复杂。

这意味着对于使用 GitLab CI 的任何人来说，这也是一个重大变化。因此，我们只会在 GitLab 8.0 中引入此更改。

我们还不确定在哪个次要版本之后我们将发布 GitLab 8.0（7.11,7.12 或更高版本）。

请按照 GitLab CI 存储库中的进度进行操作。