gitlab生成包 gitlab怎么打包

如何让gitlab管道停止并要求我输入变量进行个性化打包？

• 流程介绍
• 前言
• 一、 Gitlab-CI/CD使用场景
• 二、Gitlab CI yaml是什么？
• 三、如何编写.gitlab-ci.yml文件

• after_script
• stages
• variables
• build(job作业)
• 汇总：gitlab-ci.yml 基础代码脚本（全代码）

• 四.`*`如何让gitlab管道停止并要求我输入变量进行个性化打包?(打包多个镜像，选其一)
• 总结

---

流程介绍

• 介绍yaml和jenkins，引入gitlab-ci.yml
• yaml文件中关键字的术语解释
• 全代码展示
• 介绍 打包多个镜像时，如何实现与用户进行交互

前言

yml就是配置文件，不同地方用处不同。
（在这里用于gitlab-ci，根据yml配置，编写执行命令行，构建打包镜像流程。）

目前市面上常用的自动化部署的工具比较常见的是Jenkins，但是使用过程中，总会遇到各种奇奇怪怪的错误，很难定位问题所在（还光爱出小问题，越着急打包镜像越给你出问题╰（｀□′）╯）；

今天介绍的是gitlab中的CI/CD功能，Gitlab CI yaml进行阿里云镜像打包。个人觉得部署起来更加简单，有效，易排查，可视化界面也更加整洁～（两种都是运行dockerfile）

在涉及到有队列消费端的时候，jenkin可以用户选择打包哪一个的镜像包进行一个交互，那么转移到Gitlab CI yaml中，也可以有方式进行交互。

---

一、 Gitlab-CI/CD使用场景

公司使用Gitlab作为工作仓库进行代码发布及版本控制，Gitlab内置了CI/CD的工具，这些工具可以用于代码提交的同时完成镜像构建、自动化测试、自动化部署等连续的工作：

• CI: Continuous Integration（持续集成）
• CD: Continuous Delivery（连续交付）
• CD: Continuous Deployment（持续部署）

本篇所说的是CI持续集成部分做一些自动化工作。例如镜像打包，大大节约了时间成本。

二、Gitlab CI yaml是什么？

GitLab CI使用YAML文件(.gitlab-ci.yml)来管理项目配置。该文件存放于项目仓库的根目录，它定义该项目如何构建。

yml就是配置文件，不同地方用处不同。
（在这里用于gitlab-ci，根据yml配置，编写执行命令行，构建打包镜像流程。）

三、如何编写.gitlab-ci.yml文件

.gitlab-ci.yml文件中指定了CI的触发条件、工作内容、工作流程，编写和理解此文件是CI实战中最重要的一步，该文件指定的任务内容总体构成了1个pipeline、1个pipeline包含不同的stage执行阶段、每个stage包含不同的具体job工作脚本任务。首先先来认识一下关键字使用：

after_script

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

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

stages

stages的规范允许有灵活的多级pipelines，定义的元素的顺序决定了任务执行的顺序。例如：

stages:
- buildApi
- buildSvc

如图所示，gitlab流水线执行时，会产生两个相关作业：

buildApi任务成功后，buildSvc才会执行；所有的都成功了，提交将会标记为成功

任何一步任务失败了，提交标记为失败，并且下一个stages的jobs都不会执行。如图所示：

variables

GitLab CI允许你为.gitlab-ci.yml文件中添加变量，该变量会在job环境中起作用。这些变量是你存储在git仓库里，并且非敏感的项目配置，例如:

variables:
  # 阿里云镜像仓库地址
  ALI_REGISTRY : 'registry.cn-hangzhou.aliyuncs.com/XXX子页面'
  IMAGE_NAME : 'XXXXXX镜像名称'
  IMAGE_TAG : '默认develop分支镜像版本' 
  DOCKERFILE : 'dockerfile路径'
  GIT_DEPTH: 0

build(job作业)

以上都是声明的类似于全局变量，到这一步，里面的代码都是执行的主要代码，这里面需要将几个主要的关键字用法：

• image
  image：使用的docker镜像 （docker详情）
  services：使用的docker服务
  这两个关键字允许使用一个自定义的Docker镜像和一系列的服务，并且可以用于整个job作业周期。

build:
  image: docker:latest
  services:
    - docker:19.03.12-dind

• script
  script：是一段由Runner执行的shell脚本，可以包含多条命令。
  after_script：定义每个任务的脚本执行结束后所需执行的命令。
  before_script：定义每个任务的脚本启动前所需执行的命令，它必须是一个数组或者是多行字符串。

.gitlab-ci.yml文件所用之地，主要是以下三步：先登录个人版/企业版实例→执行docker语句（打包镜像,将镜像推送到Registry）→退出登陆

before_script:
    - "docker login registry.cn-hangzhou.aliyuncs.com -u 登陆账号 -p 登陆密码"
                    
 script:
    - echo default image is ${IMAGE_NAME} ${IMAGE_TAG}
    - echo at branch is ${CI_COMMIT_REF_SLUG}
    - 
       # 执行docker语句，镜像仓库基本信息中有此拉取推送代码，可自行调整
    - 'docker build -t ${IMAGE_NAME}:${IMAGE_TAG} -f ${DOCKERFILE} .'
    - 'docker tag ${IMAGE_NAME}:${IMAGE_TAG} ${ALI_REGISTRY}/${IMAGE_NAME}:${IMAGE_TAG}'
    - 'docker push ${ALI_REGISTRY}/${IMAGE_NAME}:${IMAGE_TAG}'
    - echo 'end'
  after_script:
    - 'docker logout registry.cn-hangzhou.aliyuncs.com'

echo：用于Git lab上执行作业时打印输出，方便在执行中，根据输出语句，快速定位问题。如图所示：

$ echo default image is ${IMAGE_NAME} ${IMAGE_TAG}

default image is msgcenter-web-service 2.1.2-snapshot (default image is 镜像名称 镜像版本 )

PS：有些时候，script命令需要被单引号或者双引号所包裹，当命令中包涵以下字符时需要注意打引号:`: { } [ ] , & * # ? | - < > = ! % @ ``

• 4.3 only
  only：定义了job作业需要执行的所在分支或者标签。
  例如：master在git提交代码时是不触发以上job作业的，而dev分支、tag标签则会触发并执行job作业。

only:
    - dev 
    - tag

PS:允许使用正则、允许使用指定仓库地址，但是不forks仓库

• 4.4 tags
  tags：定义一列tags，用来指定选择哪个Runner（同时Runner也要设置tags）

tags:
    - code1

这个是需要在Gitlab配置中进行配置的，否则会出现：一直都是等待中 或者 此作业已阻塞，因为您未分配任何具有这些标签的可用Runne… 之类的问题

汇总：gitlab-ci.yml 基础代码脚本（全代码）

# 全局脚本，会运行在各个阶段的script前，如果某个阶段里面存在before_script，那么以那个阶段里的为主
before_script:
- echo 'start'
# 定义CI执行的阶段，这里可以自己根据情况定义多少个阶段
stages:
- build

# 定义变量
variables:
  ALI_REGISTRY : 'registry.cn-hangzhou.aliyuncs.com/XXX子页面
  DOCKERFILE : 'Dockerfile'
  IMAGE_NAME : '镜像名称'
  # 默认develop分支镜像版本
  IMAGE_TAG : '2.1.2-snapshot'
  GIT_DEPTH: 0

# 构建镜像
build:
  image: docker:latest
  services:
    - docker:19.03.12-dind
  stage: build
  allow_failure: false
  only:
    - dev 
    - tag
  tags:
    - code1

  #登陆
  before_script:
    - "docker login registry.cn-hangzhou.aliyuncs.com -u 登陆账号 -p 登陆密码"
  #运行容器
  script:
    - echo default image is ${IMAGE_NAME} ${IMAGE_TAG}
    - 'docker build -t ${IMAGE_NAME}:${IMAGE_TAG} -f ${DOCKERFILE} .'
    - 'docker tag ${IMAGE_NAME}:${IMAGE_TAG} ${ALI_REGISTRY}/${IMAGE_NAME}:${IMAGE_TAG}'
    - 'docker push ${ALI_REGISTRY}/${IMAGE_NAME}:${IMAGE_TAG}
    - echo 'end'
  #退出登陆
  after_script:
    - 'docker logout registry.cn-hangzhou.aliyuncs.com'

四.*如何让gitlab管道停止并要求我输入变量进行个性化打包?(打包多个镜像，选其一)

Jenkins打包消费端相关的，可以与用户进行交互，选择打包服务还是打包消费端，如图所示：

那么gitlab-ci.yml中怎么实现与用户交互呢？我所使用的方法逻辑大致一下流程：
执行两个CI执行的阶段→可以与only一些变量一起使用，形成输入mq 打包消费端，输入service 打包服务。代码如图所示：

# job工作1 构建消费端
buildApi:
  ...
  script:
    ...

  only:
      refs:
        - dev 
        - tag
      variables:
        - $BUILD_API == "mq"
        - $BUILD_API == "" 

 
 # job工作2 构建服务
buildSvc:  
   ...
  script:
    ...

  only:
      refs:
        - dev 
        - tag
      variables:
        - $BUILD_API == "service"
        - $BUILD_API == ""

这需要在Git lab【设置】→ CI/CD→Variables下创建一个变量。
我的印象是，当我进入手动阶段deploy时，gitlab 应该暂停并要求我为该变量输入一个值，手动触发管道：

• 输入mq 打包消费端
• 输入service打包服务
• 什么都不输入 两个都打包

执行效果展示：

---

总结

1. 有了这样的东西，您可以拥有手动出发管道进行个性化执行作业，但前提是得在分支上手动启动新管道并将变量设置$BUILD_API 为 mq/service/不输入。
2. 其他相关配置也要在Gitlab的【设置】CI/CD中进行配置，设置好默认.gitlab-ci.yml文件的路径名字，在进行提交后会自动触发，执行作业为.gitlab-ci.yml的job。（管理员可配置）
3. 也可在群组或项目设置中可设置公共变量，以供.gitlab-ci.yml使用。
4. passed为执行通过，padding为在等待中，failed为执行失败，点击某个job可查看详细情况。
5. 相关microsoft/dotnet报错：可能是因为.NET Core 2.1 和 2.2 容器映像已从 Docker Hub 中删除。 他们于 2021 年 8 月 21 日将这些映像移到了 Microsoft 容器注册表 (MCR)。
   可使用mcr.microsoft.com/dotnet/sdk:2.1 来代替 microsoft/dotnet。