流水线改用文件来写的原因

一句话总结.gitlab-ci.yml是将构建服务器设置拖入存储库，使代码等评论、相同履历、相同撤销的文件。

##为什么需要这个

设置构建服务器为屏幕的那个时代的错误通常以一句短语结束。“昨天能做的事情今天做不了，但没有人知道什么被改变了。”因为讨论设置存储库外的数据库里。那个设置里没有diff，没有评论，没有分支，也没有可以撤销的提交。谁勾选了一个复选框的事实是在发生错误后，也只能依靠记忆才能发现。

更深的问题是没有分支。代码在每个分支上都不一样，但管道只有一个，所以要添加新的测试阶段，必须同时更改所有分支的构建。所以人们不再动管道，管道就像几年前有人制作的那样僵化了。僵化的管道很快就会变成没有人相信的管道。

如果将设置从存储库移动到文件中，这四个问题就会同时解决。每个分支可以拥有不同的管道，可以在合并请求中审查管道本身的变化，如果出错，可以撤销提交，管道也会一起恢复，什么是什么时候为什么变更的记录在Git日志中。

怎么操作

GitLab是存储库根的.gitlab-ci.yml读取并创建一个管道。这里重要的就是顺序。提交上传后，GitLab首先读取提交中的设置文件，根据内容决定要制作什么样的游戏，然后将制作好的游戏分配给游戏运行者。也就是说，设置在游戏开始之前就已经全部评价过了。以后会学到的rules之所以决定不是“要执行这个杂项吗”，而是“要制作这个杂项吗”，也是因为这个顺序。

文件的语法只有一个YAML映射。一个顶级键是抓一个，预定的几个名字（stages，variables，default，include，workflow)不是用作捕获，而是用作全域设置。这种简单性是优点和陷阱。如果在缩进的一格上放错了，捕获整个捕获就会消失，但YAML本身不会出现任何错误。文件会正常解析，只是那个捕获变成了其他键的子项。

从一开始就明确了这个课程所涵盖的范围。**在这个实践环境中，没有GitLab服务器也没有GitLab Runner。**所以无法看到实际运行的场景，也不会启动假的Runner来假装运行。相反，我们讨论了设置语言及其执行模型——会生成什么，会按照什么顺序开始，什么在等什么。虽然安装工具后可以学习的是工具，但执行模型即使没有Runner也可以学习，即使供应商变更也不会消失。

在现场相遇的样子

将设置移动到文件中的团队中，首先变化的是评论对话。“为什么把这个测试移到发布后？”的问题作为合并请求评论留下来，答案也一起留下来。相反，在还没有在屏幕上设置的团队中，同样的问题在聊天中来回交流并消失。

另一个经常看到的场景是管道文件膨胀成数百行之后include哇，开始寻找模板了。如果文件存储在仓库里，其庞大性就会显而易见，所以开始重构。如果放在屏幕里，没有人能看到它的大小。

##在下一篇文章中可以看到

把一个杂物到底包含了什么，按基数拆开看看。script如果没有的话，为什么不是捕获对象，名字前面的一点为什么从执行对象中删除它，default哇extends甚至看它如何以不同的方式减少重复。