├── _config.yml ├── LICENSE ├── README.md ├── quick_start.md ├── pipelines.md ├── GitLab CI.md ├── Variables.md ├── docs ├── index.html ├── gitlab-ci.html ├── pipelines.html └── quick_start.html └── gitlab-ci-yaml.md /_config.yml: -------------------------------------------------------------------------------- 1 | theme: jekyll-theme-slate -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | The MIT License (MIT) 2 | 3 | Copyright (c) 2017 Fennay 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy of 6 | this software and associated documentation files (the "Software"), to deal in 7 | the Software without restriction, including without limitation the rights to 8 | use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of 9 | the Software, and to permit persons to whom the Software is furnished to do so, 10 | subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS 17 | FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR 18 | COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER 19 | IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN 20 | CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. 21 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | ## 官方GitLab文档翻译 2 | 3 | 英文文档地址：https://docs.gitlab.com/ 4 | 5 | 已完成内容： 6 | 7 | | 修改时间 | 内容 | 说明 | 文档地址 | 8 | | ---------- | ----------------------------- | --------- | ---------------------------------------- | 9 | | 2017-12-29 | gitlab-ci-yaml | yaml配置文档 | [访问地址](https://fennay.github.io/gitlab-ci-cn/gitlab-ci-yaml.html) | 10 | | 2017-07-02 | Variables | 变量说明 | [访问地址](https://fennay.github.io/gitlab-ci-cn/variables.html) | 11 | | 2018-01-05 | Quick start guide | 快速引导页 | [访问地址](https://fennay.github.io/gitlab-ci-cn/quick_start.html) | 12 | | 2018-01-10 | GitLab Continuous Integration | GitLab CI | [访问地址](https://fennay.github.io/gitlab-ci-cn/gitlab-ci.html) | 13 | | 2018-06-23 | Pipelines and jobs | 管道 | [访问地址](https://fennay.github.io/gitlab-ci-cn/pipelines.html) | 14 | 15 | 计划内容： 16 | 17 | | 内容 | 文档地址 | 进度 | 18 | | ------------------ | ---------------------------------------- | ---- | 19 | | Using Docker images | https://docs.gitlab.com/ee/ci/docker/using_docker_images.html | 未开始 | 20 | 21 | -------------------------------------------------------------------------------- /quick_start.md: -------------------------------------------------------------------------------- 1 | # 开始GitLab CI/CD 2 | 3 | 4 | 官方原文档：https://docs.gitlab.com/ee/ci/quick_start/README.html 5 | 6 | > 注：从8.0版本开始，GitLab [持续集成](https://about.gitlab.com/gitlab-ci/)（CI）完全集成到GitLab中，且默认所有的项目开启。 7 | 8 | GitLab提供[持续集成](https://about.gitlab.com/gitlab-ci/)服务。如果添加一个[`.gitlab-ci.yml`文件](https://docs.gitlab.com/ee/ci/yaml/README.html)到项目根目录，并配置GitLab项目使用某个[Runner](https://docs.GitLab.com/ee/ci/runners/README.html)，然后每一次提交或者是推送都会触发CI [pipeline](https://docs.GitLab.com/ee/ci/pipelines.html). 9 | 10 | `.gitlab-ci.yml`文件会告诉GitLab Runner 做什么。默认情况下，它运行一个`pipeline`，分为三个阶段：`build`，`test`，`deploy`。你并不需要用到所有的阶段，没有`job`的阶段会被忽略。 11 | 12 | 如果一切运行正常(没有非零的返回值)，您将得到与commit关联的漂亮的绿色标记。这使得在查看代码之前，很容易就能看出是否有一个提交导致了测试失败。 13 | 14 | 大多数项目使用GitLab CI服务来运行测试套件，这样如果开发人员发现问题就会及时得到反馈。 15 | 16 | 因此，简而言之，CI所需要的步骤可以归结为： 17 | ``` 18 | 1. 添加`.gitlab-ci.yml`到项目的根目录 19 | 2. 配置一个Runner 20 | ``` 21 | 从此刻开始，在每一次push到Git仓库的过程中，Runner会自动开启pipline，pipline将显示在项目的Pipline页面中。 22 | 23 | ------ 24 | 25 | 本指南要求： 26 | 27 | - 使用版本8.0+ 的GitLab实例或者是使用[GitLab.com](https://gitlab.com/) 28 | - 一个想使用GitLab CI的项目 29 | 30 | 让我们把它分解成碎片，并致力于解决GitLab CI之谜。 31 | 32 | # 创建`.gitlab-ci.yml` 33 | 34 | 在创建`.gitlab-ci.yml`之前，我们先对它进行个简单的解释。 35 | 36 | ## `.gitlab-ci.yml`是什么 37 | 38 | `.gitlab-ci.yml`是用来配置CI在我们的项目中做些什么工作。它位于项目的根目录。 39 | 40 | 在任何的push操作，GitLab都会寻找`.gitlab-ci.yml`文件，并对此次commit开始jobs，jobs的内容来源于`.gitlab-ci.yml`文件。 41 | 42 | 因为`.gitlab-ci.yml`是存在于我们的项目仓库中，并且受版本控制的，所以旧版本也可以执行成功，且使用CI可以让forks更容易，分支可也以拥有不同的pipelines和jobs，而且对于CI来说只会拥有单一的来源。你也可以在我们的博客中找到我们为什么使用`.gitlab-ci.yml`的原因。 43 | 44 | ## 创建一个简单的`.gitlab-ci.yml` 45 | 46 | > 注意：`.gitlab-ci.yml`是一个[YAML](https://en.wikipedia.org/wiki/YAML)文件，所以必须要格外注意锁紧。使用空格，而不是tabs。 47 | 48 | 在项目的根目录创建一个名为`.gitlab-ci.yml`的文件。下面是一个Ruby on Rails项目的示例。 49 | 50 | ```yaml 51 | before_script: 52 | - apt-get update -qq && apt-get install -y -qq sqlite3 libsqlite3-dev nodejs 53 | - ruby -v 54 | - which ruby 55 | - gem install bundler --no-ri --no-rdoc 56 | - bundle install --jobs $(nproc) "${FLAGS[@]}" 57 | 58 | rspec: 59 | script: 60 | - bundle exec rspec 61 | 62 | rubocop: 63 | script: 64 | - bundle exec rubocop 65 | ``` 66 | 67 | 这是大多数Ruby应用程序最简单的配置： 68 | 69 | 1. 定义了两个jobs，`rspec`和`rubocop`（名字可以随便取），他们执行不同的命令。 70 | 2. 在每个jobs之前，`before_script`定义的命令都将会被执行。 71 | 72 | `.gitlab-ci.yml`定义了一系列的jobs，其中包含如何运行和何时运行的限制。jobs必须定义一个名称（在示例中分别是`rspec`和`rubocop`）作为顶级元素，而且总是必须包含`script`关键字。Jobs被用来创建任务，它们会被Runners接受和环境中的Runner执行。 73 | 74 | 重要的是，每个工作都是独立运行的。 75 | 76 | 如果你想检验`.gitlab-ci.yml`文件的语法是否正确，在GitLab实例页面中有一个命令行工具`/ci/lint`。也可以从项目中的**CI/CD ➔ Pipelines** and **Pipelines ➔ Jobs**找到此页面。 77 | 78 | 关于更多`.gitlab-ci.yml`的信息和语法，请阅读[.gitlab-ci.yml](https://docs.gitlab.com/ee/ci/yaml/README.html)参考文档。 79 | 80 | ## 推送`.gitlab-ci.yml`到GitLab 81 | 82 | 一旦创建了`.gitlab-ci.yml`，你应该及时添加到Git仓库并推送到GitLab。 83 | 84 | ```shell 85 | git add .gitlab-ci.yml 86 | git commit -m "Add .gitlab-ci.yml" 87 | git push origin master 88 | ``` 89 | 90 | 现在到**Pipelines**页面查看，将会看到该Pipline处于等待状态。 91 | 92 | 你也可以到**Commits**页面查看，并会发现SHA旁边的暂停按钮。 93 | 94 | ![](https://docs.gitlab.com/ee/ci/quick_start/img/new_commit.png) 95 | 96 | 点击它即可进入到该特定commit的jobs页面。 97 | 98 | ![](https://docs.gitlab.com/ee/ci/quick_start/img/single_commit_status_pending.png) 99 | 100 | ## 配置Runner 101 | 102 | 在GitLab中，Runners将会运行你在`.gitlab-ci.yml`中定义的jobs。Runner可以是虚拟机，VPS，裸机，docker容器，甚至一堆容器。GitLab和Runners通过API通信，所以唯一的要求就是运行Runners的机器可以联网。 103 | 104 | 一个Runner可以服务GitLab中的某个特定的项目或者是多个项目。如果它服务所有的项目，则被称为共享的Runner。 105 | 106 | 在[Runners](https://docs.gitlab.com/ee/ci/runners/README.html)文档中查阅更多关于不同Runners的信息。 107 | 108 | 你可以通过**Settings->CI/CD**查找是否有Runners分配到你的项目中。创建一个Runner是简单且直接的。官方支持的Runner是用GO语言写的，它的文档在这里https://docs.gitlab.com/runner/。 109 | 110 | 为了有一个功能性的Runner，你需要遵循以下步骤： 111 | 112 | 1. [安装](https://docs.gitlab.com/runner/install/) 113 | 2. [配置](https://docs.gitlab.com/ee/ci/runners/README.html#registering-a-specific-runner) 114 | 115 | 按照上面的连接设置你自己的Runner或者使用下一节介绍的共享Runner。 116 | 117 | 一旦Runner安装好，你可以从项目的**Settings->CI/CD**找到Runner页面。 118 | 119 | ## ![](https://docs.gitlab.com/ee/ci/quick_start/img/runners_activated.png) 120 | 121 | ## 共享Runners 122 | 123 | 如果你用的是GitLab.com，你可以使用GitLab公司提供的共享Runners。 124 | 125 | 这些是运行在GitLab基础设置上面的特殊虚拟机，可以构建任何项目。 126 | 127 | 你可以通过项目中的**Settings->CI/CD**找到**Shared Runners**，并点击开启它。 128 | 129 | [阅读更多关于共享Runners](https://docs.gitlab.com/ee/ci/runners/README.html)。 130 | 131 | ## 查看pipeline和jobs的状态 132 | 133 | 成功的配置好Runner后，你应该查看最后一次提交后的状态，从*pending*、到*执行中*、*成功*或*失败*。 134 | 135 | 你可以通过项目中的Piplines页面查看所有的piplines。 136 | 137 | ![](https://docs.gitlab.com/ee/ci/quick_start/img/pipelines_status.png) 138 | 139 | 也可以通过**Piplines->Jobs**页面查看所有的jobs。 140 | 141 | ![](https://docs.gitlab.com/ee/ci/quick_start/img/builds_status.png) 142 | 143 | 通过点击jobs的状态，查看该job的日志。这对于帮助诊断job失败或者job与预期结果不同很重要。 144 | 145 | ![](https://docs.gitlab.com/ee/ci/quick_start/img/build_log.png) 146 | 147 | 你还可以查看在GitLab的各种页面中的任何提交状态，例如**Commits**和**Merge requests**。 148 | 149 | ## Examples 150 | 151 | 在[这里](https://docs.gitlab.com/ee/ci/examples/README.html)，可以查看各种语言使用GitLab CI的示例。 -------------------------------------------------------------------------------- /pipelines.md: -------------------------------------------------------------------------------- 1 | # 管道和作业介绍 2 | 3 | 官方文档：https://docs.gitlab.com/ee/ci/pipelines.html 4 | 5 | > 在GitLab 8.8中引入的。 6 | 7 | > 注意：如果你的项目是从[GitLab中拉取的镜像仓库](https://docs.gitlab.com/ee/workflow/repository_mirroring.html#pulling-from-a-remote-repository)，需要在项目中开启触动开关 8 | > 9 | > **Settings > Repository > Pull from a remote repository > Trigger pipelines for mirror updates**. 10 | 11 | ## 管道 12 | 13 | 管道是一组[分阶段](https://docs.gitlab.com/ee/ci/yaml/README.html#stages)（批处理）执行的[工作](https://docs.gitlab.com/ee/ci/pipelines.html#jobs)。同一个阶段中的所有工作都是并行执行的（如果有足够的并发[Runners](https://docs.gitlab.com/ee/ci/runners/README.html)），如果它们全部成功，管道就进入下一个阶段。如果其中一个jobs失败，则下一个阶段不（通常）执行。您可以访问项目的**Pipeline**选项卡中的管道页面。 14 | 15 | 在下图中，您可以看到管道由4个阶段组成（`build(构建)`, `test(测试)`, `staging(分级)`, `production(生产)`），每个阶段都有一个或多个工作。 16 | 17 | > 注意：在GitLab [pipeline图](https://docs.gitlab.com/ee/ci/pipelines.html#pipeline-graphs)上显示时，应当大写显示stats的名称。 18 | 19 | ![](https://docs.gitlab.com/ee/ci/img/pipelines.png) 20 | 21 | ### 管道类型 22 | 23 | 管道分三种，但是通常都使用单一的“管道”来代替所有。人们经常谈论他们，就好像每个都是“管道”一样，但实际上，他们只是综合管道的一部分。 24 | 25 | ![](https://docs.gitlab.com/ee/ci/img/types-of-pipelines.svg) 26 | 27 | 1. **CI Pipeline：** 在`gitlab-ci.yml`中定义的构建和测试阶段。 28 | 29 | 2. **Deploy Pipeline：** 在`.gitlab-ci.yml`中定义的部署阶段，用来通过各种各样的方式将代码部署到服务器： 30 | 31 | 例如，将代码发布到生成环境 32 | 33 | 3. **Project Pipeline**：[通过API触发](https://docs.gitlab.com/ee/ci/triggers/README.html#ci-job-token)跨项目CI依赖关系，尤其是针对微服务，但也适用于复杂的构建依赖关系： 34 | 35 | 例如，api-> front-end，ce / ee-> omnibus。 36 | 37 | ## 开发工作流程 38 | 39 | 管道适应多种开发工作流程： 40 | 41 | 1. **Branch Flow**（例如，dev，qa，分期，生产等不同分支） 42 | 2. **Trunk-based Flow** （例如，功能分支、单一的主分支和可能带有标签的发布） 43 | 3. **基于分叉的流程**（例如，来自fork的合并请求） 44 | 45 | 连续交付流程示例： 46 | 47 | ![](https://docs.gitlab.com/ee/ci/img/pipelines-goal.svg) 48 | 49 | ### 工作 50 | 51 | 工作可以在[`.gitlab-ci.yml`](https://docs.gitlab.com/ee/ci/yaml/README.html#jobs)文件中定义。不要与`build`工作或`build` 阶段混淆。 52 | 53 | ## 定义管道 54 | 55 | 在`.gitlab-ci.yml`中通过指定[阶段](https://docs.gitlab.com/ee/ci/yaml/README.html#stages)运行的[作业](https://docs.gitlab.com/ee/ci/pipelines.html#jobs)来定义管道。 56 | 57 | 有关[作业](https://docs.gitlab.com/ee/ci/yaml/README.html#jobs)，请参阅参考[文档](https://docs.gitlab.com/ee/ci/yaml/README.html#jobs)。 58 | 59 | ## 查看管道状态 60 | 61 | 您可以在项目的 **Pipeline**选项卡下找到当前和历史运行的管道 。点击管道将显示为该管道运行的作业。 62 | 63 | ![](https://docs.gitlab.com/ee/ci/img/pipelines_index.png) 64 | 65 | ## 查看工作状态 66 | 67 | 当您访问单个管道时，您可以看到该管道的相关作业。点击单个作业会显示该作业运行历史，并允许您取消作业，重试作业或清除作业运行日志。 68 | 69 | [![管道示例](https://docs.gitlab.com/ee/ci/img/pipelines.png)](https://docs.gitlab.com/ee/ci/img/pipelines.png) 70 | 71 | ## 查看工作失败的原因 72 | 73 | > 在GitLab 10.7中[引入](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/17782)。 74 | 75 | 当管道发生故障或允许失败时，有几个地方可以快速检查失败的原因： 76 | 77 | - **在管道图中** 出现在管道图中。 78 | - **在管道小部件中** 出现在合并请求和提交页面中。 79 | - **在工作视图中 **出现在全局和详细的工作视图中。 80 | 81 | 无论任何方式中，你将鼠标悬停在失败的作业上，你可以看到失败的原因。 82 | 83 | [![管道细节](https://docs.gitlab.com/ee/ci/img/job_failure_reason.png)](https://docs.gitlab.com/ee/ci/img/job_failure_reason.png) 84 | 85 | 从[GitLab 10.8中](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/17814)，您还可以在工作详情页面上看到失败的原因。 86 | 87 | ## 管道图 88 | 89 | > 在GitLab 8.11中[引入](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5742)。 90 | 91 | 管道可以是复杂的结构，具有许多顺序和平行的作业。为了让您更容易看到发生了什么，它可以查看单个管道及其状态。 92 | 93 | 管道图可以通过两种不同的方式显示，具体取决于您所处的页面。 94 | 95 | ------ 96 | 97 | 当您在[单个管道页面](https://docs.gitlab.com/ee/ci/pipelines.html#seeing-pipeline-status)上时，可以找到显示每个阶段作业名称的常规管道图。 98 | 99 | [![管道示例](https://docs.gitlab.com/ee/ci/img/pipelines.png)](https://docs.gitlab.com/ee/ci/img/pipelines.png) 100 | 101 | 其次，有管道迷你图，占用更少的空间，并且可以快速浏览所有作业是成果还是失败。管道迷你图可以在您访问以下页面时找到： 102 | 103 | - 管道索引页面 104 | - 提交页面 105 | - 合并请求页面 106 | 107 | 通过这种方式，您可以看到所有相关的作业以及每个阶段的最终结果。这使您可以快速查看失败的工作并修复它。管道迷你图的阶段是可折叠的。将鼠标悬停在它们上面，然后单击以展开其他作业。 108 | 109 | | **迷你图** | **迷你图展开** | 110 | | ------------------------------------------------------------ | ------------------------------------------------------------ | 111 | | [![管道迷你图](https://docs.gitlab.com/ee/ci/img/pipelines_mini_graph_simple.png)](https://docs.gitlab.com/ee/ci/img/pipelines_mini_graph_simple.png) | [![管道迷你图扩展](https://docs.gitlab.com/ee/ci/img/pipelines_mini_graph.png)](https://docs.gitlab.com/ee/ci/img/pipelines_mini_graph.png) | 112 | 113 | ### 将相似的工作分组 114 | 115 | > 在GitLab 8.12中[引入](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6242)。 116 | 117 | 如果你有许多类似的工作，你的管道图会变得很长，很难阅读。出于这个原因，类似的工作可以自动组合在一起。如果作业名称以某种格式命名，则它们将在常规管线图（非迷你图）中折叠为一个组。如果您没有看到重试或取消按钮，您就知道管道将作业已经合并分组了。将鼠标悬停在上面会显示分组作业的数量。可以点击展开它们。 118 | 119 | [![分组管道](https://docs.gitlab.com/ee/ci/img/pipelines_grouped.png)](https://docs.gitlab.com/ee/ci/img/pipelines_grouped.png) 120 | 121 | 基本要求是需使用以下方式的一种将两个数字分隔开（可以互换使用）（查看下面的示例）： 122 | 123 | - 空间 124 | - 斜线（`/`） 125 | - 冒号（`:`） 126 | 127 | > **注意：** 更准确地说，[它使用](https://gitlab.com/gitlab-org/gitlab-ce/blob/2f3dc314f42dbd79813e6251792853bc231e69dd/app/models/commit_status.rb#L99)这个正则表达式：`\d+[\s:\/\\]+\d+\s*`。 128 | 129 | 这些工作将通过从左到右比较这两个数字来进行排序。通常第一个是索引，第二个是总数。 130 | 131 | 例如，以下作业将被分组在一个名为的作业下`test`： 132 | 133 | - `test 0 3` => `test` 134 | - `test 1 3` => `test` 135 | - `test 2 3` => `test` 136 | 137 | 以下作业将被分组在下列作业中`test ruby`： 138 | 139 | - `test 1:2 ruby` => `test ruby` 140 | - `test 2:2 ruby` => `test ruby` 141 | 142 | 下列作业也将被归类在一个作业中`test ruby`： 143 | 144 | - `1/3 test ruby` => `test ruby` 145 | - `2/3 test ruby` => `test ruby` 146 | - `3/3 test ruby` => `test ruby` 147 | 148 | ### 手动操作 149 | 150 | > 在GitLab 8.15中[引入](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7931)。 151 | 152 | [手动操作](https://docs.gitlab.com/ee/ci/yaml/README.html#manual)允许您在使用CI中的指定作业之前需要手动操作。整个管道可以自动运行，但实际[部署到生产](https://docs.gitlab.com/ee/ci/environments.html#manually-deploying-to-environments)需要点击。 153 | 154 | 您可以直接从管道图中做到这一点。只需点击播放按钮即可执行指定作业。例如，在下面的图片中，`production` 舞台上有一项手动操作。 155 | 156 | [![管道示例](https://docs.gitlab.com/ee/ci/img/pipelines.png)](https://docs.gitlab.com/ee/ci/img/pipelines.png) 157 | 158 | ### 作业排序 159 | 160 | **常规管道图** 161 | 162 | 在单个管道页面中，作业按名称排序。 163 | 164 | **迷你管道图** 165 | 166 | > 在GitLab 9.0中[引入](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9760)。 167 | 168 | 在管道迷你图中，作业首先按重要性排序，然后按名称排序。重要性的顺序是： 169 | 170 | - 失败 171 | - 警告 172 | - 有待 173 | - 赛跑 174 | - 手册 175 | - 取消 176 | - 成功 177 | - 跳过 178 | - 创建 179 | 180 | [![管道迷你图排序](https://docs.gitlab.com/ee/ci/img/pipelines_mini_graph_sorting.png)](https://docs.gitlab.com/ee/ci/img/pipelines_mini_graph_sorting.png) 181 | 182 | ### 多项目管道图 183 | 184 | > 可在GitLab Premium 、GitLab Sliver或更高级版本中使用。 185 | 186 | [多项目管道](https://docs.gitlab.com/ee/ci/multi_project_pipelines.html)，您可以访问跨项目管道。 187 | 188 | ## 如何计算管道持续时间 189 | 190 | 管道的总运行时间将排除重试和待处理（排队）时间。我们可以将这个问题缩减为寻找周期的联合。 191 | 192 | 所以每个工作都会被表示为 `Period`，其中包括 `Period#first`工作开始`Period#last`时和工作完成时。一个简单的例子是： 193 | 194 | - A（1,3） 195 | - B（2,4） 196 | - C（6,7） 197 | 198 | 这里A从1开始，到3结束。B从2开始，并到4结束。C从6开始，到7结束。视觉上它可以被看作： 199 | 200 | ``` 201 | 0 1 2 3 4 5 6 7 202 | AAAAAAA 203 | BBBBBBB 204 | CCCC 205 | ``` 206 | 207 | A，B和C的联合将是（1,4）和（6,7），因此总运行时间应该是： 208 | 209 | ``` 210 | (4 - 1) + (7 - 6) => 4 211 | ``` 212 | 213 | ## 徽章 214 | 215 | 管道状态和测试范围内报告徽章可用。您可以在[管道设置](https://docs.gitlab.com/ee/user/project/pipelines/settings.html)页面找到它们各自的链接。 216 | 217 | ## 受保护分行的安全 218 | 219 | 管道在[受保护的分支](https://docs.gitlab.com/ee/user/project/protected_branches.html)上执行时，将执行严格的安全模型 。 220 | 221 | 只有在[允许](https://docs.gitlab.com/ee/user/project/protected_branches.html#using-the-allowed-to-merge-and-allowed-to-push-settings)用户[合并或推送](https://docs.gitlab.com/ee/user/project/protected_branches.html#using-the-allowed-to-merge-and-allowed-to-push-settings) 特定分支时，才允许在受保护的分支上执行以下操作 ： 222 | 223 | - 运行**手动管道**（使用Web UI或Pipelines API） 224 | - 运行**预定的管道** 225 | - 使用**触发器**运行管道 226 | - 在现有管线上触发**手动操作** 227 | - **重试/取消**现有作业（使用Web UI或Pipelines API） 228 | 229 | 标记为**受保护的变量**仅适用于在受保护分支上运行的作业，从而避免不受信任的用户无意中访问敏感信息，如部署凭证和令牌。 230 | 231 | 标记为**受保护的Runners**只能保护分支机构运行的作业，避免不受信任的代码要在保护runner和保存部署键被意外地触发或其他凭证执行。为了确保打算在受保护的跑步者上执行的工作不会使用常规runner，必须对其进行相应标记。 232 | 233 | [帮助改进此翻译](https://github.com/Fennay/gitlab-ci-cn/blob/master/pipelines.md) 234 | 235 | -------------------------------------------------------------------------------- /GitLab CI.md: -------------------------------------------------------------------------------- 1 | # GitLab 持续集成 (GitLab CI) 2 | 3 | ![ss](https://docs.gitlab.com/ee/ci/img/cicd_pipeline_infograph.png) 4 | 5 | 当自动化在你的工作中扮演一个不可或缺的角色时，持续集成带来的收益是巨大的。GitLab具有内置的持续集成、持续部署和持续交付来构建、测试和部署应用程序。 6 | 7 | 这里有一些我们收集到的信息带你开始持续集成。 8 | 9 | ## 开始 10 | 11 | 向你的GitLab CI旅程迈出的第一步。 12 | 13 | - [开始使用GitLab CI](https://fennay.github.io/gitlab-ci-cn/quick_start.html) 14 | - [Pipelines and jobs](https://docs.gitlab.com/ee/ci/pipelines.html) 15 | - [配置Runner，让它运行你的程序](https://docs.gitlab.com/ee/ci/runners/README.html) 16 | - 参考文章 17 | - [Getting started with GitLab and GitLab CI - Intro to CI](https://about.gitlab.com/2015/12/14/getting-started-with-gitlab-and-gitlab-ci/) 18 | - [Continuous Integration, Delivery, and Deployment with GitLab - Intro to CI/CD](https://about.gitlab.com/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/) 19 | - [GitLab CI: Run jobs sequentially, in parallel, or build a custom pipeline](https://about.gitlab.com/2016/07/29/the-basics-of-gitlab-ci/) 20 | - [Setting up GitLab Runner For Continuous Integration](https://about.gitlab.com/2016/03/01/gitlab-runner-with-docker/) 21 | - [GitLab CI: Deployment & environments](https://about.gitlab.com/2016/08/26/ci-deployment-and-environments/) 22 | - 视频： 23 | - [Demo (Streamed live on Jul 17, 2017): GitLab CI/CD Deep Dive](https://youtu.be/pBe4t1CD8Fc?t=195) 24 | - [Demo (March, 2017): how to get started using CI/CD with GitLab](https://about.gitlab.com/2017/03/13/ci-cd-demo/) 25 | - [Webcast (April, 2016): getting started with CI in GitLab](https://about.gitlab.com/2016/04/20/webcast-recording-and-slides-introduction-to-ci-in-gitlab/) 26 | - 第三方视频 27 | - [Intégration continue avec GitLab (September, 2016)](https://www.youtube.com/watch?v=URcMBXjIr24&t=13s) 28 | - [GitLab CI for Minecraft Plugins (July, 2016)](https://www.youtube.com/watch?v=Z4pcI9F8yf8) 29 | 30 | ## 参考指南 31 | 32 | 一旦你熟悉了入门指南，你就可以去查阅特定的参考指南。 33 | 34 | - [`.gitlab-ci.yml`指南](https://fennay.github.io/gitlab-ci-cn/quick_start.html) - 了解关于`.gitlab-ci.yml`的所有细节和参数设置。 35 | - CI Variables - 了解如何在你的`.gitlab-ci.yml`中使用变量或者保证项目中变量的安全。 36 | - 权限模型 - 了解用户执行某些CI操作的访问级别 37 | - [用户权限](https://docs.gitlab.com/ee/user/permissions.html#gitlab-ci) 38 | - [Job权限](https://docs.gitlab.com/ee/user/permissions.html#job-permissions) 39 | 40 | ## Auto DevOps 41 | 42 | - [Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/index.html) 43 | 44 | ## GitLab CI + Docker 45 | 46 | 利用Docker的能力来运行CI pipelines。 47 | 48 | - 使用docker 镜像执行 GitLab Runner。 49 | - 使用CI构建 docker 镜像 50 | - CI 服务（链接docker容器） 51 | - 文章 52 | - [Setting up GitLab Runner For Continuous Integration](https://about.gitlab.com/2016/03/01/gitlab-runner-with-docker/) 53 | 54 | ## 高级使用 55 | 56 | 一旦你熟悉了GitLab CI的基础知识，就该开始学习如何利用它的潜能了。 57 | 58 | - [Environments and deployments](https://docs.gitlab.com/ee/ci/environments.html) - 将你的工作分成不同的环境，并将它们用于不同的目的，如测试、构建和部署。 59 | - [Job artifacts](https://docs.gitlab.com/ee/user/project/pipelines/job_artifacts.html) 60 | - [Git submodules](https://docs.gitlab.com/ee/ci/git_submodules.html) - 在涉及Git子模块时如何运行CI jobs 61 | - [Auto deploy](https://docs.gitlab.com/ee/ci/autodeploy/index.html) 62 | - [Use SSH keys in your build environment](https://docs.gitlab.com/ee/ci/ssh_keys/README.html) and status of each CI environment running on Kubernetes 63 | - [Trigger pipelines through the GitLab API](https://docs.gitlab.com/ee/ci/triggers/README.html) 64 | - [Trigger pipelines on a schedule](https://docs.gitlab.com/ee/user/project/pipelines/schedules.html) 65 | - [Deploy Boards](https://docs.gitlab.com/ee/user/project/deploy_boards.html) - 检查当前状况 66 | - [Kubernetes clusters](https://docs.gitlab.com/ee/user/project/clusters/index.html) - 将一个或多个Kubernetes集群集成到项目中。 67 | 68 | ## Review Apps 69 | 70 | - [Review Apps](https://docs.gitlab.com/ee/ci/review_apps/index.html) 71 | - 参考文章: 72 | - [Introducing Review Apps](https://about.gitlab.com/2016/11/22/introducing-review-apps/) 73 | - [Example project that shows how to use Review Apps](https://gitlab.com/gitlab-examples/review-apps-nginx/) 74 | 75 | ## GitLab CI for GitLab Pages 76 | 77 | See the topic on [GitLab Pages](https://docs.gitlab.com/ee/user/project/pages/index.html). 78 | 79 | ## 特殊配置 80 | 81 | 你可以在你的整个GitLab实例以及每个项目中更改GitLab CI的默认行为。 82 | 83 | - Project specific 84 | - [Pipelines settings](https://docs.gitlab.com/ee/user/project/pipelines/settings.html) 85 | - [Learn how to enable or disable GitLab CI](https://docs.gitlab.com/ee/ci/enable_or_disable_ci.html) 86 | - Affecting the whole GitLab instance 87 | - [Continuous Integration admin settings](https://docs.gitlab.com/ee/user/admin_area/settings/continuous_integration.html) 88 | 89 | ## 示例 90 | 91 | > 注意：[GitLab CI Yml 项目](https://gitlab.com/gitlab-org/gitlab-ci-yml)是官方维护的`.gitlab-ci.yml`文件集合。如果你最爱的编程语言或框架没有`.gitlab-ci.yml`文件，我们非常欢迎你通过提交merge request来帮忙。 92 | 93 | 这里有一些关于设置CI pipline的教程和指南。 94 | 95 | - [GitLab CI示例](https://docs.gitlab.com/ee/ci/examples/README.html)： 96 | - [PHP](https://docs.gitlab.com/ee/ci/examples/php.html) 97 | - [Ruby](https://docs.gitlab.com/ee/ci/examples/test-and-deploy-ruby-application-to-heroku.html) 98 | - [Python](https://docs.gitlab.com/ee/ci/examples/test-and-deploy-python-application-to-heroku.html) 99 | - [Clojure](https://docs.gitlab.com/ee/ci/examples/test-clojure-application.html) 100 | - [Scala](https://docs.gitlab.com/ee/ci/examples/test-scala-application.html) 101 | - [Phoenix](https://docs.gitlab.com/ee/ci/examples/test-phoenix-application.html) 102 | - [Run PHP Composer & NPM scripts then deploy them to a staging server](https://docs.gitlab.com/ee/ci/examples/deployment/composer-npm-deploy.html) 103 | - [Analyze code quality with the Code Climate CLI](https://docs.gitlab.com/ee/ci/examples/code_climate.html) 104 | - 参考文章： 105 | - [How to test and deploy Laravel/PHP applications with GitLab CI/CD and Envoy](https://docs.gitlab.com/ee/articles/laravel_with_gitlab_and_envoy/index.html) 106 | - [How to deploy Maven projects to Artifactory with GitLab CI/CD](https://docs.gitlab.com/ee/ci/examples/artifactory_and_gitlab/index.html) 107 | - [Automated Debian packaging](https://about.gitlab.com/2016/10/12/automated-debian-package-build-with-gitlab-ci/) 108 | - [Spring boot application with GitLab CI and Kubernetes](https://about.gitlab.com/2016/12/14/continuous-delivery-of-a-spring-boot-application-with-gitlab-ci-and-kubernetes/) 109 | - [Setting up GitLab CI for iOS projects](https://about.gitlab.com/2016/03/10/setting-up-gitlab-ci-for-ios-projects/) 110 | - [Setting up GitLab CI for Android projects](https://about.gitlab.com/2016/11/30/setting-up-gitlab-ci-for-android-projects/) 111 | - [Building a new GitLab Docs site with Nanoc, GitLab CI, and GitLab Pages](https://about.gitlab.com/2016/12/07/building-a-new-gitlab-docs-site-with-nanoc-gitlab-ci-and-gitlab-pages/) 112 | - [CI/CD with GitLab in action](https://about.gitlab.com/2017/03/13/ci-cd-demo/) 113 | - [Building an Elixir Release into a Docker image using GitLab CI](https://about.gitlab.com/2016/08/11/building-an-elixir-release-into-docker-image-using-gitlab-ci-part-1/) 114 | - 杂项 115 | - [Using `dpl` as deployment tool](https://docs.gitlab.com/ee/ci/examples/deployment/README.html) 116 | - [Repositories with examples for various languages](https://gitlab.com/groups/gitlab-examples) 117 | - [The .gitlab-ci.yml file for GitLab itself](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/.gitlab-ci.yml) 118 | - [Example project that shows how to use Review Apps](https://gitlab.com/gitlab-examples/review-apps-nginx/) 119 | 120 | ## 集成 121 | 122 | - 参考文章： 123 | - [Continuous Delivery with GitLab and Convox](https://about.gitlab.com/2016/06/09/continuous-delivery-with-gitlab-and-convox/) 124 | - [Getting Started with GitLab and Shippable Continuous Integration](https://about.gitlab.com/2016/05/05/getting-started-gitlab-and-shippable/) 125 | - [GitLab Partners with DigitalOcean to make Continuous Integration faster, safer, and more affordable](https://about.gitlab.com/2016/04/19/gitlab-partners-with-digitalocean-to-make-continuous-integration-faster-safer-and-more-affordable/) 126 | 127 | ## 为什么选择GitLab CI？ 128 | 129 | - 参考文章： 130 | - [Why We Chose GitLab CI for our CI/CD Solution](https://about.gitlab.com/2016/10/17/gitlab-ci-oohlala/) 131 | - [Building our web-app on GitLab CI: 5 reasons why Captain Train migrated from Jenkins to GitLab CI](https://about.gitlab.com/2016/07/22/building-our-web-app-on-gitlab-ci/) 132 | 133 | ## 正在发生的变化 134 | 135 | - [为GitLab 9.0重命名CI变量](https://docs.gitlab.com/ee/ci/variables/README.html#9-0-renaming) 阅读一些已经不推荐的CI变量，以及如何使用GitLab 9.0+。 136 | - [新的CI工作权限模型](https://docs.gitlab.com/ee/user/project/new_ci_build_permissions_model.html) 查看在GitLab 8.12中发生了什么变化，以及这会如何影响工作。有一种新的方法可以访问工作中的Git子模块和LFS对象。 137 | 138 | 139 | 140 | [编辑此页面](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/doc/ci/README.md) -------------------------------------------------------------------------------- /Variables.md: -------------------------------------------------------------------------------- 1 | # Variables 2 | 3 | 官方文档：https://docs.gitlab.com/ce/ci/variables/README.html 4 | 5 | 当GitLab CI 中接受到一个job后，[Runner](https://docs.gitlab.com/runner/)就开始准备构建环境。开始设置预定义的变量(环境变量)和用户自定义的变量。 6 | 7 | ## variables 的执行顺序 8 | 9 | 变量可以被重写，并且是按照下面的顺序进行执行： 10 | 11 | 1. [Trigger variables](https://docs.gitlab.com/ce/ci/triggers/README.html#pass-job-variables-to-a-trigger)(优先级最高) 12 | 2. [Secret variables](https://docs.gitlab.com/ce/ci/variables/README.html#secret-variables) 13 | 3. YAML-defined [job-level variables](https://docs.gitlab.com/ce/ci/yaml/README.html#job-variables) 14 | 4. YAML-defined [global variables](https://docs.gitlab.com/ce/ci/yaml/README.html#variables) 15 | 5. [Deployment variables](https://docs.gitlab.com/ce/ci/variables/README.html#deployment-variables) 16 | 6. [Predefined variables](https://docs.gitlab.com/ce/ci/variables/README.html#predefined-variables-environment-variables) (优先级最低) 17 | 18 | 举个例子，如果你定义了私有变量`API_TOKEN=secure`，并且在`.gitlab-ci.yml`中定义了 ` API_TOKEN=yaml`，那么私有变量`API_TOKEN`的值将是`secure`，因为secret variables的优先级较高。 19 | 20 | ## Predefined variables(Environment variables) 21 | 22 | 有部分预定义的环境变量仅仅只能在最小版本的[GitLab Runner](https://docs.gitlab.com/runner/)中使用。请参考下表查看对应的Runner版本要求。 23 | 24 | > **注意**：从GitLab 9.0 开始，部分变量已经不提倡使用。请查看[9.0 Renaming](https://docs.gitlab.com/ce/ci/variables/README.html#9-0-renaming)部分来查找他们的替代变量。强烈建议使用新的变量，我们也会在将来的GitLab版本中将他们移除。 25 | 26 | | Variable | GitLab | Runner | Description | 27 | | :----------------------------- | ------ | ------ | ---------------------------------------- | 28 | | **CI** | all | 0.4 | 标识该job是在CI环境中执行 | 29 | | **CI_COMMIT_REF_NAME** | 9.0 | all | 用于构建项目的分支或tag名称 | 30 | | **CI_COMMIT_REF_SLUG** | 9.0 | all | 先将`$CI_COMMIT_REF_NAME`的值转换成小写，最大不能超过63个字节，然后把除了`0-9`和`a-z`的其他字符转换成`-`。在URLs和域名名称中使用。 | 31 | | **CI_COMMIT_SHA** | 9.0 | all | commit的版本号 | 32 | | **CI_COMMIT_TAG** | 9.0 | 0.5 | commit的tag名称。只有创建了tags才会出现。 | 33 | | **CI_DEBUG_TRACE** | 9.0 | 1.7 | [debug tracing](https://docs.gitlab.com/ce/ci/variables/README.html#debug-tracing)开启时才生效 | 34 | | **CI_ENVIRONMENT_NAME** | 8.15 | all | job的环境名称 | 35 | | **CI_ENVIRONMENT_SLUG** | 8.15 | all | 环境名称的简化版本，适用于DNS，URLs，Kubernetes labels等 | 36 | | **CI_JOB_ID** | 9.0 | all | GItLab CI内部调用job的一个唯一ID | 37 | | **CI_JOB_MANUAL** | 8.12 | all | 表示job启用的标识 | 38 | | **CI_JOB_NAME** | 9.0 | 0.5 | `.gitlab-ci.yml`中定义的job的名称 | 39 | | **CI_JOB_STAGE** | 9.0 | 0.5 | `.gitlab-ci.yml`中定义的stage的名称 | 40 | | **CI_JOB_TOKEN** | 9.0 | 1.2 | 用于同GitLab容器仓库验证的token | 41 | | **CI_REPOSITORY_URL** | 9.0 | all | git仓库地址，用于克隆 | 42 | | **CI_RUNNER_DESCRIPTION** | 8.10 | 0.5 | GitLab中存储的Runner描述 | 43 | | **CI_RUNNER_ID** | 8.10 | 0.5 | Runner所使用的唯一ID | 44 | | **CI_RUNNER_TAGS** | 8.10 | 0.5 | Runner定义的tags | 45 | | **CI_PIPELINE_ID** | 8.10 | 0.5 | GitLab CI 在内部使用的当前pipeline的唯一ID | 46 | | **CI_PIPELINE_TRIGGERED** | all | all | 用于指示该job被触发的标识 | 47 | | **CI_PROJECT_DIR** | all | all | 仓库克隆的完整地址和job允许的完整地址 | 48 | | **CI_PROJECT_ID** | all | all | GitLab CI在内部使用的当前项目的唯一ID | 49 | | **CI_PROJECT_NAME** | 8.10 | 0.5 | 当前正在构建的项目名称（事实上是项目文件夹名称） | 50 | | **CI_PROJECT_NAMESPACE** | 8.10 | 0.5 | 当前正在构建的项目命名空间（用户名或者是组名称） | 51 | | **CI_PROJECT_PATH** | 8.10 | 0.5 | 命名空间加项目名称 | 52 | | **CI_PROJECT_PATH_SLUG** | 9.3 | all | `$CI_PROJECT_PATH`小写字母、除了`0-9`和`a-z`的其他字母都替换成`-`。用于地址和域名名称。 | 53 | | **CI_PROJECT_URL** | 8.10 | 0.5 | 项目的访问地址（http形式） | 54 | | **CI_REGISTRY** | 8.10 | 0.5 | 如果启用了Container Registry，则返回GitLab的Container Registry的地址 | 55 | | **CI_REGISTRY_IMAGE** | 8.10 | 0.5 | 如果为项目启用了Container Registry，它将返回与特定项目相关联的注册表的地址 | 56 | | **CI_REGISTRY_PASSWORD** | 9.0 | all | 用于push containers到GitLab的Container Registry的密码 | 57 | | **CI_REGISTRY_USER** | 9.0 | all | 用于push containers到GItLab的Container Registry的用户名 | 58 | | **CI_SERVER** | all | all | 标记该job是在CI环境中执行 | 59 | | **CI_SERVER_NAME** | all | all | 用于协调job的CI服务器名称 | 60 | | **CI_SERVER_REVISION** | all | all | 用于调度job的GitLab修订版 | 61 | | **CI_SERVER_VERSION** | all | all | 用于调度job的GItLab版本 | 62 | | **ARTIFACT_DOWNLOAD_ATTEMPTS** | 8.15 | 1.9 | 尝试运行下载artifacts的job的次数 | 63 | | **GET_SOURCES_ATTEMPTS** | 8.15 | 1.9 | 尝试运行获取源的job次数 | 64 | | **GITLAB_CI** | all | all | 用于指示该job是在GItLab CI环境中运行 | 65 | | **GITLAB_USER_ID** | 8.12 | all | 开启该job的用户ID | 66 | | **GITLAB_USER_EMAIL** | 8.12 | all | 开启该job的用户邮箱 | 67 | | **RESTORE_CACHE_ATTEMPTS** | 8.15 | 1.9 | 尝试运行存储缓存的job的次数 | 68 | 69 | ## 9.0 Renaming 70 | 71 | 根据GitLab的命名规则，在9.0以后将从`build`术语转到`job`CI变量中，并且已经被重命名。 72 | 73 | | 8.x name | 9.0+ name | 74 | | -------------------- | ----------------------- | 75 | | `CI_BUILD_ID` | `CI_JOB_ID` | 76 | | `CI_BUILD_REF` | `CI_COMMIT_SHA` | 77 | | `CI_BUILD_TAG` | `CI_COMMIT_TAG` | 78 | | `CI_BUILD_REF_NAME` | `CI_COMMIT_REF_NAME` | 79 | | `CI_BUILD_REF_SLUG` | `CI_COMMIT_REF_SLUG` | 80 | | `CI_BUILD_NAME` | `CI_JOB_NAME` | 81 | | `CI_BUILD_STAGE` | `CI_JOB_STAGE` | 82 | | `CI_BUILD_REPO` | `CI_REPOSITORY_URL` | 83 | | `CI_BUILD_TRIGGERED` | `CI_PIPELINE_TRIGGERED` | 84 | | `CI_BUILD_MANUAL` | `CI_JOB_MANUAL` | 85 | | `CI_BUILD_TOKEN` | `CI_JOB_TOKEN` | 86 | 87 | ## `.gitlab-ci.yaml` defined variables 88 | 89 | > 注意：此功能要求GitLab Runner 0.5或者更高版本，并且GitLab CI 7.14或者更高版本 90 | 91 | GitLab CI允许你向`.gitlab-ci.yml`中添加变量，这个变量在构建环境中设置。因此，变量将保存在存储中，他们用于存储非敏感的项目配置，例如：`RAILS_ENV`或者`DATABASE_URL`。 92 | 93 | 举个例子，如果将变量设置为全局以下（不是在一个作业中），则它将用于所有执行的命令脚本中： 94 | 95 | ```yaml 96 | variables: 97 | DATABASE_URL: "postgres://postgres@postgres/my_database" 98 | ``` 99 | 100 | YAML中定义的变量也将应用到所有创建的服务容器中，因此可以对它进行微调。 101 | 102 | 变量可以定义为全局，同时也可以定义为job级别。若要关闭作业中的全局定义变量，请定义一个空hash： 103 | 104 | ```yaml 105 | job_name: 106 | variables: {} 107 | ``` 108 | 109 | 您可以在变量定义中使用其他变量（或使用$$将其转义）： 110 | 111 | ```yaml 112 | variables: 113 | LS_CMD: 'ls $FLAGS $$TMP_DIR' 114 | FLAGS: '-al' 115 | script: 116 | - 'eval $LS_CMD' # will execute 'ls -al $TMP_DIR' 117 | ``` 118 | 119 | ## Secret variables 120 | 121 | > 注意： 122 | > 123 | > - 这个功能需要GitLab Runner 0.4.0或者更高版本。 124 | > - 请注意，私有变量不会隐藏，如果明确要这么做，他们的值可以显示在job日志中。如果您的项目是公共的或内部的，你可以在项目的pipeline中设置pipeline为私有的。关于私有变量的讨论在issue [#13784](https://gitlab.com/gitlab-org/gitlab-ce/issues/13784)。 125 | 126 | GitLab CI允许你在构建环境过程中设置项目的私有变量。私有变量存储在仓库(.gitlab-ci.yml)中，并被安全的传递给GitLab Runner，使其在构建环境中可用。建议使用该方法存储诸如密码、秘钥和凭据之类的东西。 127 | 128 | 可用通过**Settings ➔ Pipelines**来增加私有变量，通过**Settings ➔ Pipelines**找到的模块称之为私有变量。 129 | 130 | 一次设置，所有的后续pipeline是都可以使用它们。 131 | 132 | ## Protected secret variables 133 | 134 | > 注意：此功能要求GitLab 9.3或者更高。 135 | 136 | 私有变量可以被保护。每当一个私有变量被保护时，它只会安全的传递到在[受保护的分支](https://docs.gitlab.com/ce/user/project/protected_branches.html)或[受保护的标签](https://docs.gitlab.com/ce/user/project/protected_tags.html)上运行的pipeline。其他的pipeline将不会得到受保护的变量。 137 | 138 | 可用通过**Settings ➔ Pipelines**来增加私有变量，通过**Settings ➔ Pipelines**找到的模块称之为私有变量，然后点击*Protected*。 139 | 140 | 一次设置，所有的后续pipeline是都可以使用它们。 141 | 142 | ## Deploment variables 143 | 144 | > 注意：此功能要求GitLab CI 8.15或者更高版本。 145 | 146 | 负责部署配置的[项目服务](https://docs.gitlab.com/ce/user/project/integrations/project_services.html)可以定义在构建环境中设置自己的变量。这些变量只定义用于[部署job](https://docs.gitlab.com/ce/ci/environments.html)。请参考您正在使用的项目服务的文档，以了解他们定义的变量。 147 | 148 | 一个定义有部署变量的项目服务示例[Kubernetes Service](https://docs.gitlab.com/ce/user/project/integrations/kubernetes.html)。 149 | 150 | ## Debug tracing 151 | 152 | > GitLab Runner 1.7开始引入。 153 | > 154 | > **警告**：启用调试跟踪可能会严重的安全隐患。输出内容将包含所有的私有变量和其他的隐私！输出的内容将被上传到GitLab服务器并且将会在job记录中明显体现。 155 | 156 | 默认情况下，GitLab Runner会隐藏了处理job时正在做的大部分细节。这种行为使job跟踪很短，并且防止秘密泄露到跟踪中，除非您的脚本将他们输出到屏幕中。 157 | 158 | 如果job没有按照预期的运行，这也会让问题查找变得更加困难；在这种情况下，你可以在`.gitlab-ci.yml`中开启调试记录。它需要GitLab Runner v1.7版本以上，此功能可启用shell的执行记录，从而产生详细的job记录，列出所有执行的命令，设置变量等。 159 | 160 | 在启用此功能之前，您应该确保job只对[团队成](https://docs.gitlab.com/ce/user/permissions.html#project-features)员可见。您也应该https://docs.gitlab.com/ce/ci/pipelines.html#seeing-build-status所有生成的job记录，然后使其可见。 161 | 162 | 设置`CI_DEBUG_TRACE`变量的值为`true`来开启调试记录。 163 | 164 | ```yaml 165 | job_name: 166 | variables: 167 | CI_DEBUG_TRACE: "true" 168 | ``` 169 | 170 | 调试记录设置为TRUE的截断输出示例： 171 | 172 | ```shell 173 | ... 174 | 175 | export CI_SERVER_TLS_CA_FILE="/builds/gitlab-examples/ci-debug-trace.tmp/CI_SERVER_TLS_CA_FILE" 176 | if [[ -d "/builds/gitlab-examples/ci-debug-trace/.git" ]]; then 177 | echo $'\''\x1b[32;1mFetching changes...\x1b[0;m'\'' 178 | $'\''cd'\'' "/builds/gitlab-examples/ci-debug-trace" 179 | $'\''git'\'' "config" "fetch.recurseSubmodules" "false" 180 | $'\''rm'\'' "-f" ".git/index.lock" 181 | $'\''git'\'' "clean" "-ffdx" 182 | $'\''git'\'' "reset" "--hard" 183 | $'\''git'\'' "remote" "set-url" "origin" "https://gitlab-ci-token:xxxxxxxxxxxxxxxxxxxx@example.com/gitlab-examples/ci-debug-trace.git" 184 | $'\''git'\'' "fetch" "origin" "--prune" "+refs/heads/*:refs/remotes/origin/*" "+refs/tags/*:refs/tags/*" 185 | else 186 | $'\''mkdir'\'' "-p" "/builds/gitlab-examples/ci-debug-trace.tmp/git-template" 187 | $'\''rm'\'' "-r" "-f" "/builds/gitlab-examples/ci-debug-trace" 188 | $'\''git'\'' "config" "-f" "/builds/gitlab-examples/ci-debug-trace.tmp/git-template/config" "fetch.recurseSubmodules" "false" 189 | echo $'\''\x1b[32;1mCloning repository...\x1b[0;m'\'' 190 | $'\''git'\'' "clone" "--no-checkout" "https://gitlab-ci-token:xxxxxxxxxxxxxxxxxxxx@example.com/gitlab-examples/ci-debug-trace.git" "/builds/gitlab-examples/ci-debug-trace" "--template" "/builds/gitlab-examples/ci-debug-trace.tmp/git-template" 191 | $'\''cd'\'' "/builds/gitlab-examples/ci-debug-trace" 192 | fi 193 | echo $'\''\x1b[32;1mChecking out dd648b2e as master...\x1b[0;m'\'' 194 | $'\''git'\'' "checkout" "-f" "-q" "dd648b2e48ce6518303b0bb580b2ee32fadaf045" 195 | ' 196 | +++ hostname 197 | ++ echo 'Running on runner-8a2f473d-project-1796893-concurrent-0 via runner-8a2f473d-machine-1480971377-317a7d0f-digital-ocean-4gb...' 198 | Running on runner-8a2f473d-project-1796893-concurrent-0 via runner-8a2f473d-machine-1480971377-317a7d0f-digital-ocean-4gb... 199 | ++ export CI=true 200 | ++ CI=true 201 | ++ export CI_DEBUG_TRACE=false 202 | ++ CI_DEBUG_TRACE=false 203 | ++ export CI_COMMIT_SHA=dd648b2e48ce6518303b0bb580b2ee32fadaf045 204 | ++ CI_COMMIT_SHA=dd648b2e48ce6518303b0bb580b2ee32fadaf045 205 | ++ export CI_COMMIT_BEFORE_SHA=dd648b2e48ce6518303b0bb580b2ee32fadaf045 206 | ++ CI_COMMIT_BEFORE_SHA=dd648b2e48ce6518303b0bb580b2ee32fadaf045 207 | ++ export CI_COMMIT_REF_NAME=master 208 | ++ CI_COMMIT_REF_NAME=master 209 | ++ export CI_JOB_ID=7046507 210 | ++ CI_JOB_ID=7046507 211 | ++ export CI_REPOSITORY_URL=https://gitlab-ci-token:xxxxxxxxxxxxxxxxxxxx@example.com/gitlab-examples/ci-debug-trace.git 212 | ++ CI_REPOSITORY_URL=https://gitlab-ci-token:xxxxxxxxxxxxxxxxxxxx@example.com/gitlab-examples/ci-debug-trace.git 213 | ++ export CI_JOB_TOKEN=xxxxxxxxxxxxxxxxxxxx 214 | ++ CI_JOB_TOKEN=xxxxxxxxxxxxxxxxxxxx 215 | ++ export CI_PROJECT_ID=1796893 216 | ++ CI_PROJECT_ID=1796893 217 | ++ export CI_PROJECT_DIR=/builds/gitlab-examples/ci-debug-trace 218 | ++ CI_PROJECT_DIR=/builds/gitlab-examples/ci-debug-trace 219 | ++ export CI_SERVER=yes 220 | ++ CI_SERVER=yes 221 | ++ export 'CI_SERVER_NAME=GitLab CI' 222 | ++ CI_SERVER_NAME='GitLab CI' 223 | ++ export CI_SERVER_VERSION= 224 | ++ CI_SERVER_VERSION= 225 | ++ export CI_SERVER_REVISION= 226 | ++ CI_SERVER_REVISION= 227 | ++ export GITLAB_CI=true 228 | ++ GITLAB_CI=true 229 | ++ export CI=true 230 | ++ CI=true 231 | ++ export GITLAB_CI=true 232 | ++ GITLAB_CI=true 233 | ++ export CI_JOB_ID=7046507 234 | ++ CI_JOB_ID=7046507 235 | ++ export CI_JOB_TOKEN=xxxxxxxxxxxxxxxxxxxx 236 | ++ CI_JOB_TOKEN=xxxxxxxxxxxxxxxxxxxx 237 | ++ export CI_COMMIT_REF=dd648b2e48ce6518303b0bb580b2ee32fadaf045 238 | ++ CI_COMMIT_REF=dd648b2e48ce6518303b0bb580b2ee32fadaf045 239 | ++ export CI_COMMIT_BEFORE_SHA=dd648b2e48ce6518303b0bb580b2ee32fadaf045 240 | ++ CI_COMMIT_BEFORE_SHA=dd648b2e48ce6518303b0bb580b2ee32fadaf045 241 | ++ export CI_COMMIT_REF_NAME=master 242 | ++ CI_COMMIT_REF_NAME=master 243 | ++ export CI_COMMIT_NAME=debug_trace 244 | ++ CI_JOB_NAME=debug_trace 245 | ++ export CI_JOB_STAGE=test 246 | ++ CI_JOB_STAGE=test 247 | ++ export CI_SERVER_NAME=GitLab 248 | ++ CI_SERVER_NAME=GitLab 249 | ++ export CI_SERVER_VERSION=8.14.3-ee 250 | ++ CI_SERVER_VERSION=8.14.3-ee 251 | ++ export CI_SERVER_REVISION=82823 252 | ++ CI_SERVER_REVISION=82823 253 | ++ export CI_PROJECT_ID=17893 254 | ++ CI_PROJECT_ID=17893 255 | ++ export CI_PROJECT_NAME=ci-debug-trace 256 | ++ CI_PROJECT_NAME=ci-debug-trace 257 | ++ export CI_PROJECT_PATH=gitlab-examples/ci-debug-trace 258 | ++ CI_PROJECT_PATH=gitlab-examples/ci-debug-trace 259 | ++ export CI_PROJECT_NAMESPACE=gitlab-examples 260 | ++ CI_PROJECT_NAMESPACE=gitlab-examples 261 | ++ export CI_PROJECT_URL=https://example.com/gitlab-examples/ci-debug-trace 262 | ++ CI_PROJECT_URL=https://example.com/gitlab-examples/ci-debug-trace 263 | ++ export CI_PIPELINE_ID=52666 264 | ++ CI_PIPELINE_ID=52666 265 | ++ export CI_RUNNER_ID=1337 266 | ++ CI_RUNNER_ID=1337 267 | ++ export CI_RUNNER_DESCRIPTION=shared-runners-manager-1.example.com 268 | ++ CI_RUNNER_DESCRIPTION=shared-runners-manager-1.example.com 269 | ++ export 'CI_RUNNER_TAGS=shared, docker, linux, ruby, mysql, postgres, mongo' 270 | ++ CI_RUNNER_TAGS='shared, docker, linux, ruby, mysql, postgres, mongo' 271 | ++ export CI_REGISTRY=registry.example.com 272 | ++ CI_REGISTRY=registry.example.com 273 | ++ export CI_DEBUG_TRACE=true 274 | ++ CI_DEBUG_TRACE=true 275 | ++ export GITLAB_USER_ID=42 276 | ++ GITLAB_USER_ID=42 277 | ++ export GITLAB_USER_EMAIL=user@example.com 278 | ++ GITLAB_USER_EMAIL=user@example.com 279 | ++ export VERY_SECURE_VARIABLE=imaverysecurevariable 280 | ++ VERY_SECURE_VARIABLE=imaverysecurevariable 281 | ++ mkdir -p /builds/gitlab-examples/ci-debug-trace.tmp 282 | ++ echo -n '-----BEGIN CERTIFICATE----- 283 | MIIFQzCCBCugAwIBAgIRAL/ElDjuf15xwja1ZnCocWAwDQYJKoZIhvcNAQELBQAw' 284 | ... 285 | ``` 286 | 287 | ## Using the CI variables in your job scripts 288 | 289 | 在构建环境变量时，所有的变量都被设置为环境变量，他们可以使用普通方法访问这些变量。在大多数情况下，用于执行job脚本都是通过bash或者是sh。 290 | 291 | 想要访问环境变量，请示使用一下Runner对应的语法： 292 | 293 | | Shell | 用法 | 294 | | ------------- | --------------- | 295 | | bash/sh | `$variable` | 296 | | windows batch | `%variable%` | 297 | | PowerShell | `$env:variable` | 298 | 299 | 在bash中访问环境变量，需要给变量名称加上前缀(`$`)： 300 | 301 | ```yaml 302 | job_name: 303 | script: 304 | - echo $CI_JOB_ID 305 | ``` 306 | 307 | 在Windows系统的PowerShell中访问环境变量，需要给变量名称加上前缀(`$env:`)： 308 | 309 | ```yaml 310 | job_name: 311 | script: 312 | - echo $env:CI_JOB_ID 313 | ``` 314 | 315 | 您可以使用`export`命令来列出所有的环境变量。在使用此命令时要注意，此命令也会在job记录中列出所有私有变量的值： 316 | 317 | ```yaml 318 | job_name: 319 | script: 320 | - export 321 | ``` 322 | 323 | 实例的值： 324 | 325 | ```shell 326 | export CI_JOB_ID="50" 327 | export CI_COMMIT_SHA="1ecfd275763eff1d6b4844ea3168962458c9f27a" 328 | export CI_COMMIT_REF_NAME="master" 329 | export CI_REPOSITORY_URL="https://gitlab-ci-token:abcde-1234ABCD5678ef@example.com/gitlab-org/gitlab-ce.git" 330 | export CI_COMMIT_TAG="1.0.0" 331 | export CI_JOB_NAME="spec:other" 332 | export CI_JOB_STAGE="test" 333 | export CI_JOB_MANUAL="true" 334 | export CI_JOB_TRIGGERED="true" 335 | export CI_JOB_TOKEN="abcde-1234ABCD5678ef" 336 | export CI_PIPELINE_ID="1000" 337 | export CI_PROJECT_ID="34" 338 | export CI_PROJECT_DIR="/builds/gitlab-org/gitlab-ce" 339 | export CI_PROJECT_NAME="gitlab-ce" 340 | export CI_PROJECT_NAMESPACE="gitlab-org" 341 | export CI_PROJECT_PATH="gitlab-org/gitlab-ce" 342 | export CI_PROJECT_URL="https://example.com/gitlab-org/gitlab-ce" 343 | export CI_REGISTRY="registry.example.com" 344 | export CI_REGISTRY_IMAGE="registry.example.com/gitlab-org/gitlab-ce" 345 | export CI_RUNNER_ID="10" 346 | export CI_RUNNER_DESCRIPTION="my runner" 347 | export CI_RUNNER_TAGS="docker, linux" 348 | export CI_SERVER="yes" 349 | export CI_SERVER_NAME="GitLab" 350 | export CI_SERVER_REVISION="70606bf" 351 | export CI_SERVER_VERSION="8.9.0" 352 | export GITLAB_USER_ID="42" 353 | export GITLAB_USER_EMAIL="user@example.com" 354 | export CI_REGISTRY_USER="gitlab-ci-token" 355 | export CI_REGISTRY_PASSWORD="longalfanumstring" 356 | ``` -------------------------------------------------------------------------------- /docs/index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 官方GitLab文档翻译 544 | 545 | 546 |
547 |

官方GitLab文档翻译

548 |

英文文档地址：https://docs.gitlab.com/

549 |

已完成内容：

550 | 551 | 552 | 553 | 554 | 555 | 556 | 557 | 558 | 559 | 560 | 561 | 562 | 564 | 565 | 566 | 567 | 568 | 569 | 570 | 571 | 572 | 573 | 574 | 575 | 576 | 577 | 578 | 579 | 580 | 581 | 582 | 583 | 584 | 585 | 586 | 587 | 588 | 589 | 590 |
修改时间内容说明文档地址
2017-12-29gitlab-ci-yamlyaml配置文档https://fennay.github.io/gitlab-ci-cn/gitlab-ci-yaml.html 563 |
2017-07-02Variables变量说明https://fennay.github.io/gitlab-ci-cn/variables.html
2018-01-05Quick start guide快速引导页https://fennay.github.io/gitlab-ci-cn/quick_start.html
2018-01-10GitLab Continuous IntegrationGitLab CIhttps://fennay.github.io/gitlab-ci-cn/gitlab-ci.html
2018-06-23Pipelines and jobs管道https://fennay.github.io/gitlab-ci-cn/pipelines.html
591 |
592 | 593 | -------------------------------------------------------------------------------- /docs/gitlab-ci.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | GitLab CI.md 541 | 542 | 543 |

GitLab 持续集成 (GitLab CI)

ss

当自动化在你的工作中扮演一个不可或缺的角色时，持续集成带来的收益是巨大的。GitLab具有内置的持续集成、持续部署和持续交付来构建、测试和部署应用程序。

这里有一些我们收集到的信息带你开始持续集成。

开始

向你的GitLab CI旅程迈出的第一步。

参考指南

一旦你熟悉了入门指南，你就会发现自己回去查阅特定的参考指南。

Auto DevOps

GitLab CI + Docker

利用Docker的力量来运行CI piplis。

高级使用

一旦你熟悉了GitLab CI的基础知识，就该开始学习如何利用它的潜能了。

Review Apps

GitLab CI for GitLab Pages

See the topic on GitLab Pages.

特殊配置

你可以在你的整个GitLab实例以及每个项目中更改GitLab CI的默认行为。

示例

注意：GitLab CI Yml 项目是官方维护的.gitlab-ci.yml文件集合。如果你最爱的编程语言或框架没有.gitlab-ci.yml文件，我们非常欢迎你通过提交merge request来帮忙。

这里有一些关于设置CI pipline的教程和指南。

集成

为什么选择GitLab CI？

正在发生的变化

 

编辑此页面

544 | 545 | -------------------------------------------------------------------------------- /gitlab-ci-yaml.md: -------------------------------------------------------------------------------- 1 | # 通过 .gitlab-ci.yml配置任务 2 | 3 | 此文档用于描述.gitlab-ci.yml语法，.gitlab-ci.yml文件被用来管理项目的runner 任务。 4 | 5 | 如果想要快速的了解GitLab CI ，可查看[快速引导](https://docs.gitlab.com/ce/ci/quick_start/README.html)。 6 | 7 | ## .gitlab-ci.yml 8 | 9 | 从7.12版本开始，GitLab CI使用[YAML](https://en.wikipedia.org/wiki/YAML)文件(.gitlab-ci.yml)来管理项目配置。该文件存放于项目仓库的根目录，它定义该项目如何构建。 10 | 11 | 开始构建之前YAML文件定义了一系列带有约束说明的任务。这些任务都是以任务名开始并且至少要包含`script`部分： 12 | 13 | ```yaml 14 | job1: 15 | script: "execute-script-for-job1" 16 | 17 | job2: 18 | script: "execute-script-for-job2" 19 | ``` 20 | 21 | 上面这个例子就是一个最简单且带有两个独立任务的CI配置，每个任务分别执行不同的命令。 22 | 23 | `script`可以直接执行系统命令(例如：./configure;make;make install)或者是直接执行脚本(test.sh)。 24 | 25 | 任务是由[Runners](https://docs.gitlab.com/ce/ci/runners/README.html)接管并且由服务器中runner执行。更重要的是，每一个任务的执行过程都是独立运行的。 26 | 27 | 用下面这个例子来说明YAML语法还有更多复杂的任务： 28 | 29 | ```yaml 30 | image: ruby:2.1 31 | services: 32 | - postgres 33 | 34 | before_script: 35 | - bundle install 36 | 37 | after_script: 38 | - rm secrets 39 | 40 | stages: 41 | - build 42 | - test 43 | - deploy 44 | 45 | job1: 46 | stage: build 47 | script: 48 | - execute-script-for-job1 49 | only: 50 | - master 51 | tags: 52 | - docker 53 | ``` 54 | 55 | 下面列出保留字段，这些保留字段不能被定义为`job`名称： 56 | 57 | | 关键字 | 是否必须 | 描述 | 58 | | ------------- | ---- | ---------------------------------------- | 59 | | image | 否 | 用于docker镜像，查看[docker](https://docs.gitlab.com/ce/ci/docker/README.html)文档 | 60 | | services | 否 | 用于docker服务，查看[docker](https://docs.gitlab.com/ce/ci/docker/README.html)文档 | 61 | | stages | 否 | 定义构建阶段 | 62 | | types | 否 | `stages` 的别名(已废除) | 63 | | before_script | 否 | 定义在每个job之前运行的命令 | 64 | | after_script | 否 | 定义在每个job之后运行的命令 | 65 | | variable | 否 | 定义构建变量 | 66 | | cache | 否 | 定义一组文件列表，可在后续运行中使用 | 67 | ### image和services 68 | 69 | 这两个关键字允许使用一个自定义的Docker镜像和一系列的服务，并且可以用于整个job周期。详细配置文档请查看[a separate document](https://docs.gitlab.com/ce/ci/docker/README.html)。 70 | 71 | ### before_script 72 | 73 | `before_script`用来定义所有job之前运行的命令，包括deploy(部署) jobs，但是在修复artifacts之后。它可以是一个数组或者是多行字符串。 74 | 75 | ### after_script 76 | 77 | > GitLab 8.7 开始引入，并且要求Gitlab Runner v1.2 78 | 79 | `after_script`用来定义所有job之后运行的命令。它必须是一个数组或者是多行字符串 80 | 81 | ### stages 82 | 83 | `stages`用来定义可以被job调用的stages。stages的规范允许有灵活的多级pipelines。 84 | 85 | stages中的元素顺序决定了对应job的执行顺序： 86 | 87 | 1. 相同stage的job可以平行执行。 88 | 2. 下一个stage的job会在前一个stage的job成功后开始执行。 89 | 90 | 接下仔细看看这个例子，它包含了3个stage： 91 | 92 | ```yaml 93 | stages: 94 | - build 95 | - test 96 | - deploy 97 | ``` 98 | 99 | 1. 首先，所有`build`的jobs都是并行执行的。 100 | 2. 所有`build`的jobs执行成功后，`test`的jobs才会开始并行执行。 101 | 3. 所有`test`的jobs执行成功，`deploy`的jobs才会开始并行执行。 102 | 4. 所有的`deploy`的jobs执行成功，commit才会标记为`success` 103 | 5. 任何一个前置的jobs失败了，commit会标记为`failed`并且下一个stages的jobs都不会执行。 104 | 105 | 这有两个特殊的例子值得一提： 106 | 107 | 1. 如果`.gitlab-ci.yml`中没有定义`stages`，那么job's stages 会默认定义为 `build`，`test` 和 `deploy`。 108 | 2. 如果一个job没有指定`stage`，那么这个任务会分配到`test` stage。 109 | 110 | ### types 111 | 112 | > 已废除，将会在10.0中移除。用stages替代。 113 | 114 | 与[stages](#)同义 115 | 116 | ### variables 117 | 118 | > GitLab Runner V0.5.0. 开始引入 119 | 120 | GItLab CI 允许在`.gitlab-ci.yml`文件中添加变量，并在job环境中起作用。因为这些配置是存储在git仓库中，所以最好是存储项目的非敏感配置，例如： 121 | 122 | ```yaml 123 | variables: 124 | DATABASE_URL:"postgres://postgres@postgres/my_database" 125 | ``` 126 | 127 | 这些变量可以被后续的命令和脚本使用。服务容器也可以使用YAML中定义的变量，因此我们可以很好的调控服务容器。变量也可以定义成[job level](https://docs.gitlab.com/ce/ci/yaml/README.html#job-variables)。 128 | 129 | 除了用户自定义的变量外，Runner也可以定义它自己的变量。`CI_COMMIT_REG_NAME`就是一个很好的例子，它的值表示用于构建项目的分支或tag名称。除了在`.gitlab-ci.yml`中设置变量外，还有可以通过GitLab的界面上设置私有变量。 130 | 131 | [更多关于variables](https://docs.gitlab.com/ce/ci/variables/README.html)。 132 | 133 | ### cache 134 | 135 | > Gitlab Runner v0.7.0 开始引入。 136 | 137 | `cache`用来指定需要在job之间缓存的文件或目录。只能使用该项目工作空间内的路径。 138 | 139 | **从GitLab 9.0开始，pipelines和job就默认开启了缓存** 140 | 141 | 如果`cache`定义在jobs的作用域之外，那么它就是全局缓存，所有jobs都可以使用该缓存。 142 | 143 | 缓存`binaries`和`.config`中的所有文件： 144 | 145 | ```yaml 146 | rspec: 147 | script: test 148 | cache: 149 | paths: 150 | - binaries/ 151 | - .config 152 | ``` 153 | 154 | 缓存git中没有被跟踪的文件： 155 | 156 | ```yaml 157 | rspec: 158 | script: test 159 | cache: 160 | untracked: true 161 | ``` 162 | 163 | 缓存`binaries`下没有被git跟踪的文件： 164 | 165 | ```yaml 166 | rspec: 167 | script: test 168 | cache: 169 | untracked: true 170 | paths: 171 | - binaries/ 172 | ``` 173 | 174 | job中优先级高于全局的。下面这个`rspec`job中将只会缓存`binaries/`下的文件： 175 | 176 | ```yaml 177 | cache: 178 | paths: 179 | - my/files 180 | 181 | rspec: 182 | script: test 183 | cache: 184 | key: rspec 185 | paths: 186 | - binaries/ 187 | ``` 188 | 189 | 注意，缓存是在jobs之前进行共享的。如果你不同的jobs缓存不同的文件路径，必须设置不同的**cache:key**，否则缓存内容将被重写。 190 | 191 | 缓存只是尽力而为之，所以别期望缓存会一直存在。查看更多详细内容，请查阅GitLab Runner。 192 | 193 | #### 缓存key 194 | 195 | > GitLab Runner v1.0.0 开始引入。 196 | 197 | `key`指令允许我们定义缓存的作用域(亲和性)，可以是所有jobs的单个缓存，也可以是每个job，也可以是每个分支或者是任何你认为合适的地方。 198 | 199 | 它也可以让你很好的调整缓存，允许你设置不同jobs的缓存，甚至是不同分支的缓存。 200 | 201 | `cache:key`可以使用任何的[预定义变量](https://docs.gitlab.com/ce/ci/variables/README.html)。 202 | 203 | 默认key是默认设置的这个项目缓存，因此默认情况下，每个pipelines和jobs中可以共享一切，从GitLab 9.0开始。 204 | 205 | **配置示例** 206 | 207 | 缓存每个job： 208 | 209 | ```yaml 210 | cache: 211 | key: "$CI_JOB_NAME" 212 | untracked: true 213 | ``` 214 | 215 | 缓存每个分支： 216 | 217 | ```yaml 218 | cache: 219 | key: "$CI_COMMIT_REF_NAME" 220 | untracked: true 221 | ``` 222 | 223 | 缓存每个job且每个分支： 224 | 225 | ```yaml 226 | cache: 227 | key: "$CI_JOB_NAME/$CI_COMMIT_REF_NAME" 228 | untracked: true 229 | ``` 230 | 231 | 缓存每个分支且每个stage： 232 | 233 | ```yaml 234 | cache: 235 | key: "$CI_JOB_STAGE/$CI_COMMIT_REF_NAME" 236 | untracked: true 237 | ``` 238 | 239 | 如果使用的[Windows Batch](http://blog.csdn.net/hitlion2008/article/details/7467252)(windows批处理)来跑脚本需要用`%`替代`$`： 240 | 241 | ```yaml 242 | cache: 243 | key: "%CI_JOB_STAGE%/%CI_COMMIT_REF_NAME%" 244 | untracked: true 245 | ``` 246 | 247 | ### Jobs 248 | 249 | `.gitlab-ci.yml`允许指定无限量jobs。每个jobs必须有一个唯一的名字，而且不能是上面提到的关键字。job由一列参数来定义jobs的行为。 250 | 251 | ```yaml 252 | job_name: 253 | script: 254 | - rake spec 255 | - coverage 256 | stage: test 257 | only: 258 | - master 259 | except: 260 | - develop 261 | tags: 262 | - ruby 263 | - postgres 264 | allow_failure: true 265 | ``` 266 | 267 | | Keyword | Required | Description | 268 | | ------------- | -------- | ---------------------------------------- | 269 | | script | yes | Runner执行的命令或脚本 | 270 | | image | no | 所使用的docker镜像，查阅[使用docker镜像](https://docs.gitlab.com/ce/ci/docker/using_docker_images.html#define-image-and-services-from-gitlab-ciyml) | 271 | | services | no | 所使用的docker服务，查阅[使用docker镜像](https://docs.gitlab.com/ce/ci/docker/using_docker_images.html#define-image-and-services-from-gitlab-ciyml) | 272 | | stage | no | 定义job stage（默认：`test`） | 273 | | type | no | `stage`的别名（已弃用） | 274 | | variables | no | 定义job级别的变量 | 275 | | only | no | 定义一列git分支，并为其创建job | 276 | | except | no | 定义一列git分支，不创建job | 277 | | tags | no | 定义一列tags，用来指定选择哪个Runner（同时Runner也要设置tags） | 278 | | allow_failure | no | 允许job失败。失败的job不影响commit状态 | 279 | | when | no | 定义何时开始job。可以是`on_success`，`on_failure`，`always`或者`manual` | 280 | | dependencies | no | 定义job依赖关系，这样他们就可以互相传递artifacts | 281 | | cache | no | 定义应在后续运行之间缓存的文件列表 | 282 | | before_script | no | 重写一组在作业前执行的命令 | 283 | | after_script | no | 重写一组在作业后执行的命令 | 284 | | environment | no | 定义此作业完成部署的环境名称 | 285 | | coverage | no | 定义给定作业的代码覆盖率设置 | 286 | 287 | #### script 288 | 289 | `script`是Runner执行的yaml脚本。举个例子： 290 | 291 | ```yaml 292 | job: 293 | script: "bundle exec rspec" 294 | ``` 295 | 296 | 该参数也可以用数组包含多个命令： 297 | 298 | ```yaml 299 | job: 300 | script: 301 | - uname -a 302 | - bundle exec rspec 303 | ``` 304 | 305 | 有时候，`script`命令需要被单引号或者是双引号包裹起来。举个例子，当命令中包含冒号(`:`)时，script需要被包在双引号中，这样YAML解析器才可以正确解析为一个字符串而不是一个键值对(key:value)。使用这些特殊字符的时候一定要注意：`:`,`{`,`}`,`[`,`]`,`,`,`&`,`*`,`#`,`?`,`|`,`-`,`<`,`>`,`=`,`!`。 306 | 307 | #### stage 308 | 309 | `stage`允许一组jobs进入不同的stages。jobs在相同的`stage`时会`parallel`同时进行。查阅`stages`更多的用法请查看[stages](https://docs.gitlab.com/ce/ci/yaml/README.html#stages)。 310 | 311 | #### only and except 312 | 313 | `only`和except是两个参数用分支策略来限制jobs构建： 314 | 315 | 1. `only`定义哪些分支和标签的git项目将会被job执行。 316 | 2. `except`定义哪些分支和标签的git项目将不会被job执行。 317 | 318 | 下面是refs策略的使用规则： 319 | 320 | - `only`和`except`可同时使用。如果`only`和`except`在一个job配置中同时存在，则以`only`为准，跳过`except`(从下面示例中得出)。 321 | - `only`和`except`可以使用正则表达式。 322 | - `only`和`except`允许使用特殊的关键字：`branches`，`tags`和`triggers`。 323 | - `only`和`except`允许使用指定仓库地址但不是forks的仓库(查看示例3)。 324 | 325 | 在下面这个例子中，`job`将只会运行以`issue-`开始的refs(分支)，然而except中设置将被跳过。 326 | 327 | ```yaml 328 | job: 329 | # use regexp 330 | only: 331 | - /^issue-.*$/ 332 | # use special keyword 333 | except: 334 | - branches 335 | ``` 336 | 337 | 在下面这个例子中，`job`将只会执行有tags的refs，或者通过API触发器明确地请求构建。 338 | 339 | ```yaml 340 | job: 341 | # use special keywords 342 | only: 343 | - tags 344 | - triggers 345 | ``` 346 | 347 | 仓库路径只能用于父级仓库执行jobs，而不是forks： 348 | 349 | ```yaml 350 | job: 351 | only: 352 | - branches@gitlab-org/gitlab-ce 353 | except: 354 | - master@gitlab-org/gitlab-ce 355 | ``` 356 | 357 | 上面这个例子将会为所有的分支执行`job`，但master分支除外。 358 | 359 | #### Job variables 360 | 361 | 在job中是可以使用关键字`variables`来定义job变量。它的运行原理跟[global-level](https://docs.gitlab.com/ce/ci/yaml/README.html#variables)是一样的，但是它允许设置特殊的job变量。 362 | 363 | 当设置了job级别的关键字`variables`，它会覆盖全局YAML和预定义中的job变量。想要关闭全局变量可以在job中设置一个空数组： 364 | 365 | ```yaml 366 | job_name: 367 | variables: [] 368 | ``` 369 | 370 | Job变量的优先级关系可查看[variables文档](https://docs.gitlab.com/ce/ci/variables/README.html)说明。 371 | 372 | #### tags 373 | 374 | `tags`可以从允许运行此项目的所有Runners中选择特定的Runners来执行jobs。 375 | 376 | 在注册Runner的过程中，我们可以设置Runner的标签，比如`ruby`，`postgres`，`development`。 377 | 378 | `tags`可通过tags来指定特殊的Runners来运行jobs： 379 | 380 | ```yaml 381 | job: 382 | tags: 383 | - ruby 384 | - postgres 385 | ``` 386 | 387 | 上面这个示例中，需要确保构建此`job`的Runner必须定义了`ruby`和`postgres`这两个tags。 388 | 389 | ### allow_failure 390 | 391 | `allow_failure`可以用于当你想设置一个job失败的之后并不影响后续的CI组件的时候。失败的jobs不会影响到commit状态。 392 | 393 | 当开启了允许job失败，所有的intents和purposes里的pipeline都是成功/绿色，但是也会有一个"CI build passed with warnings"信息显示在merge request或commit或job page。这被允许失败的作业使用，但是如果失败表示其他地方应采取其他（手动）步骤。 394 | 395 | 下面的这个例子中，`job1`和`job2`将会并列进行，如果`job1`失败了，它也不会影响进行中的下一个stage，因为这里有设置了`allow_failure: true`。 396 | 397 | ```yaml 398 | job1: 399 | stage: test 400 | script: 401 | - execute_script_that_will_fail 402 | allow_failure: true 403 | 404 | job2: 405 | stage: test 406 | script: 407 | - execute_script_that_will_succeed 408 | 409 | job3: 410 | stage: deploy 411 | script: 412 | - deploy_to_staging 413 | ``` 414 | 415 | #### when 416 | 417 | `when` is used to implement jobs that are run in case of failure or despite the failure. 418 | 419 | `when`可以设置以下值： 420 | 421 | 1. `on_success` - 只有前面stages的所有工作成功时才执行。 这是默认值。 422 | 2. `on_failure` - 当前面stages中任意一个jobs失败后执行。 423 | 3. `always` - 无论前面stages中jobs状态如何都执行。 424 | 4. ``manual` ` - 手动执行(GitLab8.10增加)。更多请查看[手动操作](https://docs.gitlab.com/ce/ci/yaml/README.html#manual-actions)。 425 | 426 | 举个例子： 427 | 428 | ```yaml 429 | stages: 430 | - build 431 | - cleanup_build 432 | - test 433 | - deploy 434 | - cleanup 435 | 436 | build_job: 437 | stage: build 438 | script: 439 | - make build 440 | 441 | cleanup_build_job: 442 | stage: cleanup_build 443 | script: 444 | - cleanup build when failed 445 | when: on_failure 446 | 447 | test_job: 448 | stage: test 449 | script: 450 | - make test 451 | 452 | deploy_job: 453 | stage: deploy 454 | script: 455 | - make deploy 456 | when: manual 457 | 458 | cleanup_job: 459 | stage: cleanup 460 | script: 461 | - cleanup after jobs 462 | when: always 463 | ``` 464 | 465 | 脚本说明： 466 | 467 | 1. 只有当`build_job`失败的时候才会执行``cleanup_build_job` 。 468 | 2. 不管前一个job执行失败还是成功都会执行``cleanup_job` 。 469 | 3. 可以从GitLab界面中手动执行`deploy_jobs`。 470 | 471 | #### Manual actions 472 | 473 | > GitLab 8.10 开始引入手动执行。GitLab 9.0 开始引入手动停止。GitLab 9.2 开始引入保护手动操作。 474 | 475 | 手动操作指令是不自动执行的特殊类型的job；它们必须要人为启动。手动操作指令可以从pipeline，build，environment和deployment视图中启动。 476 | 477 | 部署到生产环境是手动操作指令的一个很好示例。 478 | 479 | 了解更多请查看[environments documentation](https://docs.gitlab.com/ce/ci/environments.html#manually-deploying-to-environments)。 480 | 481 | 手动操作指令可以是可选的或阻塞。在定义了手动执行的那个stage中，手动操作指令将会停止pipline中的自动执行指令。当有人通过点击play按钮来执行需要手动执行的job时，可以来恢复pipeline的执行。 482 | 483 | 当pipeline被阻塞时，即使是pipeline是成功状态也不会merge。被阻塞的pipelines也有一个特殊的状态，叫`manual`。 484 | 485 | 手动操作指令默认是不阻塞的。如果你想要手动操作指令产生阻塞，首先需要在job的配置文件`.gitlab-ci.yml`中添加`allow_failure:false`。 486 | 487 | 可选的手动操作指令默认设置`allow_failure:true`。 488 | 489 | 可选动作的状态不影响整个pipeline的状态。 490 | 491 | 手动操作指令被认为是写操作，所以当前用户触发操作时，必须拥有操作保护分支的权限。换句话说，为了触发一个手动操作指令到pipeline中正在运行的指定分支，当前用户必须拥有推送到这分支的权限。 492 | 493 | ### enviroment 494 | 495 | > 注意： 496 | > 497 | > - GitLab 8.9 开始引入。 498 | > - 更多关于environment说明或者示例可以查看 [documentation about environments](https://docs.gitlab.com/ce/ci/environments.html)。 499 | 500 | `environment`用于定义job部署到特殊的环境中。如果指定了`environment`，并且没有该名称下的环境，则会自动创建新环境。 501 | 502 | 在最简单的格式中，环境关键字可以定义为： 503 | 504 | ```yaml 505 | deploy to production: 506 | stage: deploy 507 | script: git push production HEAD:master 508 | environment: 509 | name: production 510 | ``` 511 | 512 | 在上面这个例子中，`deploy to profuction`job将会执行部署到`production`环境的操作。 513 | 514 | #### environment:name 515 | 516 | > 注意 517 | > 518 | > - GitLab 8.11 开始引入。 519 | > - 在GitLab8.11之前，环境名称定义为`environment:production`。现在推荐的做法是定义为`name`关键字。 520 | 521 | `environment`名称可以包含： 522 | 523 | - 英文字母(`letters`) 524 | - 数字(`digits`) 525 | - 空格(`spaces`) 526 | - `-` 527 | - `_` 528 | - `/` 529 | - `$` 530 | - `{` 531 | - `}` 532 | 533 | 常用的名称有`qa`,`staging`，和`production`，当然你可以在你的工作流中使用任意名字。 534 | 535 | 除了在`environment`关键字右边紧跟name定义方法外，也是可以为环境名称单独设定一个值。例如，用`name`关键字在`environment`下面设置： 536 | 537 | ```yaml 538 | deploy to production: 539 | stage: deploy 540 | script: git push production HEAD:master 541 | environment: 542 | name: production 543 | ``` 544 | 545 | #### environment:url 546 | 547 | > 注意： 548 | > 549 | > - GitLab 8.11 开始引用。 550 | > - 在GitLab 8.11之前，URL只能在GitLab's UI中添加。现在推荐的定义方法是在`.gitlab-ci.yml`。 551 | 552 | 这是设置一个可选值，它会显示在按钮中，点击它可以带你到设置的URL页面。 553 | 554 | 在下面这个例子中，如果job都成功完成了，在environment/deployments页面中将会创建一个合并请求的按钮，它将指向`https://prod.example.com`。 555 | 556 | ```yaml 557 | deploy to production: 558 | stage: deploy 559 | script: git push production HEAD:master 560 | environment: 561 | name: production 562 | url: https://prod.example.com 563 | ``` 564 | 565 | #### environment:on_stop 566 | 567 | > 注意： 568 | > 569 | > - GitLab 8.13中开始[引入](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6669)。 570 | > - 从GitLab 8.14开始，当在environment中定义了一个stop操作，GitLab将会在相关联的分支本删除时自动触发一个stop操作。 571 | 572 | 关闭(停止)environments可以通过在`environment`下定义关键字`on_stop`来实现。它定义了一个不同的job，用于关闭environment。 573 | 574 | 请查看`environment:action`模块中例子。 575 | 576 | #### environment:action 577 | 578 | > Gitlab 8.13 开始[引入](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6669)。 579 | 580 | `action`和`on_stop`联合使用，定义在job中，用来关闭environment。 581 | 582 | 举个例子： 583 | 584 | ```yaml 585 | review_app: 586 | stage: deploy 587 | script: make deploy-app 588 | environment: 589 | name: review 590 | on_stop: stop_review_app 591 | 592 | stop_review_app: 593 | stage: deploy 594 | script: make delete-app 595 | when: manual 596 | environment: 597 | name: review 598 | action: stop 599 | ``` 600 | 601 | 上面这个例子中，我们定义了`review_app`job来部署到`review`环境中，同时我们也定义了一个新`stop_review_app`job在`on_stop`中。一旦`review_app`job执行完成并且成功，它将触发定义在`when`中的`stop_review_app`job。在这种情况下，我们设置为`manual`，需要通过GitLab's web界面来允许[manual action](https://docs.gitlab.com/ce/ci/yaml/README.html#manual-actions)。 602 | 603 | `stop_review_app`job需要定义下面这些关键字： 604 | 605 | - `when` - [说明](https://docs.gitlab.com/ce/ci/yaml/README.html#when) 606 | - `environment:name` 607 | - `environment:action` 608 | - `stage`需要和`review_app`相同，以便分支删除被删除的时候自动执行停止。 609 | 610 | 611 | #### dynamic environment 612 | 613 | > 注意： 614 | > 615 | > - GitLab 8.12开始引入，并且要求GitLab Runner 1.6 。 616 | > - GitLab 8.15开始引入`$CI_ENVIRONMENT_SLUG`。 617 | 618 | `environment`也可以是代表配置项，其中包含`name`和`url`。这些参数可以使用任何的[CI variables](https://docs.gitlab.com/ce/ci/yaml/README.html#variables)(包括预定义、安全变量和`.gitlab-ci.yml`中的变量)。 619 | 620 | 举个例子： 621 | 622 | ```yaml 623 | deploy as review app: 624 | stage: deploy 625 | script: make deploy 626 | environment: 627 | name: review/$CI_COMMIT_REF_NAME 628 | url: https://$CI_ENVIRONMENT_SLUG.example.com/ 629 | ``` 630 | 631 | 当`$CI_COMMIT_REF_NAME` 被Runner设置为[environment variable](https://docs.gitlab.com/ce/ci/variables/README.html)时，`deply as review app`job将会被指定部署到动态创建`revuew/$CI_COMMIT_REF_NAME`的环境中。`$CI_ENVIRONMENT_SLUG`变量是基于环境名称的，最终组合成完整的URLs。在这种情况下，如果`deploy as review app`job是运行在名称为`pow`的分支下，那么可以通过URL`https"//review-pw.example.com/`来访问这个环境。 632 | 633 | 这当然意味着托管应用程序的底层服务器已经正确配置。 634 | 635 | 常见的做法是为分支创建动态环境，并讲它们作为Review Apps。可以通过https://gitlab.com/gitlab-examples/review-apps-nginx/上查看使用Review Apps的简单示例。 636 | 637 | ### artifacts 638 | 639 | > 注意： 640 | > 641 | > - 非Windows平台从GitLab Runner v0.7.0中引入。 642 | > - Windows平台从GitLab Runner V1.0.0中引入。 643 | > - 在GItLab 9.2之前，在artifacts之后存储缓存。 644 | > - 在GItLab 9.2之后，在artifacts之前存储缓存。 645 | > - 目前并不是所有的executors都支持。 646 | > - 默认情况下，job artifacts 只正对成功的jobs收集。 647 | 648 | `artifacts`用于指定成功后应附加到job的文件和目录的列表。只能使用项目工作间内的文件或目录路径。如果想要在不通的job之间传递artifacts，请查[阅依赖关系](https://docs.gitlab.com/ce/ci/yaml/README.html#dependencies)。以下是一些例子： 649 | 650 | 发送`binaries`和`.config`中的所有文件： 651 | 652 | ```yaml 653 | artifacts: 654 | paths: 655 | - binaries/ 656 | - .config 657 | ``` 658 | 659 | 发送所有没有被Git跟踪的文件： 660 | 661 | ```yaml 662 | artifacts: 663 | untracked: true 664 | ``` 665 | 666 | 发送没有被Git跟踪和`binaries`中的所有文件： 667 | 668 | ```yaml 669 | artifacts: 670 | untracked: true 671 | paths: 672 | - binaries/ 673 | ``` 674 | 675 | 定义一个空的[dependencies](https://docs.gitlab.com/ce/ci/yaml/README.html#dependencies)可以禁用artifact传递： 676 | 677 | ```yaml 678 | job: 679 | stage: build 680 | script: make build 681 | dependencies: [] 682 | ``` 683 | 684 | 有时候只需要为标签为releases创建artifacts，以避免将临时构建的artifacts传递到生产服务器中。 685 | 686 | 只为tags创建artifacts（`default-job`将不会创建artifacts）： 687 | 688 | ```yaml 689 | default-job: 690 | script: 691 | - mvn test -U 692 | except: 693 | - tags 694 | 695 | release-job: 696 | script: 697 | - mvn package -U 698 | artifacts: 699 | paths: 700 | - target/*.war 701 | only: 702 | - tags 703 | ``` 704 | 705 | 在job成功完成后artifacts将会发送到GitLab中，同时也会在GitLab UI中提供下载。 706 | 707 | #### artifacts:name 708 | 709 | > GitLab 8.6 和 Runner v1.1.0 引入。 710 | 711 | `name`允许定义创建的artifacts存档的名称。这样一来，我们可以为每个存档提供一个唯一的名称，当需要从GitLab中下载是才不会混乱。`artifacts:name`可以使用任何的[预定义变量](https://docs.gitlab.com/ce/ci/variables/README.html)([predefined variables](https://docs.gitlab.com/ce/ci/variables/README.html))。它的默认名称为`artifacts`，当下载是就变成了`artifacts.zip`。 712 | 713 | --- 714 | 715 | **配置示例** 716 | 717 | 通过使用当前job的名字作为存档名称： 718 | 719 | ```yaml 720 | job: 721 | artifacts: 722 | name: "$CI_JOB_NAME" 723 | ``` 724 | 725 | 使用当前分支名称或者是tag作为存到名称，只存档没有被Git跟踪的文件： 726 | 727 | ```yaml 728 | job: 729 | artifacts: 730 | name: "$CI_COMMIT_REF_NAME" 731 | untracked: true 732 | ``` 733 | 734 | 使用当前job名称和当前分支名称或者是tag作为存档名称，只存档没有被Git跟踪的文件： 735 | 736 | ```yaml 737 | job: 738 | artifacts: 739 | name: "${CI_JOB_NAME}_${CI_COMMIT_REF_NAME}" 740 | untracked: true 741 | ``` 742 | 743 | 使用当前[stage](https://docs.gitlab.com/ce/ci/yaml/README.html#stages)和分支名称作为存档名称： 744 | 745 | ```yaml 746 | job: 747 | artifacts: 748 | name: "${CI_JOB_STAGE}_${CI_COMMIT_REF_NAME}" 749 | untracked: true 750 | ``` 751 | 752 | 如果是使用Windows批处理来运行yaml脚本，需要用`%`替换`$`： 753 | 754 | ```yaml 755 | job: 756 | artifacts: 757 | name: "%CI_JOB_STAGE%_%CI_COMMIT_REF_NAME%" 758 | untracked: true 759 | ``` 760 | 761 | 762 | 763 | #### artifacts:when 764 | 765 | > GitLab 8.9和GitLab Runner v1.3.0 引入。 766 | 767 | 在job失败的时候，`artifacts:when`用来上传artifacts或者忽略失败。 768 | 769 | `artifacts:when`可以设置一下值： 770 | 771 | 1. `on_success` - 当job成功的时候上传artifacts。默认值。 772 | 2. `on_failure` - 当job失败的时候上传artifacts。 773 | 3. `always` - 不论job失败还是成功都上传artifacts。 774 | 775 | --- 776 | 777 | **示例配置** 778 | 779 | 只在job失败的时候上传artifacts。 780 | 781 | ```yaml 782 | job: 783 | artifacts: 784 | when: on_failure 785 | ``` 786 | 787 | #### artifacts:expire_in 788 | 789 | > GitLab 8.9 和 GitLab Runner v1.3.0 引入。 790 | 791 | `artifacts:expire_in`用于过期后删除邮件上传的artifacts。默认情况下，artifacts都是在GitLab中永久保存。`expire_in`允许设置设置artifacts的存储时间，从它们被上传存储到GitLab开始计算。 792 | 793 | 可以通过job页面的**Keep**来修改有效期。 794 | 795 | 过期后，artifacts会被通过一个默认每小时执行一次的定时job删除，所以在过期后无法访问artifacts。 796 | 797 | `expire_in`是一个时间区间。下面可设置的值： 798 | 799 | - '3 mins 4 sec' 800 | - '2 hrs 20 min' 801 | - '2h20min' 802 | - '6 mos 1 day' 803 | - '47 yrs 6 mos and 4d' 804 | - '3 weeks and 2 days' 805 | 806 | --- 807 | 808 | **示例配置** 809 | 810 | 设置artifacts的有效期为一个星期： 811 | 812 | ```yaml 813 | job: 814 | artifacts: 815 | expire_in: 1 week 816 | ``` 817 | 818 | ### dependencies 819 | 820 | > GitLab 8.6 和 GitLab RUnner v1.1.1引入。 821 | 822 | 这个功能应该与`artifacts`一起使用，并允许定义在不同jobs之间传递artifacts。 823 | 824 | 注意：所有之前的stages都是默认设置通过。 825 | 826 | 如果要使用此功能，应该在上下文的job中定义`dependencies`，并且列出之前都已经通过的jobs和可下载的artifacts。你只能在当前执行的stages前定义jobs。你如果在当前stages或者后续的stages中定义了jobs，它将会报错。可以通过定义一个空数组是当前job跳过下载artifacts。 827 | 828 | --- 829 | 830 | 在接下来的例子中，我们定义两个带artifacts的jobs，`build:osx`和`build:linux`。当`test:osx`开始执行的时候，`build:osx`的artifacts就会开始下载并且会在build的stages下执行。同样的会发生在`test:linux`，从`build:linux`中下载artifacts。 831 | 832 | 因为stages的优先级关系，`deploy`job将会下载之前jobs的所有artifacts： 833 | 834 | ```yaml 835 | build:osx: 836 | stage: build 837 | script: make build:osx 838 | artifacts: 839 | paths: 840 | - binaries/ 841 | 842 | build:linux: 843 | stage: build 844 | script: make build:linux 845 | artifacts: 846 | paths: 847 | - binaries/ 848 | 849 | test:osx: 850 | stage: test 851 | script: make test:osx 852 | dependencies: 853 | - build:osx 854 | 855 | test:linux: 856 | stage: test 857 | script: make test:linux 858 | dependencies: 859 | - build:linux 860 | 861 | deploy: 862 | stage: deploy 863 | script: make deploy 864 | ``` 865 | 866 | ### before_script 和 after_script 867 | 868 | 它可能会覆盖全局定义的`before_script`和`after_script`： 869 | 870 | ```yaml 871 | before_script: 872 | - global before script 873 | 874 | job: 875 | before_script: 876 | - execute this instead of global before script 877 | script: 878 | - my command 879 | after_script: 880 | - execute this after my script 881 | ``` 882 | 883 | ### coverage 884 | 885 | > 注意： 886 | > 887 | > GitLab 8.17 [引入](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7447)。 888 | 889 | `coverage`允许你配置代码覆盖率将会从该job中提取输出。 890 | 891 | 在这里正则表达式是唯一有效的值。因此，字符串的前后必须使用`/`包含来表明一个正确的正则表达式规则。特殊字符串需要转义。 892 | 893 | 一个简单的例子： 894 | 895 | ```yaml 896 | job1: 897 | coverage: '/Code coverage: \d+\.\d+/' 898 | ``` 899 | 900 | ## Git Strategy 901 | 902 | > GitLab 8.9中以试验性功能引入。将来的版本中可能改变或完全移除。`GIT_STRATEGY`要求GitLab Runner v1.7+。 903 | 904 | 你可以通过设置`GIT_STRATEGY`用于获取最新的代码，可以再全局`variables`或者是在单个job的`variables`模块中设置。如果没有设置，将从项目中使用默认值。 905 | 906 | 可以设置的值有：`clone`，`fetch`，和`none`。 907 | 908 | `clone`是最慢的选项。它会从头开始克隆整个仓库，包含每一个job，以确保项目工作区是最原始的。 909 | 910 | ```yaml 911 | variables: 912 | GIT_STRATEGY: clone 913 | ``` 914 | 915 | 当它重新使用项目工作区是，`fetch`是更快（如果不存在则返回克隆）。`git clean`用于撤销上一个job做的任何改变，`git fetch`用于获取上一个job到现在的的commit。 916 | 917 | ```yaml 918 | variables: 919 | GIT_STRATEGY: fetch 920 | ``` 921 | 922 | `none`也是重新使用项目工作区，但是它会跳过所有的Git操作（包括GitLab Runner前的克隆脚本，如果存在的话）。它主要用在操作job的artifacts（例如：`deploy`）。Git数据仓库肯定是存在的，但是他肯定不是最新的，所以你只能依赖于从项目工作区的缓存或者是artifacts带来的文件。 923 | 924 | ```yaml 925 | variables: 926 | GIT_STRATEGY: none 927 | ``` 928 | 929 | ## Git Checout 930 | 931 | > GitLab Runner 9.3 引入。 932 | 933 | 当`GIT_STRATEGY`设置为`clone`或`fetch`时，可以使用`GIT_CHECKOUT`变量来指定是否应该运行`git checkout`。如果没有指定，它默认为true。就像`GIT_STRATEGY`一样，它可以设置在全局`variables`或者是单个job的`variables`中设置。 934 | 935 | 如果设置为`false`，Runner就会： 936 | 937 | - `fetch` - 更新仓库并在当前版本中保留工作副本， 938 | - `clone` - 克隆仓库并在默认分支中保留工作副本。 939 | 940 | Having this setting set to `true` will mean that for both `clone` and `fetch` strategies the Runner will checkout the working copy to a revision related to the CI pipeline: 941 | 942 | 【如果设置这个为`true`将意味着`clone`和`fetch`策略都会让Runner执行项目工作区更新到最新：】 943 | 944 | ```yaml 945 | variables: 946 | GIT_STRATEGY: clone 947 | GIT_CHECKOUT: false 948 | script: 949 | - git checkout master 950 | - git merge $CI_BUILD_REF_NAME 951 | ``` 952 | 953 | ## Git Submodule Strategy 954 | 955 | > 需要GitLab Runner v1.10+。 956 | 957 | `GIT_SUBMODULE_STRATEGY`变量用于在构建之前拉取代码时，Git子模块是否或者如何被引入。就像`GIT_STRATEGY`一样，它可在全局`variables`或者是单个job的`variables`模块中设置。 958 | 959 | 它的可用值有：`none`，`normal`和`recursive`： 960 | 961 | - `none`意味着在拉取项目代码时，子模块将不会被引入。这个是默认值，与v1.10之前相同的。 962 | - `normal`意味着在只有顶级子模块会被引入。它相当于： 963 | 964 | ```yaml 965 | git submodule sync 966 | git submodule update --init 967 | ``` 968 | 969 | `recursive`意味着所有的子模块（包括子模块的子模块）都会被引入，他相当于： 970 | 971 | ```yaml 972 | git submodule sync --recursive 973 | git submodule update --init --recursive 974 | ``` 975 | 976 | 注意：如果想要此功能正常工作，子模块必须配置（在`.gitmodules`）下面中任意一个： 977 | 978 | - 可访问的公共仓库http(s)地址， 979 | - 在同一个GitLab服务器上有一个可访问到另外的仓库的真实地址。更多查看[Git 子模块文档](https://docs.gitlab.com/ce/ci/git_submodules.html)。 980 | 981 | ## Job stages attempts 982 | 983 | > GitLab引入，要求GItLab Runner v1.9+。 984 | 985 | 正在执行的job将会按照你设置尝试次数依次执行下面的stages： 986 | 987 | | 变量 | 描述 | 988 | | ------------------------------ | ---------------- | 989 | | **GET_SOURCES_ATTEMPTS** | 获取job源的尝试次数 | 990 | | **ARTIFACT_DOWNLOAD_ATTEMPTS** | 下载artifacts的尝试次数 | 991 | | **RESTORE_CACHE_ATTEMPTS** | 重建缓存的尝试次数 | 992 | 993 | 默认是一次尝试。 994 | 995 | 例如： 996 | 997 | ```yaml 998 | variables: 999 | GET_SOURCES_ATTEMPTS: 3 1000 | ``` 1001 | 1002 | 你可以在全局`variables`模块中设置，也可以在单个job的`variables`模块中设置。 1003 | 1004 | ## Shallow cloning 1005 | 1006 | > GitLab 8.9 以实验性功能引入。在将来的版本中有可能改变或者完全移除。 1007 | 1008 | 你可以通过`GIT_DEPTH`来指定抓取或克隆的深度。它可浅层的克隆仓库，这可以显著加速具有大量提交和旧的大型二进制文件的仓库的克隆。这个设置的值会传递给`git fetch`和`git clone`。 1009 | 1010 | > 注意：如果设置depth=1，并且有一个jobs队列或者是重试jobs，则jobs可能会失败。 1011 | 1012 | 由于Git抓取和克隆是基于一个REF，例如分支的名称，所以Runner不能指定克隆一个commit SHA。如果队列中有多个jobs，或者您正在重试旧的job，则需要测试的提交应该在克隆的Git历史记录中存在。设置`GIT_DEPTH`太小的值可能会导致无法运行哪些旧的commits。在job日志中可以查看`unresolved reference`。你应该考虑设置`GIT_DEPTH`为一个更大的值。 1013 | 1014 | 当`GIT_DEPTH`只设置了部分存在的记录时，哪些依赖于`git describe`的jobs也许不能正确的工作。 1015 | 1016 | 只抓取或克隆最后的3次commits： 1017 | 1018 | ```yaml 1019 | variables: 1020 | GIT_DEPTH: "3" 1021 | ``` 1022 | 1023 | ## Hidden keys 1024 | 1025 | > GitLab 8.6 和 GitLab Runner v1.1.1引入。 1026 | 1027 | Key 是以`.`开始的，GitLab CI 将不会处理它。你可以使用这个功能来忽略jobs，或者用[Special YAML features ](https://docs.gitlab.com/ce/ci/yaml/README.html#special-yaml-features)转换隐藏键为模版。 1028 | 1029 | 在下面这个例子中，`.key_name`将会被忽略： 1030 | 1031 | ```yaml 1032 | .key_name: 1033 | script: 1034 | - rake spec 1035 | ``` 1036 | 1037 | Hidden keys 可以是像普通CI jobs一样的哈希值，但你也可以利用special YAMLfeatures来使用不同类型的结构。 1038 | 1039 | ## Special YAML features 1040 | 1041 | 使用special YAML features 像anchors(`&`)，aliases(`*`)和map merging(`<<`)，这将使您可以大大降低`.gitlab-ci.yml`的复杂性。 1042 | 1043 | 查看更多[YAML features](https://learnxinyminutes.com/docs/yaml/)。 1044 | 1045 | ### Anchors 1046 | 1047 | > GitLab 8.6 和 GitLab Runner v1.1.1引入。 1048 | 1049 | YAML有个方便的功能称为"锚",它可以让你轻松的在文档中复制内容。Anchors可用于复制/继承属性，并且是使用[hidden keys](https://docs.gitlab.com/ce/ci/yaml/README.html#hidden-keys)来提供模版的完美示例。 1050 | 1051 | 下面这个例子使用了anchors和map merging。它将会创建两个jobs，`test1`和`test2`，该jobs将集成`.job_template`的参数，每个job都自定义脚本： 1052 | 1053 | ```yaml 1054 | .job_template: &job_definition # Hidden key that defines an anchor named 'job_definition' 1055 | image: ruby:2.1 1056 | services: 1057 | - postgres 1058 | - redis 1059 | 1060 | test1: 1061 | <<: *job_definition # Merge the contents of the 'job_definition' alias 1062 | script: 1063 | - test1 project 1064 | 1065 | test2: 1066 | <<: *job_definition # Merge the contents of the 'job_definition' alias 1067 | script: 1068 | - test2 project 1069 | ``` 1070 | 1071 | `&`在anchor的名称(`job_definition`)前设置，`<<`表示"merge the given hash into the current one"，`*`包括命名的anchor(`job_definition`)。扩展版本如下： 1072 | 1073 | ```yaml 1074 | .job_template: 1075 | image: ruby:2.1 1076 | services: 1077 | - postgres 1078 | - redis 1079 | 1080 | test1: 1081 | image: ruby:2.1 1082 | services: 1083 | - postgres 1084 | - redis 1085 | script: 1086 | - test1 project 1087 | 1088 | test2: 1089 | image: ruby:2.1 1090 | services: 1091 | - postgres 1092 | - redis 1093 | script: 1094 | - test2 project 1095 | ``` 1096 | 1097 | 让我们来看另外一个例子。这一次我们将用anchors来定义两个服务。两个服务会创建两个job，`test:postgres`和`test:mysql`，他们会在`.job_template`中共享定义的`script`指令，以及分别在`.postgres_services`和`.mysql_services`中定义的`service`指令： 1098 | 1099 | ```yaml 1100 | .job_template: &job_definition 1101 | script: 1102 | - test project 1103 | 1104 | .postgres_services: 1105 | services: &postgres_definition 1106 | - postgres 1107 | - ruby 1108 | 1109 | .mysql_services: 1110 | services: &mysql_definition 1111 | - mysql 1112 | - ruby 1113 | 1114 | test:postgres: 1115 | <<: *job_definition 1116 | services: *postgres_definition 1117 | 1118 | test:mysql: 1119 | <<: *job_definition 1120 | services: *mysql_definition 1121 | ``` 1122 | 1123 | 扩展版本如下： 1124 | 1125 | ```yaml 1126 | .job_template: 1127 | script: 1128 | - test project 1129 | 1130 | .postgres_services: 1131 | services: 1132 | - postgres 1133 | - ruby 1134 | 1135 | .mysql_services: 1136 | services: 1137 | - mysql 1138 | - ruby 1139 | 1140 | test:postgres: 1141 | script: 1142 | - test project 1143 | services: 1144 | - postgres 1145 | - ruby 1146 | 1147 | test:mysql: 1148 | script: 1149 | - test project 1150 | services: 1151 | - mysql 1152 | - ruby 1153 | ``` 1154 | 1155 | 你可以看到hidden keys被方便的用作模版。 1156 | 1157 | ## Triggers 1158 | 1159 | Triggers 可用于强制使用API调用重建特定分支，tag或commits。 1160 | 1161 | [在triggers文档中查看更多。](https://docs.gitlab.com/ce/ci/triggers/README.html) 1162 | 1163 | ## pages 1164 | 1165 | pages是一个特殊的job，用于将静态的内容上传到GitLab，可用于为您的网站提供服务。它有特殊的语法，因此必须满足以下两个要求： 1166 | 1167 | 1. 任何静态内容必须放在`public/`目录下 1168 | 2. `artifacts`必须定义在`public/`目录下 1169 | 1170 | 下面的这个例子是将所有文件从项目根目录移动到`public/`目录。`.public`工作流是`cp`，并且它不会循环复制`public/`本身。 1171 | 1172 | ```yaml 1173 | pages: 1174 | stage: deploy 1175 | script: 1176 | - mkdir .public 1177 | - cp -r * .public 1178 | - mv .public public 1179 | artifacts: 1180 | paths: 1181 | - public 1182 | only: 1183 | - master 1184 | ``` 1185 | 1186 | 更多内容请查看[GitLab Pages用户文档](https://docs.gitlab.com/ce/user/project/pages/index.html)。 1187 | 1188 | ## Validate the .gitlab-ci.yml 1189 | 1190 | GitLab CI的每个实例都有一个名为Lint的嵌入式调试工具。 你可以在gitlab实例的`/ci/lint`下找到该链接。 1191 | 1192 | ## Skipping jobs 1193 | 1194 | 如果你的commit信息中包含`[ci skip]`或者`[skip ci]`，不论大小写，那么这个commit将会创建但是jobs也会跳过。 1195 | 1196 | ## Examples 1197 | 1198 | 访问[examples README](https://docs.gitlab.com/ce/ci/examples/README.html)来查看各种语言的GitLab CI用法示例。 1199 | 1200 | 1201 | 1202 | 官方文档地址：https://docs.gitlab.com/ce/ci/yaml/README.html 1203 | -------------------------------------------------------------------------------- /docs/pipelines.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | pipelines 307 | 308 | 309 |

管道和作业介绍

官方文档：https://docs.gitlab.com/ee/ci/pipelines.html

在GitLab 8.8中引入的。

注意：如果你的项目是从GitLab中拉取的镜像仓库，需要在项目中开启触动开关

Settings > Repository > Pull from a remote repository > Trigger pipelines for mirror updates.

管道

管道是一组分阶段（批处理）执行的工作。同一个阶段中的所有工作都是并行执行的（如果有足够的并发Runners），如果它们全部成功，管道就进入下一个阶段。如果其中一个jobs失败，则下一个阶段不（通常）执行。您可以访问项目的Pipeline选项卡中的管道页面。

在下图中，您可以看到管道由4个阶段组成（build(构建), test(测试), staging(分级), production(生产)），每个阶段都有一个或多个工作。

注意：在GitLab pipeline图上显示时，应当大写显示stats的名称。

管道类型

管道分三种，但是通常都使用单一的“管道”来代替所有。人们经常谈论他们，就好像每个都是“管道”一样，但实际上，他们只是综合管道的一部分。

  1. CI Pipeline： 在gitlab-ci.yml中定义的构建和测试阶段。

  2. Deploy Pipeline： 在.gitlab-ci.yml中定义的部署阶段，用来通过各种各样的方式将代码部署到服务器：

    例如，将代码发布到生成环境

  3. Project Pipeline：通过API触发跨项目CI依赖关系，尤其是针对微服务，但也适用于复杂的构建依赖关系：

    例如，api-> front-end，ce / ee-> omnibus。

开发工作流程

管道适应多种开发工作流程：

  1. Branch Flow（例如，dev，qa，分期，生产等不同分支）
  2. Trunk-based Flow （例如，功能分支、单一的主分支和可能带有标签的发布）
  3. 基于分叉的流程（例如，来自fork的合并请求）

连续交付流程示例：

工作

工作可以在.gitlab-ci.yml文件中定义。不要与build工作或build 阶段混淆。

定义管道

在.gitlab-ci.yml中通过指定阶段运行的作业来定义管道。

有关作业，请参阅参考文档。

查看管道状态

您可以在项目的 Pipeline选项卡下找到当前和历史运行的管道 。点击管道将显示为该管道运行的作业。

查看工作状态

当您访问单个管道时，您可以看到该管道的相关作业。点击单个作业会显示该作业运行历史，并允许您取消作业，重试作业或清除作业运行日志。

管道示例

查看工作失败的原因

在GitLab 10.7中引入。

当管道发生故障或允许失败时，有几个地方可以快速检查失败的原因：

无论任何方式中，你将鼠标悬停在失败的作业上，你可以看到失败的原因。

管道细节

从GitLab 10.8中，您还可以在工作详情页面上看到失败的原因。

管道图

在GitLab 8.11中引入。

管道可以是复杂的结构，具有许多顺序和平行的作业。为了让您更容易看到发生了什么，它可以查看单个管道及其状态。

管道图可以通过两种不同的方式显示，具体取决于您所处的页面。

当您在单个管道页面上时，可以找到显示每个阶段作业名称的常规管道图。

管道示例

其次，有管道迷你图，占用更少的空间，并且可以快速浏览所有作业是成果还是失败。管道迷你图可以在您访问以下页面时找到：

通过这种方式，您可以看到所有相关的作业以及每个阶段的最终结果。这使您可以快速查看失败的工作并修复它。管道迷你图的阶段是可折叠的。将鼠标悬停在它们上面，然后单击以展开其他作业。

迷你图迷你图展开
管道迷你图管道迷你图扩展

将相似的工作分组

在GitLab 8.12中引入。

如果你有许多类似的工作，你的管道图会变得很长，很难阅读。出于这个原因，类似的工作可以自动组合在一起。如果作业名称以某种格式命名，则它们将在常规管线图（非迷你图）中折叠为一个组。如果您没有看到重试或取消按钮，您就知道管道将作业已经合并分组了。将鼠标悬停在上面会显示分组作业的数量。可以点击展开它们。

分组管道

基本要求是需使用以下方式的一种将两个数字分隔开（可以互换使用）（查看下面的示例）：

注意： 更准确地说，它使用这个正则表达式：\d+[\s:\/\\]+\d+\s*。

这些工作将通过从左到右比较这两个数字来进行排序。通常第一个是索引，第二个是总数。

例如，以下作业将被分组在一个名为的作业下test：

以下作业将被分组在下列作业中test ruby：

下列作业也将被归类在一个作业中test ruby：

手动操作

在GitLab 8.15中引入。

手动操作允许您在使用CI中的指定作业之前需要手动操作。整个管道可以自动运行，但实际部署到生产需要点击。

您可以直接从管道图中做到这一点。只需点击播放按钮即可执行指定作业。例如，在下面的图片中，production 舞台上有一项手动操作。

管道示例

作业排序

常规管道图

在单个管道页面中，作业按名称排序。

迷你管道图

在GitLab 9.0中引入。

在管道迷你图中，作业首先按重要性排序，然后按名称排序。重要性的顺序是：

管道迷你图排序

多项目管道图

可在GitLab Premium 、GitLab Sliver或更高级版本中使用。

多项目管道，您可以访问跨项目管道。

如何计算管道持续时间

管道的总运行时间将排除重试和待处理（排队）时间。我们可以将这个问题缩减为寻找周期的联合。

所以每个工作都会被表示为 Period，其中包括 Period#first工作开始Period#last时和工作完成时。一个简单的例子是：

这里A从1开始，到3结束。B从2开始，并到4结束。C从6开始，到7结束。视觉上它可以被看作：

A，B和C的联合将是（1,4）和（6,7），因此总运行时间应该是：

徽章

管道状态和测试范围内报告徽章可用。您可以在管道设置页面找到它们各自的链接。

受保护分行的安全

管道在受保护的分支上执行时，将执行严格的安全模型 。

只有在允许用户合并或推送 特定分支时，才允许在受保护的分支上执行以下操作 ：

标记为受保护的变量仅适用于在受保护分支上运行的作业，从而避免不受信任的用户无意中访问敏感信息，如部署凭证和令牌。

标记为受保护的Runners只能保护分支机构运行的作业，避免不受信任的代码要在保护runner和保存部署键被意外地触发或其他凭证执行。为了确保打算在受保护的跑步者上执行的工作不会使用常规runner，必须对其进行相应标记。

帮助改进此翻译

 

310 | 311 | -------------------------------------------------------------------------------- /docs/quick_start.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | quick_start.md 653 | 654 | 655 |

开始GitLab CI/CD

官方原文档：https://docs.gitlab.com/ee/ci/quick_start/README.html

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

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

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

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

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

因此，简而言之，CI所需要的步骤可以归结为：

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

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

本指南要求：

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

创建.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项目的示例。

这是大多数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。

现在到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的示例。

656 | 657 | --------------------------------------------------------------------------------