Skip to content

帮
帮助文档

GitCode / 帮助文档

通知 1627
Star 125
Fork 140
帮
帮助文档

ci

最后修改来自于BaiXuePrincess
页面历史
这是此页面的过期版本。 你可以查看 最新版本 或浏览 历史。

开始使用 CI/CD

在开始使用 CI/CD 功能之前，请先确保：

  • 一个你想使用 CI/CD 功能的项目
  • 你至少拥有项目的 Maintainer 权限

**注意：**从 8.0 版开始，GitLab 持续集成 （CI）已完全集成到 GitLab 本身，并且默认情况下在所有项目上都启用 .**注意：**请记住，只有项目维护者和管理员用户有权访问项目的设置.**注意：**要从 Jenkins 转到 GitLab 吗？ 查阅我们的参考 ，将您先前存在的管道转换为我们的格式.**注意：**您可以考虑在项目中使用几种不同的基本管道体系结构 . 您可能需要在开始之前熟悉这些内容.

GitLab 提供持续集成服务. 对于每次提交或推送以触发您的 CI 管道 ，您必须：

.gitlab-ci.yml文件告诉 GitLab Runner 做什么. 一个简单的管道通常包括三个阶段 ：

  • build
  • test
  • deploy

您不需要使用所有三个阶段； 没有工作的阶段将被忽略.

管道显示在项目的CI / CD>管道页面下. 如果一切运行正常（没有非零返回值），您将获得与提交关联的绿色复选标记. 这样就可以轻松查看提交是否导致任何测试失败，甚至无需查看作业（测试）日志. 许多项目使用 GitLab 的 CI 服务来运行测试套件，因此如果开发人员遇到问题，他们会立即获得反馈.

通常，使用管道将经过测试的代码自动部署到登台和生产环境中.

本指南假定您具有：

  • 8.0+或正在使用GitLab.com 的有效 GitLab 实例.
  • 您要在其中使用 CI 的 GitLab 中的项目.
  • 维护者或所有者对项目的访问

让我们将其分解为 GitLab CI / CD 难题.

Creating a .gitlab-ci.yml file

在创建.gitlab-ci.yml之前，让我们首先简要地解释这是怎么回事.

What is .gitlab-ci.yml

您可以在.gitlab-ci.yml文件中配置 CI 对项目的作用. 它位于存储库的根目录中.

在对存储库进行任何推送时，GitLab 都会查找.gitlab-ci.yml文件，并根据该文件的内容在Runners上启动作业，以进行提交.

由于.gitlab-ci.yml在存储库中并且受版本控制，因此旧版本仍然可以成功构建，fork 可以轻松使用 CI，分支可以具有不同的管道和作业，并且您拥有 CI 的唯一真实来源. 您可以在我们的博客中阅读更多有关为什么使用.gitlab-ci.yml的原因.

Creating a simple .gitlab-ci.yml file

注意： .gitlab-ci.yml是一个YAML文件，因此您必须特别注意缩进. 始终使用空格，不要使用制表符.

您需要在存储库的根目录中创建一个名为.gitlab-ci.yml的文件. 以下是 Ruby on Rails 项目的示例.

image: "ruby:2.5"

before_script:
  - apt-get update -qq && apt-get install -y -qq sqlite3 libsqlite3-dev nodejs
  - ruby -v
  - which ruby
  - gem install bundler --no-document
  - bundle install --jobs $(nproc)  "${FLAGS[@]}"

rspec:
  script:
    - bundle exec rspec

rubocop:
  script:
    - bundle exec rubocop

This is the simplest possible configuration that will work for most Ruby applications:

  1. 用要执行的不同命令定义两个作业rspec和rubocop （名称是任意的）.
  2. 在执行每个作业之前，将执行before_script定义的命令.

.gitlab-ci.yml文件定义了作业集，并限制了作业的运行方式和时间. 作业被定义为具有名称的顶级元素（在我们的示例中为rspec和rubocop ），并且始终必须包含script关键字. 乔布斯被用于创造就业机会，然后由挑选运动员和跑步者的环境中执行.

重要的是每个作业都彼此独立运行.

如果要检查项目的.gitlab-ci.yml是否有效，则项目名称空间的/-/ci/lint页下有一个 Lint 工具. 您也可以在项目的CI / CD➔管道和管道➔作业下找到" CI Lint"按钮以转到此页面.

有关更多信息和完整的.gitlab-ci.yml语法，请阅读.gitlab-ci.yml上的参考文档 .

Push .gitlab-ci.yml to GitLab

创建.gitlab-ci.yml ，应将其添加到 Git 存储库中并将其推送到 GitLab.

git add .gitlab-ci.yml
git commit -m "Add .gitlab-ci.yml"
git push origin master

现在，如果您转到" **管道"**页面，您将看到管道处于挂起状态.

注意：如果您有一个从 GitLab 提取镜像的存储库 ，则可能需要在项目的"设置">"存储库">"从远程存储库中提取">"触发管道以进行镜像更新"中启用管道触发.

您也可以转到" **提交"**页面，注意提交 SHA 旁边的小暂停图标.

New commit pending

单击它，您将被定向到该特定提交的作业页面.

Single commit jobs page

注意，有一个待处理的作业以我们在.gitlab-ci.yml编写的.gitlab-ci.yml . "卡住"表示尚未为此作业配置任何运行器.

下一步是配置运行器，以便它选择挂起的作业.

Configuring a Runner

在 GitLab 中，Runners 运行您在.gitlab-ci.yml定义的作业. Runner 可以是虚拟机，VPS，裸机，Docker 容器甚至是容器集群. GitLab 和 Runners 通过 API 进行通信，因此唯一的要求是 Runner 的计算机具有对 GitLab 服务器的网络访问权限.

Runner 可以特定于某个项目，也可以在 GitLab 中服务多个项目. 如果它服务于所有项目，则称为Shared Runner .

在" 跑步者"文档中查找有关不同跑步者的更多信息.

您可以通过转到设置➔CI / CD来查找是否将任何跑步者分配给您的项目. 设置 Runner 既简单又直接. GitLab 支持的官方 Runner 是用 Go 编写的，其文档可以在https://docs.gitlab.com/runner/中找到.

为了拥有功能正常的 Runner，您需要执行以下两个步骤：

  1. Install it
  2. Configure it

请按照上面的链接设置您自己的 Runner 或使用下一节所述的 Shared Runner.

设置 Runner 之后，您应该在设置➔CI / CD后面的项目的 Runners 页面上看到它.

Activated runners

Shared Runners

如果使用GitLab.com ，则可以使用 GitLab Inc.提供的共享运行程序 .

这些是在 GitLab 基础架构上运行的特殊虚拟机，可以构建任何项目.

要启用共享运行程序，您必须转到项目的设置➔CI / CD ，然后单击启用共享运行程序 .

Read more on Shared Runners.

Seeing the status of your pipeline and jobs

成功配置 Runner 之后，您应该看到上一次提交的状态从" *未决"*更改为" 正在 运行" ，" *成功"*或" 失败" .

您可以转到项目中的" **管道"**页面来查看所有管道.

Commit status

或者，您可以转到" **管道➔作业"**页面查看所有作业.

Commit status

通过单击作业的状态，您将能够看到该作业的日志. 这对于诊断工作为什么失败或行为与您预期的不同很重要.

Build log

您还可以在 GitLab 的各个页面中查看任何提交的状态，例如提交和合并请求 .

Examples

请访问示例自述文件以查看使用各种语言的 GitLab CI 的示例列表.