简介

关于gitlab的入门与实战，这里使用的是docker安装。2核4g的话不太行。 

安装

由于这里我是学习环境,所以买的是抢占式，配置也不是很高。

购买服务器示例

Docker安装步骤

1.安装docker

yum install -y docker

  

2.启动docker

systemctl start docker

3.设置开启启动

systemctl enable  docker

配置docker加速

4.更具下面的配置配置好镜像加速

sudo mkdir -p /etc/docker
sudo tee /etc/docker/daemon.json <<-'EOF'
{
  "registry-mirrors": ["https://obnqc505.mirror.aliyuncs.com"]
}
EOF
sudo systemctl daemon-reload
sudo systemctl restart docker

 5.拉去gitlab镜像

docker search gitlab

6.拉取你要安装的镜像.

#1:拉取gitlab镜像
docker pull gitlab/gitlab-ce  
#2:生成挂载目录
mkdir -p /home/gitlab/etc/gitlab	
mkdir -p /home/gitlab/var/log
mkdir -p /home/gitlab/var/opt
#3:启动容器（用的时候调整下命令，为了便于查看，有换行符）
docker run 
-d                #后台运行，全称：detach
-p 8443:443      #将容器内部端口向外映射
-p 8090:80       #将容器内80端口映射至宿主机8090端口，这是访问gitlab的端口
-p 8022:22       #将容器内22端口映射至宿主机8022端口，这是访问ssh的端口
--restart always #容器自启动
--name gitlab    #设置容器名称为gitlab
-v /usr/local/gitlab/etc:/etc/gitlab    #将容器/etc/gitlab目录挂载到宿主机/usr/local/gitlab/etc目录下，若宿主机内此目录不存在将会自动创建
-v /usr/local/gitlab/log:/var/log/gitlab    #与上面一样
-v /usr/local/gitlab/data:/var/opt/gitlab   #与上面一样
--privileged=true         #让容器获取宿主机root权限
twang2218/gitlab-ce-zh    #镜像的名称，这里也可以写镜像ID（这个是别人的镜像）



# -d：后台运行
# -p：将容器内部端口向外映射
# --name：命名容器名称
# -v：将容器内数据文件夹或者日志、配置等文件夹挂载到宿主机指定目录

【–privileged=true 要加上，不然可能因为权限问题导致启动失败】
这里不要着急 稍等一会
此时访问对应的主机是有界面了，如果网络不可用或者502，就再等个几分钟，此时容器尚未启动完全，下面是我的运行命令，由于我的镜像是下面这种情况，Imageid也是对应的镜像，只要远程镜像还在那么这个镜像id也不会改变。

docker run \
-d \
-p 8443:443 \
-p 8090:80 \
-p 222:22  \
--restart always \
--name gitlab \
-v /home/gitlab/etc/gitlab:/etc/gitlab   \
-v /home/gitlab/var/log:/var/log/gitlab   \
-v /home/gitlab/var/opt:/var/opt/gitlab    \
--privileged=true     \
46cd6954564a

7.修改对应的配置文件。

sudo vi /home/gitlab/etc/gitlab/gitlab.rb

# 配置http协议所使用的访问地址,不加端口号默认为80,47.98.156.164是我的公网地址，如果是虚拟机就写192.168.1.1内网地址就行
pages_external_url = "http://0.0.0.0"

# 配置ssh协议所使用的访问地址和端口47.98.156.164是我的公网地址，如果是虚拟机就写192.168.1.1内网地址就行，这个就是git clone的时候目标地址，所有这个就是哪个能通就是哪个地址，我这里使用了公网，所以我写的公网地址。下面的222是git clone 的端口，所以和上面-p 222:222 刚好对应47.98.156.164:222,所以就能访问到容器的代码仓库了。
gitlab_rails['gitlab_ssh_host'] = '47.98.156.164'
gitlab_rails['gitlab_shell_ssh_port'] = 222 # 此端口是run时22端口映射的222端口，也就是上面的-p 222:22 ，不然会一直要输入密码还不正确
:wq! #保存配置文件并退出
        
# 重启gitlab容器gitlab是自己创建的容器名称用docker ps -a可以查看
docker restart gitlab

如果克隆仓库的时候一直要输入密码问题

 

 

拉去项目前先配置下ssh,因为现在这种配置只能使用ssh （记得打开下222的安装组）

8.root所需 (修改密码，这里也就是gitlab的root登录的密码)

 # 进入容器内部
docker exec -it gitlab /bin/bash

# 进入控制台
gitlab-rails console -e production
#查看所有用户
u=User.all

# 查询id为1的用户，id为1的用户是超级管理员
user = User.where(id:1).first
# 修改密码为123456
user.password='123456'
#确认密码
user.password_confirmation='123456'
# 保存
user.save!
# 退出
exit;

进入控制台的时候有点慢稍等一会就行了。 

 保存的时候，多保存几次多设置几次，也就是下面的命令多执行几次，如下图因为有可能会保存失败多保存几次就差不多了 。

# 查询id为1的用户，id为1的用户是超级管理员
user = User.where(id:1).first
# 修改密码为123456
user.password='123456'
# 保存
user.save!

9.查找root 初始化密码（如果上面没有操作成功的话，就可以使用下初始密码）。

docker exec -it gitlab cat  /etc/gitlab/initial_root_password

 10.访问自己的http://公网ip:8090

访问如果是502可能是程序还没有起来，等一会在访问就可以了 。

记得开启下8090的安全组

输入root/123456登录

 11.拉取同版本的gitlab

docker pull registry.cn-hangzhou.aliyuncs.com/rouyitest/completeimages:gitlabv1.0

用自己的阿里云公开镜像操作一波

1.拉取镜像。

docker pull registry.cn-hangzhou.aliyuncs.com/rouyitest/completeimages:gitlabv1.0

2.创建对应的目录。

mkdir -p /home/gitlab/etc/gitlab	
mkdir -p /home/gitlab/var/log
mkdir -p /home/gitlab/var/opt

3.启动容器。

GitLab/CI/CD入门

简介

由于目前公司使用的gitlab，大部分项目使用的CICD是gitlab的CICD，少部分用的是jenkins，使用了gitlab-ci一段时间后感觉还不错，因此总结一下

介绍gitlab的CICD之前，可以先了解CICD是什么

我们的开发模式经历了如下的转变：瀑布模型->敏捷开发→DevOps(Development、Operations的组合词，是一组过程、方法与系统的统称)

后来随着DevOps的兴起，出现了持续集成（Continuous Integration）、持续交付（Continuous Delivery） 、持续部署（Continuous Deployment） 的新方法，关于持续集成、持续交付、持续部署，总结如下：

• 持续集成的重点是将各个开发人员的工作集合到一个代码仓库中。通常，每天都要进行几次，主要目的是尽早发现集成错误，使团队更加紧密结合，更好地协作。
• 持续交付的目的是最小化部署或释放过程中固有的摩擦。它的实现通常能够将构建部署的每个步骤自动化，以便任何时刻能够安全地完成代码发布（理想情况下）。
• 持续部署是一种更高程度的自动化，无论何时对代码进行重大更改，都会自动进行构建/部署。

持续集成的好处是什么？

持续集成可以使问题尽早暴露，从而也降低了解决问题的难度，正如老马所说，持续集成无法消除bug，但却能大大降低修复的难度和时间。

持续交付的好处是什么？

持续交付的好处在于快速获取用户反馈；适应市场变化和商业策略的变化。开发团队保证每次提交的修改都是可上线的修改，那么决定何时上线，上线哪部分功能则完全由产品业务团队决定。

虽然持续交付有显著的优点，但也有不成立的时候，比如对于嵌入式系统的开发，往往需要软硬件的配合。

持续部署的好处是什么？

持续部署的目标是通过减少批量工作的大小，并加快团队工作的节奏，帮助开发团队在其开发流程中消除浪费。这使团队能够一直处于一种可持续的平稳流状态， 让团队更容易去创新、试验，并达到可持续的生产率

市面上的CI有很多，如果在github上搜一下ci工具，也会搜到很多，比如：

1. Travis CI
2. Circle CI
3. Jenkins
4. AppVeyor
5. CodeShip
6. Drone
7. Semaphore CI
8. Buildkite
9. Wercker
10. TeamCity

这里只介绍Gitlab-CI

GitLab 是 CI/CD 领域的一个新手玩家，但它已经在 Forrester Wave 持续集成工具中占据了领先地位。在这样一个竞争对手众多而水平又很高的领域，这是一项巨大的成就。是什么让 GitLab CI 如此了不起？

• 它使用 YAML 文件来描述整个管道。
• 它还有一个功能叫 Auto DevOps，使比较简单的项目可以自动构建内置了若干测试的管道。
• 使用 Herokuish 构建包来确定语言以及如何构建应用程序。有些语言还可以管理数据库，对于构建新的应用程序并在开发过程一开始就将其部署到生产环境中，这是一个很重要的功能。
• 提供到 Kubernetes 集群的原生集成，并使用多种部署方法的一种（如基于百分比的部署和蓝绿部署）将应用程序自动部署到 Kubernetes 集群中。

除了 CI 功能之外，GitLab 还提供了许多补充功能，比如自动把 Prometheus 和你的应用程序一起部署，实现运行监控；使用 GitLab 问题（Issues）、史诗（Epics）和里程碑（Milestones）进行项目组合和项目管理；管道内置了安全检查，提供跨多个项目的聚合结果；使用 WebIDE 在 GitLab 中编辑代码的能力，它甚至可以提供预览或执行管道的一部分，以获得更快的反馈。

相关概念

pipeline（管道、流水线）

• 一次 Pipeline 其实相当于一次构建任务，里面可以包含多个流程（Stage），比如自动构建、自动进行单元测试、自动进行代码检查等流程 ;
• 任何提交或者 Merge Request 的合并都可以触发 Pipeline ;

Stage（构建阶段）

• Stage表示构建阶段，就是上面提到的流程 ;
• 可以在一次 Pipeline中定义多个 Stage;
• Stage有如下特点 :
  • 所有 stages 会按照顺序运行，即当一个 stage 完成后，下一个 Stage才会开始
  • 只有当所有 Stage 成功完成后，该构建任务 Pipeline 才算成功
  • 如果任何一个 Stage失败，那么后面的 Stage 不会执行，该构建任务 (Pipeline) 失败

阶段是对批量的作业的一个逻辑上的划分，每个 pipeline都必须包含至少一个 Stage。多个 Stage是按照顺序执行的，如果其中任何一个 Stage失败，则后续的 Stage不会被执行，整个 CI 过程被认为失败。

Jobs（任务）

• job表示构建工作，表示某个stage里面执行的工作 ;
• 一个stage里面可以定义多个job ;
• jobs有如下特点 :
  • 相同 stage 中的jobs 会并行执行
  • 相同 stage 中的 jobs 都执行成功时，该 stage 才会成功
  • 如果任何一个job 失败，那么该 stage 失败，即该构建任务 (Pipeline) 失败

举一个例子，比如下面这个图

这里的四个Statge(阶段): Verify、Build、Dockerpush、Deploy四个，这四个阶段组成一条Pipeline

每个阶段都有一个job，所以总共四个job，也就是unit-test、java-package、docker-push、service-1这四个，当然，每个stage可以由多个job组成，比如下面这个图：

Job 的执行过程中往往会产生一些数据，默认情况下 GitLab Runner 会保存 Job 生成的这些数据，然后在下一个 Job 执行之前（甚至不局限于当次 CI/CD）将这些数据恢复。这样即便是不同的 Job 运行在不同的 Runner 上，它也能看到彼此生成的数据。

.gitlab-ci.yml中提供了 before_script 和 after_script 两个全局配置项。这两个配置项在所有 Job 的 script 执行前和执行后调用。

关于.gitlab-ci.yml、before_script、after_script是什么，先别急，在后面有介绍

 关于.gitlab-ci.yml、before_script、after_script是什么，先别急，在后面有介绍

所以了解了Pipeline、Stage、Jobs后，还有一个很重要的东西，就是Runner

Runner

Runner就像一个个的工人，而Gitlab-CI就是这些工人的一个管理中心，所有工人都要在Gitlab-CI里面登记注册，并且表明自己是为哪个工程服务的。当相应的工程发生变化时，Gitlab-CI就会通知相应的工人执行软件集成脚本。如下图所示：

gitlab里面的runner叫Gitlab-Runner，Gitlab-Runner是配合Gitlab-CI进行使用的。一般地，Gitlab里面的每一个工程都会定义一个属于这个工程的软件集成脚本，用来自动化地完成一些软件集成工作。当这个工程的仓库代码发生变动时，比如有人push了代码，GitLab就会将这个变动通知Gitlab-CI。这时Gitlab-CI会找出与这个工程相关联的Runner，并通知这些Runner把代码更新到本地并执行预定义好的执行脚本(也就是在Job执行流程那个图中所示的第三步：script)，所以，Gitlab-Runner就是一个用来执行软件集成脚本script的东西。

Runner类型

Gitlab-Runner可以分类两种类型：Shared Runner（共享型）和Specific Runner（指定型）。

• Shared Runner：这种Runner（工人）是所有工程都能够用的。只有系统管理员能够创建Shared Runner。
• Specific Runner：这种Runner（工人）只能为指定的工程服务。拥有该工程访问权限的人都能够为该工程创建Shared Runner。

关于Gitlab-runner的安装，会以单独一个文章进行介绍，注册runner会对应一个tag，记住这个tag；

Runner安装

链接：https://pan.baidu.com/s/1ze9EIvtMi03qvmQQDMhJ2A 
提取码：yyds 
--来自百度网盘超级会员V5的分享

1.获取安装脚本并且执行。

wget http://mirrors.tuna.tsinghua.edu.cn/gitlab-runner/yum/el7/gitlab-runner-12.9.0-1.x86_64.rpm

2.安装 

rpm -ivh gitlab-runner-12.9.0-1.x86_64.rpm  --nodeps --force

 3.获取Runner注册Token

安装好Runner之后，需要向Gitlab进行注册，注册Runner需要GitLab-CI的url和token。可根据需求注册选择所需类型Runner。这里介绍spercific runners为例

4.runner配置

sudo gitlab-runner register

 注意，在要求输入tag时，想好tag的名字，这个就相当于你的runner的id

## 输入url
a、Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com )
 
## 输入token
b、Please enter the gitlab-ci token for this runner
 
## 写个描述
c、Please enter the gitlab-ci description for this runner
 
## 这个tag很重要，好好想个名字并记住，随后在ci配置中需要对应上。
d、Please enter the gitlab-ci tags for this runner (comma separated)
 
## ci没有配置tags时是否执行这个runner？建议采用默认值。            
e、Whether to run untagged builds [true/false]
 
## 是否只对当前工程有效？理论上讲只有“Shared runners”才有效。选true。            
f、Whether to lock Runner to current project [true/false]
 
## 选择一个执行器。我们接来下的方案是基于shell的，输入shell。    
g、Please enter the executor: virtualbox, docker+machine, kubernetes, parallels, docker-ssh, shell, ssh, docker-ssh+machine, docker:

 注册完成后，会出现一个runner，我这里注册了两个，所以会有两个tag

runner 左边会有一个小绿点，表示该runner是能正常执行的

 提高runner的权限变成root用户权限

 ps -ef | grep runner
 gitlab-runner uninstall
 gitlab-runner install --working-directory /root --user root
 gitlab-runner restart
#查看runner的运行状态
 gitlab-runner status

 5.Gitlab-runner的配置(可选)。

GitLab-CI会为这个Runner生成一个唯一的token，以后Runner就通过这个token与GitLab-CI进行通信。

那么，问题来了。注册好了的Runner的信息存放在哪儿了呢？

原来，Runner的信息是存放在一个配置文件里面的，配置文件的格式一般是.toml。这个配置文件的存放位置有以下几种情况：

• 在类Unix操作系统下（0.5.0之后版本）
  • 如果是以root用户身份运行gitlab-runner register，那么配置文件默认是/etc/gitlab-runner/config.toml
  • 如果是以非root用户身份运行gitlab-runner register，那么配置文件默认是~/.gitlab-runner/config.toml
• 在其他操作系统下以及0.5.0之前版本

配置文件默认在当前工作目录下./config.toml

一般情况下，使用默认的配置文件存放Runner的配置信息就可以了。当然，如果你有更细化的分类需求，你也可以在注册的时候通过-c或--config选项指定配置文件的位置。具体查看register命令的使用方法：gitlab-runner register --help。

问题：如果不运行gitlab-runner register命令，直接在配置文件里面添加Runner的配置信息可以吗？

回答：当然不可以。因为gitlab-ci-runner register的作用除了把Runner的信息保存到配置文件以外，还有一个很重要的作用，那就是向GitLab-CI发出请求，在GitLab-CI中登记这个Runner的信息并且获取后续通信所需要的token。

 .gitlab-ci.yml简介

.gitlab-ci.yml 文件被用来管理项目的 runner 任务，Gitlab CI通过.gitlab-ci.yml文件管理配置job，该文件定义了statge顺序、job应该如何触发和工作、执行什么脚本、如何构建pipeline等流程

该文件存放于仓库的根目录, 默认名为.gitlab-ci.yml

我们先看一个简单的例子：.gitlab-ci.yml

## 定义pipeline流程：verify->build->dockerpush->deploy
stages:
  - verify
  - build
  - dockerpush
  - deploy

#单元测试
unit-test:
  stage: verify # 属于哪个流程
  tags:
    - test-cicd # 在哪个runner上面执行，在注册runner可以自定义
  script:
    - echo unit-test # 执行脚本

#java编译
java-package:
  stage: build
  tags:
    - test-cicd
  script:
    - echo build

#push镜像
docker-push:
  stage: dockerpush
  tags:
    - test-cicd
  script:
    - echo docker-push

#deploy
service-1:
  stage: deploy
  tags:
    - test-cicd
  script:
    - echo deploy

stage比较详细的配置

stages:
  - update_master
update_production_env:
  stage: update_master
  script:
    - cd /u02/nginx/html/mercial.iu95522.com
    - git pull origin master
    - if [ -f "system/config.php" ]; then
    -   rm -rf system/config.php
    - fi
    - cp system/config.php.master system/config.php
    - chown -R nginx.nginx *
  only:
    - master
  tags:
    - tags_of_iuh_801_mercial.iu95522.com_master
stages下的deploy说明在代码提交后CI需要执行deploy节点的内容。
deploy的script就是一个个shell命令，这里需要注意每个命令都以杠+空格开头。
only：只有向dev分支提交代码时才生效。
tags：只有拥有该tags的Runner才需要执行

该配置对应下面的pipeline，test-cicd是一个Specific Runner，执行脚本的类型是shell

所以，以unit-test这个job为例，点击该任务可以进入到log界面查看整个log执行流程

剩下的job的执行日志都大部分如此，就不一一列举了 

几个重要的关键字解析

关于gitlab-ci.yml，里面有很多关键字配置，下面我主要列举一些比较常用的关键字

before_script和after_script

随着项目越来越大，Job 越来越多，Job 中包含的重复逻辑可能会让配置文件臃肿不堪。.gitlab-ci.yml 中提供了 before_script 和 after_script 两个全局配置项。这两个配置项在所有 Job 的 script 执行前和执行后调用。

before_script 和 script 在一个上下文中是串行执行的，after_script 是独立执行的。所以根据执行器(在runner注册的时候，可以选择执行器，docker,shell 等)的不同，工作树之外的变化可能不可见，例如，在before_script中执行软件的安装。

你可以在任务中定义 before_script，after_script，也可以将其定义为顶级元素，定义为顶级元素将为每一个任务都执行相应阶段的脚本或命令。

stages

stages的允许定义多个，灵活的场景阶段的pipline。定义的元素的顺序决定了任务执行的顺序。例如：

## 定义pipeline流程：verify->build->dockerpush->deploy
stages:
  - verify
  - build
  - dockerpush
  - deploy

• build场景的任务将被并行执行。test、deploy 同理
• build 任务成功后，test 执行。test 成功后，deploy 执行
• 所有的都成功了，提交将会标记为成功
• 任何一步任务失败了，提交标记为失败并之后的场景，任务都不回执行。

tags

tags可以从允许运行此项目的所有Runners中选择特定的Runners来执行jobs。

在注册Runner的过程中，我们可以设置Runner的标签，tags可通过tags来指定特殊的Runners来运行jobs：

#单元测试
unit-test:
  stage: verify # 属于哪个流程
  tags:
    - test-cicd # 在哪个runner上面执行，在注册runner可以自定义

script

script是一段由Runner执行的shell脚本，可以执行多个，例如：

job:
    script: mvn clean test

这个参数也可以使用数组包含好几条命令

job:
    script:
        - pwd
        - mvn clean test

only and except

only和except两个参数说明了job什么时候将会被创建:

• only定义了job需要执行的所在分支或者标签
• except定义了job不会执行的所在分支或者标签

以下是这两个参数的几条用法规则：

• only和except如果都存在在一个job声明中，则所需引用将会被only和except所定义的分支过滤.
• only和except允许使用正则
• only和except可同时使用。如果only和except在一个job配置中同时存在，则以only为准，跳过except(从下面示例中得出)。
• only和except允许使用特殊的关键字：branches，tags和triggers。
• only和except允许使用指定仓库地址但不是forks的仓库(查看示例3)。

例子解析：

1.job将会只在issue-开头的refs下执行，反之则其他所有分支被跳过：

job:
    # use regexp
    only:
        - /^issue-.*$/
    # use special keyword
    except:
        - branches

2.job只会在打了tag的分支，或者被api所触发，或者每日构建任务上运行

job:
    # use special keywords
    only:
        - tags      # tag 分支 commit 之后触发
        - triggers  # API 触发
        - schedules # 每日构建触发

3.job将会在父仓库gitlab-org/gitlab-ce的非master分支有提交时运行。

job:
    only:
        - branches@gitlab-org/gitlab-ce
    except:
        - master@gitlab-org/gitlab-ce

when

when可以设置以下值：

1. on_success - 只有前面stages的所有工作成功时才执行。 这是默认值。
2. on_failure - 当前面stages中任意一个jobs失败后执行。
3. always - 无论前面stages中jobs状态如何都执行。
4. manual - 手动执行(GitLab8.10增加)。

stages:
- build
- cleanup_build
- test
- deploy
- cleanup
 
build_job:
  stage: build
  script:
  - make build
 
cleanup_build_job:
  stage: cleanup_build
  script:
  - cleanup build when failed
  when: on_failure
 
test_job:
  stage: test
  script:
  - make test
 
deploy_job:
  stage: deploy
  script:
  - make deploy
  when: manual
 
cleanup_job:
  stage: cleanup
  script:
  - cleanup after jobs
  when: always

脚本说明：

• 只有当build_job失败的时候才会执行`cleanup_build_job 。
• 不管前一个job执行失败还是成功都会执行`cleanup_job 。
• 可以从GitLab界面中手动执行deploy_jobs。

manual：

• 在GitLab的用户界面中显示该作业的“播放”按钮
• 意味着deploy_job仅在单击“播放”按钮时才会触发job。

修改上面那个例子

stages:
  - verify
  - build
  - dockerpush
  - deploy
  - cleanup

before_script:
  - pwd
after_script:
  - echo after_script

#单元测试
unit-test:
  stage: verify
  tags:
    - test-cicd
  script:
    - echo unit-test

#java编译
java-package:
  stage: build
  tags:
    - test-cicd
  script:
    - echo build

#push镜像
docker-push:
  stage: dockerpush
  tags:
    - test-cicd
  script:
    - echo docker-push

#deploy
service-1:
  stage: deploy
  tags:
    - test-cicd
  script:
    - echo deploy
  when: manual # 手动触发job，只有点击按钮才会触发

cleanup_job:
  stage: cleanup
  script:
    - echo clean up
  when: always # 前面的job成功与否，都会执行该job

pipeline如下:

allow_failure

跟when一起控制job执行与否的配置还有一个就是allow_failure

allow_failure可以用于当你想设置一个job失败的之后并不影响后续的CI组件的时候。失败的jobs不会影响到commit状态。

下面的这个例子中，java-package和java-package2将会并列进行，如果java-package2失败了，它也不会影响进行中的下一个stage，因为这里有设置了allow_failure: true。

stages:
  - verify
  - build
  - dockerpush
  - deploy
  - cleanup

before_script:
  - pwd
after_script:
  - echo after_script

#单元测试
unit-test:
  stage: verify
  tags:
    - test-cicd
  script:
    - echo unit-test

#java编译
java-package:
  stage: build
  tags:
    - test-cicd
  script:
    - echo build

#java编译
java-package2:
  stage: build
  tags:
    - test-cicd
  script:
    - execute_script_that_will_fail # 该shell会导致job执行失败
  allow_failure: true # 不影响后面的任务进行

#push镜像
docker-push:
  stage: dockerpush
  tags:
    - test-cicd
  script:
    - echo docker-push

#deploy
service-1:
  stage: deploy
  tags:
    - test-cicd
  script:
    - echo deploy
  when: manual

cleanup_job:
  stage: cleanup
  tags:
    - test-cicd
  script:
    - echo clean up
  when: always

 java-package2会执行错误

运行的pipeline如下，可见java-package2的执行错误

variables

GitLab CI允许你为.gitlab-ci.yml增加变量，该变量将会被设置入任务环境。通过两种方式可以引用

• 美元符+大括号引用：${}
• 美元符：$

示例如下：

variables:
  SOFT_VERSION: '1.0'
  TAG_NAME: 'xxx'
#构建镜像
docker-build:
  stage: dockerpush
  tags:
    - test-cicd
  script:
    - docker build -t $TAG_NAME:${SOFT_VERSION}

 如果有些值不想在配置文件中显示，比如密码什么的，可以在代码仓库中setting->CICD->Variables 自定义变量，跟在.gitlab-ci.yml配置变量效果是一样的

variables的保留字

gitlab-ci有一些预定义变量，这些变量大部分以CI开头

预定义变量：

Variable	GitLab	Runner	Description
CI	all	0.4	标识该job是在CI环境中执行
CI_COMMIT_REF_NAME	9.0	all	用于构建项目的分支或tag名称
CI_COMMIT_REF_SLUG	9.0	all	先将$CI_COMMIT_REF_NAME的值转换成小写，最大不能超过63个字节，然后把除了0-9和a-z的其他字符转换成-。在URLs和域名名称中使用。
CI_COMMIT_SHA	9.0	all	commit的版本号
CI_COMMIT_TAG	9.0	0.5	commit的tag名称。只有创建了tags才会出现。
CI_DEBUG_TRACE	9.0	1.7	debug tracing开启时才生效
CI_ENVIRONMENT_NAME	8.15	all	job的环境名称
CI_ENVIRONMENT_SLUG	8.15	all	环境名称的简化版本，适用于DNS，URLs，Kubernetes labels等
CI_JOB_ID	9.0	all	GItLab CI内部调用job的一个唯一ID
CI_JOB_MANUAL	8.12	all	表示job启用的标识
CI_JOB_NAME	9.0	0.5	.gitlab-ci.yml中定义的job的名称
CI_JOB_STAGE	9.0	0.5	.gitlab-ci.yml中定义的stage的名称
CI_JOB_TOKEN	9.0	1.2	用于同GitLab容器仓库验证的token
CI_REPOSITORY_URL	9.0	all	git仓库地址，用于克隆
CI_RUNNER_DESCRIPTION	8.10	0.5	GitLab中存储的Runner描述
CI_RUNNER_ID	8.10	0.5	Runner所使用的唯一ID
CI_RUNNER_TAGS	8.10	0.5	Runner定义的tags
CI_PIPELINE_ID	8.10	0.5	GitLab CI 在内部使用的当前pipeline的唯一ID
CI_PIPELINE_TRIGGERED	all	all	用于指示该job被触发的标识
CI_PROJECT_DIR	all	all	仓库克隆的完整地址和job允许的完整地址
CI_PROJECT_ID	all	all	GitLab CI在内部使用的当前项目的唯一ID
CI_PROJECT_NAME	8.10	0.5	当前正在构建的项目名称（事实上是项目文件夹名称）
CI_PROJECT_NAMESPACE	8.10	0.5	当前正在构建的项目命名空间（用户名或者是组名称）
CI_PROJECT_PATH	8.10	0.5	命名空间加项目名称
CI_PROJECT_PATH_SLUG	9.3	all	$CI_PROJECT_PATH小写字母、除了0-9和a-z的其他字母都替换成-。用于地址和域名名称。
CI_PROJECT_URL	8.10	0.5	项目的访问地址（http形式）
CI_REGISTRY	8.10	0.5	如果启用了Container Registry，则返回GitLab的Container Registry的地址
CI_REGISTRY_IMAGE	8.10	0.5	如果为项目启用了Container Registry，它将返回与特定项目相关联的注册表的地址
CI_REGISTRY_PASSWORD	9.0	all	用于push containers到GitLab的Container Registry的密码
CI_REGISTRY_USER	9.0	all	用于push containers到GItLab的Container Registry的用户名
CI_SERVER	all	all	标记该job是在CI环境中执行
CI_SERVER_NAME	all	all	用于协调job的CI服务器名称
CI_SERVER_REVISION	all	all	用于调度job的GitLab修订版
CI_SERVER_VERSION	all	all	用于调度job的GItLab版本
ARTIFACT_DOWNLOAD_ATTEMPTS	8.15	1.9	尝试运行下载artifacts的job的次数
GET_SOURCES_ATTEMPTS	8.15	1.9	尝试运行获取源的job次数
GITLAB_CI	all	all	用于指示该job是在GItLab CI环境中运行
GITLAB_USER_ID	8.12	all	开启该job的用户ID
GITLAB_USER_EMAIL	8.12	all	开启该job的用户邮箱
RESTORE_CACHE_ATTEMPTS	8.15	1.9	尝试运行存储缓存的job的次数