开始使用GitLab CI/CD

帮忙改进翻译html

官方原文档：https://docs.gitlab.com/ee/ci...node

注：从8.0版本开始，GitLab 持续集成（CI）彻底集成到GitLab中，且默认全部的项目开启。

GitLab提供持续集成服务。若是添加一个.gitlab-ci.yml文件到项目根目录，并配置GitLab项目使用某个Runner，而后每一次提交或者是推送都会触发CI pipeline.git

.gitlab-ci.yml文件会告诉GitLab Runner 作什么。默认状况下，它运行一个pipeline，分为三个阶段：build，test，deploy。你并不须要用到全部的阶段，没有job的阶段会被忽略。github

若是一切运行正常(没有非零的返回值)，您将获得与commit关联的漂亮的绿色标记。这使得在查看代码以前，很容易就能看出是否有一个提交致使了测试失败。sql

大多数项目使用GitLab CI服务来运行测试套件，这样若是开发人员发现问题就会及时获得反馈。docker

所以，简而言之，CI所须要的步骤能够归结为：shell

1. 添加`.gitlab-ci.yml`到项目的根目录
        2. 配置一个Runner

今后刻开始，在每一次push到Git仓库的过程当中，Runner会自动开启pipline，pipline将显示在项目的Pipline页面中。ruby

本指南要求：工具

• 使用版本8.0+ 的GitLab实例或者是使用GitLab.com
• 一个想使用GitLab CI的项目

让咱们把它分解成碎片，并致力于解决GitLab CI之谜。gitlab

建立.gitlab-ci.yml

在建立.gitlab-ci.yml以前，咱们先对它进行个简单的解释。

.gitlab-ci.yml是什么

.gitlab-ci.yml是用来配置CI在咱们的项目中作些什么工做。它位于项目的根目录。

在任何的push操做，GitLab都会寻找.gitlab-ci.yml文件，并对这次commit开始jobs，jobs的内容来源于.gitlab-ci.yml文件。

由于.gitlab-ci.yml是存在于咱们的项目仓库中，而且受版本控制的，因此旧版本也能够执行成功，且使用CI可让forks更容易，分支可也以拥有不一样的pipelines和jobs，并且对于CI来讲只会拥有单一的来源。你也能够在咱们的博客中找到咱们为何使用.gitlab-ci.yml的缘由。

建立一个简单的.gitlab-ci.yml

注意： .gitlab-ci.yml是一个 YAML文件，因此必需要格外注意锁紧。使用空格，而不是tabs。

在项目的根目录建立一个名为.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应用程序最简单的配置：

1. 定义了两个jobs，rspec和rubocop（名字能够随便取），他们执行不一样的命令。
2. 在每一个jobs以前，before_script定义的命令都将会被执行。

.gitlab-ci.yml定义了一系列的jobs，其中包含如何运行和什么时候运行的限制。jobs必须定义一个名称（在示例中分别是rspec和rubocop）做为顶级元素，并且老是必须包含script关键字。Jobs被用来建立任务，它们会被Runners接受和环境中的Runner执行。

重要的是，每一个工做都是独立运行的。

若是你想检验.gitlab-ci.yml文件的语法是否正确，在GitLab实例页面中有一个命令行工具/ci/lint。也能够从项目中的CI/CD ➔ Pipelines and Pipelines ➔ Jobs找到此页面。

关于更多.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

如今到Pipelines页面查看，将会看到该Pipline处于等待状态。

你也能够到Commits页面查看，并会发现SHA旁边的暂停按钮。

点击它便可进入到该特定commit的jobs页面。

配置Runner

在GitLab中，Runners将会运行你在.gitlab-ci.yml中定义的jobs。Runner能够是虚拟机，VPS，裸机，docker容器，甚至一堆容器。GitLab和Runners经过API通讯，因此惟一的要求就是运行Runners的机器能够联网。

一个Runner能够服务GitLab中的某个特定的项目或者是多个项目。若是它服务全部的项目，则被称为共享的Runner。

在Runners文档中查阅更多关于不一样Runners的信息。

你能够经过Settings->CI/CD查找是否有Runners分配到你的项目中。建立一个Runner是简单且直接的。官方支持的Runner是用GO语言写的，它的文档在这里https://docs.gitlab.com/runner/。

为了有一个功能性的Runner，你须要遵循如下步骤：

1. 安装
2. 配置

按照上面的链接设置你本身的Runner或者使用下一节介绍的共享Runner。

一旦Runner安装好，你能够从项目的Settings->CI/CD找到Runner页面。

共享Runners

若是你用的是GitLab.com，你可使用GitLab公司提供的共享Runners。

这些是运行在GitLab基础设置上面的特殊虚拟机，能够构建任何项目。

你能够经过项目中的Settings->CI/CD找到Shared Runners，并点击开启它。

阅读更多关于共享Runners。

查看pipeline和jobs的状态

成功的配置好Runner后，你应该查看最后一次提交后的状态，从pending、到执行中、成功或失败。

你能够经过项目中的Piplines页面查看全部的piplines。

也能够经过Piplines->Jobs页面查看全部的jobs。

经过点击jobs的状态，查看该job的日志。这对于帮助诊断job失败或者job与预期结果不一样很重要。

你还能够查看在GitLab的各类页面中的任何提交状态，例如Commits和Merge requests。

Examples

在这里，能够查看各类语言使用GitLab CI的示例。