GitLab CI/CD 流水线配置入门：从 Runner 到首次运行

流水线文件

前提条件，注册一个 gitlab runner，并且该 runner 内部可以访问 giltab 服务进行下载代码。gitlab-runner 的 config.toml 参考如下：

concurrent = 1
check_interval = 0
shutdown_timeout = 0

[session_server]
  session_timeout = 1800

[[runners]]
  name = "runner"
  url = "http://192.168.1.107:8000/"
  token = "glrt-6ByqoP5bmYyz4FyYwozc"
  executor = "docker"
  [runners.custom_build_dir]
  [runners.cache]
    MaxUploadedArchiveSize = 0
    [runners.cache.s3]
    [runners.cache.gcs]
    [runners.cache.azure]
  [runners.docker]
    tls_verify = false
    image = "docker:stable"
    privileged = false
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    volumes = ["/etc/docker/daemon.json://etc/docker/daemon.json:ro","/var/run/docker.sock://var/run/docker.sock","/.m2", "/cache"]
    shm_size = 0
    network_mtu = 0
    extra_hosts = ["gitlab.example.com:192.168.1.107"]
    network_mode = "host"

在gitlab仓库中项目根目录添加一个 .gitlab-ci.yml 文件，文件内容如下：

stages:
  - build
  - deploy

build:
  stage: build
  script:
    - echo "start build"

deploy:
  stage: deploy
  script:
    - echo "start deploy"

这个流水线共包含两个job，分别是build 和 deploy。

build 包含一个stage build，运行构建命令。
deploy 包含一个stage deploy，运行部署命令。

提交文件后，会自动触发cicd流程，查看流水线信息，已成功完成操作。

默认情况下使用项目根目录下的 .gitlab-ci.yml 文件，当然我们也可以本仓库其他路径下的文件或者远程仓库文件路径。

Pipeline 基础语法

default 全局配置

在GitLab CI/CD的流水线中存在几个全局关键词，设置后，这些配置对于整条流水线生效，如stages，include，workflow，default，variables。

在default中你可以将一些关键词配置成全局配置。配置后这些配置项将对每个作业生效，作为初始值，开发者也可以在作业中重新定义覆盖他们。

default:
  image: #定义所有 jobs 的默认 Docker 镜像。
  services: #定义所有 jobs 的默认服务。
  before_script: #定义在所有 jobs 之前运行的脚本。
  after_script: #定义在所有 jobs 之后运行的脚本。
  tags: #定义所有 jobs 的默认标签。
  cache: #定义所有 jobs 的默认缓存策略。
  artifacts: #定义所有 jobs 的默认构件策略。
  retry: #定义所有 jobs 的默认重试策略。
  timeout: #定义所有 jobs 的默认超时时间。
  interruptible: #定义所有 jobs 是否可以被中断。

job

在 .gitlab-ci.yml 的YAML文件中可以定义多个作业，每个作业运行不同的命令，命令可以是shell或脚本。

job1:
  script: "execute-script-for-job1"

job2:
  script: "execute-script-for-job2"

说明：

可以定义一个或多个作业。
每个作业必须具有唯一的名称，作业名称不能使用关键字。
每个作业是独立执行的。
每个作业至少要包含一个script。

script

job:
  script:
    - uname -a
    - bundle exec rspec

注意：

有时， script命令将需要用单引号或双引号引起来.。例如，包含冒号命令（ : ）需要加引号，以便被包裹的YAML解析器知道来解释整个事情作为一个字符串，而不是一个”键：值”对.。
使用特殊字符时要小心： : 、{ 、} 、[ 、] 、, 、 & 、* 、 # 、 ? 、 | 、 - 、 < 、 > 、 = ! 、 % 、@

before_script

前置脚本，用于定义一个命令，该命令在每个作业之前运行。必须是一个数组。指定的script与主脚本中指定的任何脚本串联在一起，并在单个shell中一起执行。

after_script

后置脚本，用于定义将在每个作业（包括失败的作业）之后运行的命令。这必须是一个数组。指定的脚本在新的shell中执行，与任何before_script 或 script 脚本分开。 after_script 可以在全局定义，也可以在 job 中定义。在job中定义会覆盖全局。

default:
  before_script:
    - echo "before-script!!"
  after_script:
    - echo "after-script"

variables:
  DOMAIN: example.com

stages:
  - build
  - deploy

build:
  before_script:
    - echo "before-script in job"
  stage: build
  script:
    - echo "mvn clean "
    - echo "mvn install"
  after_script:
    - echo "after script in job"

deploy:
  stage: deploy
  script:
    - echo "hello deploy"

说明：

after_script 失败不会影响作业失败。
before_scrip t失败导致整个作业失败，其他作业将不再执行。
作业失败不会影响 after_script 运行。

stages

用于定义作业可以使用的阶段，并且是全局定义的。同一阶段的作业并行运行，不同阶段按顺序执行。

stages：
  - build
  - test
  - deploy

这里定义了三个阶段，首先 build 阶段并行运行，然后 test 阶段并行运行，最后deploy阶段并行运行。deploy阶段运行成功后将提交状态标记为 passed 状态。如果任何一个阶段运行失败，最后提交状态为 failed。