GitLab CI / CD入门
注意：从8.0版开始，GitLab 持续集成（CI）完全集成到GitLab本身，并在所有项目中默认启用。
一、GitLab提供持续集成服务
如果将.gitlab-ci.yml文件添加到存储库的根目录，并将GitLab项目配置为使用Runner，则每次提交或推送都会触发CI 管道。
该.gitlab-ci.yml文件告诉GitLab跑步者该做什么。默认情况下，它运行有三个流水线阶段：build，test，和deploy。你不需要使用所有三个阶段; 没有工作的阶段被忽略了。
如果一切运行正常（没有非零返回值），您将获得与提交相关联的漂亮绿色复选标记。这样可以在查看代码之前轻松查看提交是否导致任何测试失败。
大多数项目使用GitLab的CI服务来运行测试套件，以便开发人员在破坏某些内容时立即获得反馈。使用持续交付和持续部署将测试代码自动部署到登台和生产环境的趋势越来越明显。
简而言之，具有工作CI所需的步骤可归纳为：
1、添加.gitlab-ci.yml到存储库的根目录
2、配置一个Runner
从那时起，在每次推送到Git存储库时，Runner将自动启动管道，管道将显示在项目的Pipelines页面下。
本指南假设您：
有一个工作GitLab版本8.0 + +或正在使用
GitLab.com
在GitLab中有一个你想使用CI的项目
让我们把它分解成碎片并努力解决GitLab CI难题。
创建.gitlab-ci.yml文件
在您创建之前，.gitlab-ci.yml让我们先简要解释一下这是什么。
什么是 .gitlab-ci.yml
.gitlab-ci.yml您可以在该文件中配置CI对项目执行的操作。它位于存储库的根目录中。
在对存储库的任何推送中，GitLab将根据文件的内容查找.gitlab-ci.yml
文件并在Runners上启动作业。
因为.gitlab-ci.yml在存储库中并且受版本控制，旧版本仍然可以成功构建，分支可以轻松地使用CI，分支可以具有不同的管道和作业，并且您具有CI的单一事实来源。您可以.gitlab-ci.yml 在我们的博客中详细了解我们使用它的原因。
创建一个简单的.gitlab-ci.yml文件
注意：
.gitlab-ci.yml是一个YAML文件，因此您必须特别注意缩进。始终使用空格，而不是制表符。
您需要创建一个.gitlab-ci.yml在存储库的根目录中命名的文件。下面是Ruby on Rails项目的示例。
before_script:
- apt-get update -qq && apt-get install -y -qq sqlite3 libsqlite3-dev nodejs
- ruby -v
- which ruby
- gem install bundler --no-ri --no-rdoc
- bundle install --jobs $(nproc) "${FLAGS[@]}"
rspec:
script:
- bundle exec rspec
rubocop:
script:
- bundle exec rubocop
这是最简单的配置，适用于大多数Ruby应用程序：
使用要执行的不同命令定义两个作业rspec和rubocop（名称是任意的）。
在每个作业之前，before_script执行定义的命令。
该.gitlab-ci.yml文件定义了具有运行方式和时间限制的作业集。该工作被定义为一个名称顶层元素（在我们的情况rspec和rubocop），并总是要包含script关键词。作业用于创建作业，然后由
跑步者选择并在跑步者的环境中执行。
重要的是每项工作都是相互独立运作的。
如果要检查.gitlab-ci.yml项目是否有效，/ci/lint项目命名空间的页面下会有一个Lint工具。您还可以在CI / CD下找到“CI Lint”按钮进入此页面➔管道和
管道➔项目中的作业。
有关更多信息和完整.gitlab-ci.yml语法，请阅读
.gitlab-ci.yml上的参考文档。
推.gitlab-ci.yml送到GitLab
创建之后.gitlab-ci.yml，您应该将其添加到Git存储库并将其推送到GitLab。
git add .gitlab-ci.yml
git commit -m "Add .gitlab-ci.yml"
git push origin master
现在，如果您转到“ 管道”页面，您将看到管道处于待处理状态。
注意：注意：
如果您有一个GitLab来自的镜像存储库，您可能需要在项目的设置>存储库>从远程存储库中提取>镜像更新的触发管道中启用管道触发
。
您也可以转到“ 提交”页面，注意提交SHA旁边的小暂停图标。
单击它，您将被定向到该特定提交的作业页面。
请注意，有一个挂起的作业以我们写的内容命名
.gitlab-ci.yml。“卡住”表示尚未为此作业配置Runner。
下一步是配置一个Runner，以便它选择挂起的作业。
配置Runner
在GitLab中，Runners运行您定义的作业.gitlab-ci.yml。Runner可以是虚拟机，VPS，裸机，docker容器甚至是容器集群。GitLab和Runners通过API进行通信，因此唯一的要求是Runner的机器可以访问GitLab服务器。
Runner可以特定于某个项目，也可以在GitLab中提供多个项目。如果它服务于所有项目，则称为共享运行者。
在Runners文档中查找有关不同Runners的更多信息
。
您可以通过转到设置➔CI/ CD找到是否为您的项目分配了任何跑步者
。设置一个Runner既简单又直接。由GitLab支持的官方Runner是用Go编写的，其文档可以在https://docs.gitlab.com/runner/找到。
要获得功能性Runner，您需要执行以下两个步骤：
安装它
配置它
按照上面的链接设置您自己的Runner或使用Shared Runner，如下一节所述。
设置好Runner后，您应该按照设置➔CI/ CD在项目的Runners页面上看到它。
共享跑步者
如果您使用GitLab.com，您可以使用
GitLab Inc.提供的共享跑步者。
这些是在GitLab的基础架构上运行的特殊虚拟机，可以构建任何项目。
要启用共享运行器，您必须转到项目的
设置➔CI/ CD，然后单击启用共享运行器。
阅读共享跑步者的更多信息。
查看管道和作业的状态
成功配置Runner后，您应该会看到上次提交的状态从挂起更改为运行，成功或失败。
您可以转到项目的“ 管道”页面来查看所有管道。
或者您可以通过管道➔工作页面查看所有工作。
通过单击作业的状态，您将能够看到该作业的日志。这对于诊断工作失败或行为与预期不同的原因非常重要。
您还可以在GitLab的各个页面中查看任何提交的状态，例如提交和合并请求。
例子
访问示例README，查看使用各种语言的GitLab CI的示例列表。