一、.gitlab-ci.yml文件的介绍

GitLab中某一个项目下的.gitlab-ci.yml 文件主要是用于告诉执行器(GitLab Runner实例）需要做哪些事情。当文件被提交到GitLab远程仓库以后，在Pipelines处就会自动产生一条流水线(Pipeline)记录。默认情况下流水线有 build 、test 、deploy 三个阶段，即构建、测试 、部署 ，未被使用的阶段将会被自动忽略。

前面我们构建的.gitlab-ci.yml文件里面的内容如下：

job1:
  script:
    - echo 'hello world'

该自定义的job未明确指定属于哪个阶段，则默认属于测试阶段。 

一个.gitlab-ci.yml文件可能包含下述内容：

stages:
  - build
  - test

build-code-job:
  stage: build
  script:
    - echo "Build some project files."

test-code-job1:
  stage: test
  script:
    - echo "If the files are built successfully, test some files with one command."

test-code-job2:
  stage: test
  script:
    - echo "If the files are built successfully, test other files with a different command."

在这个文件中，我们可以定义下述这些事情： 

  • 要运行的脚本
  • 要包含的其它配置文件和模板
  • 依赖性和缓存
  • 您希望按顺序运行的命令和您希望并行运行的命令
  • 将应用程序部署到的位置
  • 您是想自动运行脚本还是手动触发它们

脚本(script)被分组到作业(jobs)中，而作业在一个大的流水线(pipeline)作为它的一部分运行。我们可以将多个独立作业分组到按已定义顺序运行的阶段(stages)中，CI/CD配置至少需要一个未隐藏的作业。

当添加一个gitlab-ci.yml类型的文件到项目仓库中时，GitLab就会检测到它，这时一个名为GitLab Runner的应用程序就会去运行作业中定义的脚本。

在这个示例中，属于build阶段名为“build-code-job”的作业会被首先运行。当“build-code-job”这个作业成功完成后，测试阶段的两个test-code-job作业将并行启动，

示例中的整个流水线由三个作业组成，分为构建和测试两个阶段。每当将更改推送到项目中的任何分支时，流水线就会运行。

GitLab CI/CD不仅可以执行作业，还显示执行过程中发生的事情。当我们点击了上图中的“build-code-job”时，就会显示如下所示的界面：

GitLab中.gitlab-ci.yml文件的介绍可以参考其官方文档：

https://docs.gitlab.com/15.6/ee/ci/yaml/gitlab_ci_yaml.html

二、.gitlab-ci.yml文件的选项配置

GitLab CI/CD管道配置包括下述两个部分：

全局关键字（用于配置管道的行为）

default：自定义的一个值就是Job(作业)的名称

stages：定义管道中的各个阶段名称及其运行顺序

images：使用Docker镜像

Job(作业)中的关键字 

stage：定义该Job(作业)属于哪个阶段

script：被runner运行的Shell脚本 

tags：指定该Job(作业)由哪个runner执行器执行

retry：当Job(作业)执行失败时，设置其重试的次数

2.1 stage

使用stage定义作业在哪个阶段运行，同一个阶段的作业可以并行运行。如果未定义stage，则作业默认使用测试阶段。

关键字类型：属于Job关键字，你可以使用它仅仅作为一个作业的一部分。

使用示例：

stages:
  - build
  - test

job1:
  stage: build
  script:
    - echo "This job compiles code."

job2:
  stage: test
  script:
    - echo "This job tests the compiled code. It runs when the build stage completes."

2.2 script

使用script指定runner要执行的命令，除了trigger jobs以外所有的Job都必须要有一个script关键字。

关键字类型：属于Job关键字，你可以使用它仅仅作为一个作业的一部分。

使用示例：

job1: 
  script: "echo 'Hello World from job1'"

job2:
  script:
    - echo "Hello World from job21"
    - echo "Hello World from job22"

script关键字既可以使用单行命令，也可以使用多行长命令。当遇到了特殊字符时，可参考下述官方文档：

https://docs.gitlab.com/15.6/ee/ci/yaml/script.html#use-special-characters-with-script

2.3 retry

使用retry配置任务失败时重试的次数，如果没有配置，默认值为0，任务不会重试。

其最大值为2，最多重试2次，运行三次。

关键字类型：属于Job关键字，你可以使用它仅仅作为一个作业的一部分。

使用示例：

job1: 
  script: rspec
  retry: 2

可以看到该任务在执行失败以后，会被重试执行2次，一共执行了3次。 

retry关键字除了单独使用外，还可以结合when和max关键字一起使用。例如可以使用 retry:when和 retry:max 仅针对特定的失败情况重试作业，retry:max是重试的最大次数，其值可以是0、1或2。

使用示例1：(仅了解即可)

job1:
  script: rspec
  retry:
    max: 2
    when: runner_system_failure

使用示例2： (仅了解即可)

job1:
  script: rspec
  retry:
    max: 2
    when:
      - runner_system_failure
      - stuck_or_timeout_failure

GitLab中.gitlab-ci.yml文件的选项配置可参考官网文档：

https://docs.gitlab.com/15.6/ee/ci/yaml/index.html

2.4 image 

指定一个基础镜像作为一个作业在运行时所需要的基础运行环境，经常用到的镜像有node、nginx、docker。

image: docker:latest

job1: 
  script: docker -v

在上面这个任务中，如果不指定image: docker:latest 执行下面的docker -v时会报错，找不到docker的命令，image的作用就是给当前任务或者当前流水线设置一个基础环境。

2.5 cache

指定要在作业之间缓存的文件和目录列表，只能使用本地工作副本中的路径。

prepare-dependencies-job:
  stage: build
  cache:
    key: gems
    paths:
      - vendor/bundle
    policy: push
  script:
    - echo "This job only downloads dependencies and builds the cache."
    - echo "Downloading dependencies..."

faster-test-job:
  stage: test
  cache:
    key: gems
    paths:
      - vendor/bundle
    policy: pull
  script:
    - echo "This job script uses the cache, but does not update it."
    - echo "Running tests..."

2.6 only/except

配置Job是否可以运行，如下图所示：

job_build:
  stage: build
  script:
    - echo "123"
  only:
    - develop

job_deploy:
  stage: test
  script:
    - echo "456"

仅仅是develop分支时才会运行job_build。 

2.7 when

使用when配置作业运行的条件，如下图所示：

job_build:
  stage: build
  script:
    - echo "123"

job_deploy:
  stage: test
  script:
    - echo "456"
  when: manual

三、CI/CD 变量

CI/CD变量是一种环境变量，我们可以使用它进行下述处理：

控制管道和作业的行为

存储我们想重复使用的值

避免在.gitlab-ci.yml文件中使用硬编码值

3.1 预定义的变量

GitLab CI/CD有一组默认的预定义CI/CD变量，可以在管道配置和作业脚本中使用。我们可以在.gitlab-ci.yml文件中没有声明这个变量的情况下直接使用预定义的CI/CD变量：

下面的例子展示了如何使用预定义变量CI_JOB_STAGE输出作业的阶段：

test_variable:
  stage: test
  script:
    - echo "$CI_JOB_STAGE"

3.2 在.gitlab-ci.yml中自定义

我们可以在作业中或者.gitlab-ci.yml文件的顶部使用variables关键字。如果变量位于顶部，则它是全局可用的，所有作业都可以使用它。如果它在作业中定义，则只有该作业可以使用它。

variables:
  TEST_VAR: "All jobs can use this variable's value"

job1:
  variables:
    TEST_VAR_JOB: "Only job1 can use this variable's value"
  script:
    - echo "$TEST_VAR" and "$TEST_VAR_JOB"

3.3 在项目中设置变量

第一步： 进入到项目的Settings->CI/CD下，找到Variables并点击后面的“Expand”按钮，如下图所示

第二步： 接着点击“Add variable”按钮

第三步：使用项目中所定义的变量

job1:
  stage: test
  script:
    - echo "$hello"

3.4 导出所有的变量

get_all_var:
  script:
    - export

关于Variables的相关资料可参考其官方文档：

https://docs.gitlab.com/15.6/ee/ci/variables/#create-a-custom-cicd-variable-in-the-gitlab-ciyml-file

四、流水线的类型

基本流水线（最常见的流水线）

DAG流水线

多项目流水线（仅了解）

父子流水线（仅了解）

合并请求流水线（仅了解）

4.1 DAG流水线

DAG流水线依赖于needs关键字，主要用于将一个项目部署到不同的环境中（Linux和Windows平台）， 以下为使用示例：

stages:
  - build
  - test
  - deploy

image: alpine

build_a:
   stage: build
   script: 
      - echo "This job builds something quickly."

build_b:
   stage: build
   script: 
      - echo "This job builds something else slowly."

test_a:
  stage: test
  needs: [build_a]
  script:
    - echo "This test job will start as soon as build_a finishes."
    - echo "It will not wait for build_b, or other jobs in the build stage, to finish."

test_b:
  stage: test
  needs: [build_b]
  script: 
    - echo "This test job will start as soon as build_b finishes."
    - echo "It will not wait for other jobs in the build stage to finish."

deploy_a:
  stage: deploy
  needs: [test_a]
  script:
    - echo "Since build_a and test_a run quickly, this deploy job can run much earlier."
    - echo "It does not need to wait for build_b or test_b."

deploy_b:
  stage: deploy
  needs: [test_b]
  script:
    - echo "Since build_b and test_b run slowly, this deploy job will run much later."

其项目部署的关系依赖图如下： 

DAG流水线的更多资料可参考其官方文档：

https://docs.gitlab.com/15.6/ee/ci/directed_acyclic_graph/

五、流水线的触发方式

推送代码（最常见的触发方式）

定时触发

url触发

手动触发（例如作业执行后带有Retry按钮，就可以手动触发）

5.1 定时触发

第一步：进入到项目的CI/CD->Schedules下，找到并点击“New schedule”按钮，如下图所示

第二步：在这个界面中填写Description、Custom触发时间以及选择时区

第三步：可以看到在Schedules列表中新增了一条定时调度的记录

大概过了几分钟以后，在Pipelines列表中就自动触发了一个流水线，并且其标签是Scheduled，如下图所示： 

5.2 url触发

第一步：进入到项目的Settings->CI/CD下，找到Pipeline triggers并点击后面的“Expand”按钮，如下图所示

第二步：填写好Description信息内容以后，直接点击“Add trigger”按钮

接着在Pipeline triggers下方就会新增一行记录，重点关注的是产生的Token值

第三步： 在Postman中以form-data的形式发送Post请求触发流水线

curl --request POST --url http://192.168.1.112:8989/api/v4/projects/4/trigger/pipeline \
--form token=glptt-180baebdbb5f25db96cf1524d8c782bab61d72ee \
--form ref=main

# gitlab
Logo
腾讯云开发者社区

腾讯云面向开发者汇聚海量精品云计算使用和开发经验，营造开放的云计算技术生态圈。

更多推荐

Elasticsearch复杂数据类型终极指南：从入门到精通

Elasticsearch作为功能强大的搜索引擎，支持多种复杂数据类型，让开发者能够灵活处理各种结构化和非结构化数据。本文将带你全面了解Elasticsearch中的复杂数据类型，从基础概念到实际应用，助你轻松掌握数据建模的核心技巧。## 内部对象：构建层级化数据结构在Elasticsearch中，对象类型（Object）是最基础的复杂数据类型之一，用于表示具有嵌套关系的数据。例如，我们可

avatar 腾讯云开发者社区

终极指南：Flink SQL连接器版本管理从混乱到有序的升级之路

Apache Flink作为流处理领域的佼佼者，其SQL连接器的版本管理一直是开发者面临的核心挑战。本文将系统讲解Flink SQL连接器版本管理的最佳实践，帮助你轻松应对版本兼容性问题，实现从混乱到有序的升级之旅。## 连接器版本管理的常见痛点 😫在Flink应用开发中，连接器版本管理常常让开发者头疼不已。不同版本的连接器可能导致各种兼容性问题，例如API变更、功能差异甚至运行时错误。

avatar 腾讯云开发者社区

如何快速搭建Neon无服务器PostgreSQL：面向初学者的完整指南

Neon是一款革命性的无服务器PostgreSQL解决方案，它通过分离存储和计算层，实现了自动扩缩容、类代码式数据库分支以及零级扩展能力。本指南将帮助你从零开始搭建Neon开发环境，体验这款创新数据库的强大功能。## 准备工作：环境要求与依赖项在开始搭建Neon环境前，请确保你的系统满足以下要求：- Linux操作系统（推荐Ubuntu 20.04+或Debian 11+）- Git

avatar 腾讯云开发者社区