GitLab CI/CD使用

1.概述

1.1概念（摘抄于RetHat）

CI（Continuous Integration）指持续集成。

持续集成： 属于开发人员的自动化流程。成功的CI 意味着应用代码的新更改会定期构建、测试并合并到共享存储库中。该解决方案可以解决在一次开发中有太多应用分支，从而导致相互冲突的问题。

CD （Continuous Delivery/Continuous Deployment）指持续交付/持续部署。

A.持续交付： 通常是指开发人员对应用的更改会自动进行错误测试并上传到存储库（如 GitHub 或容器注册表），然后由运维团队将其部署到实时生产环境中。这旨在解决开发和运维团队之间可见性及沟通较差的问题。因此，持续交付的目的就是确保尽可能减少部署新代码时所需的工作量。
B.持续部署： 指的是自动将开发人员的更改从存储库发布到生产环境，以供客户使用。它主要为了解决因手动流程降低应用交付速度，从而使运维团队超负荷的问题。持续部署以持续交付的优势为根基，实现了管道后续阶段的自动化。

1.2说明

此篇文章主要用于记录自己使用GitLab CI/CD功能的过程，方便日后查看借鉴，后续如果还有使用这个功能的话，继续补充内容。
现阶段，自己使用GitLab CI/CD功能主要用于为开发的客户端软件自动打包，因此算是用了持续部署。

2.实际使用

2.1安装GitLab-Runner

在此链接页面找到自己系统对应的安装教程，按照教程一步一步执行，便可完成，下面主要介绍Windows平台的安装（GitLab官方文档----在Windows上安装GitLab-Runner）：
1. 在任意地方创建文件夹（文件夹需要有读写权限），比如：C:\GitLab-Runner。
2. 下载对应exe（64位程序，32位程序），将exe改名为gitlab-runner.exe，并且放到第1步创建的文件夹中。

改名只是为了简洁性，可以不改，但后续出现的gitlab-runner.exe的地方均需要改成你的exe名称。

2.2注册Runner

GitLab 可以注册三种Runner，分别是共享Runner、组Runner、项目Runner，因为自己只用过项目Runner，所以下面只介绍项目Runner的注册过程（GitLab官方文档----注册Runner）：
1. 在gitlab-runner.exe的存放目录下，以管理员身份运行PowerShell，运行以下脚本：

.\gitlab-runner.exe register

2. 执行第1步后，后续会让你填写关于Runner的几项信息，依次填写完，即完成Runner的注册。

各项参数如何填写：

• GitLab instance URL：项目CI的实例URL，使用项目CI配置（Settings-CI/CD-Runners-Set up a specific Runner manually）中的信息，为下图中的第1处信息。
• registration token：项目CI的实例token，使用项目CI配置（Settings-CI/CD-Runners-Set up a specific Runner manually）中的信息，为下图中的第2处信息。
• description：Runner描述，自定义。
• tags：Runner标签，主要用于过滤，可不填。
• executor：终端，一般选shell。
  
  Runner注册完成后的配置页面：
  
  可以在配置页面进行Runner信息维护（查看及修改）：
  
  

2.2启动及停止Runner

1.启动： 在gitlab-runner.exe的存放目录下，以管理员身份运行PowerShell，运行以下脚本：

.\gitlab-runner.exe start

2.停止： 在gitlab-runner.exe的存放目录下，以管理员身份运行PowerShell，运行以下脚本：

.\gitlab-runner.exe stop

2.3在项目中使用

1.在项目中增加.gitlab-ci.yml文件，.gitlab-ci.yml文件语法规则见GitLab官方文档----.gitlab-ci.yml参考手册。下面贴上自己项目中使用的.gitlab-ci.yml文件内容：

before_script:
  - chcp 65001

stages:
  - packing-full
  - upload-ftp-full
  - packing-addition
  - upload-ftp-addition

packing-full:
  stage: packing-full
  only:
    - /^Full-.*$/
  script:
    - "& $env:PYTHON_PATH -E scripts\\full_packing.py"
  artifacts:
    expire_in: 7d
    paths:
      - dist/*.exe
  tags:
    - windows
    - python
    - nsis
    - qt

upload-ftp-full:
  stage: upload-ftp-full
  only:
    - /^Test-Full-.*$/
  script:
    - "& $env:PYTHON_PATH -E scripts\\full_publish_ftp.py"
  tags:
    - windows
    - python
    - nsis
    - qt
  except:
    - branches

packing-addition:
  stage: packing-addition
  only:
    - /^Addition-.*$/
  script:
    - "& $env:PYTHON_PATH -E scripts\\addition_packing.py"
  artifacts:
    expire_in: 7d
    paths:
      - dist/*.zip
  tags:
    - windows
    - python
    - nsis
    - qt

upload-ftp-addition:
  stage: upload-ftp-addition
  only:
    - /^Test-Addition-.*$/
  script:
    - "& $env:PYTHON_PATH -E scripts\\addition_publish_ftp.py"
  tags:
    - windows
    - python
    - nsis
    - qt
  except:
    - branches

上面的ci文件主要实现自动打包及上传FTP的功能，打包兼容全量包与增量包，下面简略说明：

• 流水线： 流水线即整个文件体现的工作流程，包括定义变量、执行工作(job)等，一个流水线(pipeline)包含多个阶段(state)，一个阶段包含多个工作(job)。
• states关键字： 定义流水线包含的阶段及执行顺序，没有特殊定义的情况下，只有前一阶段的任务执行成功完毕后，后续阶段才会进行。
• state关键字： 定义工作(job)属于哪个阶段(state)。
• packing-full、upload-ftp-full、packing-addition、upload-ftp-addition： 定义了四个工作(job)。
• only关键字： 定义job何时执行，该文件中（/^Full-.*$/）用正则表达式定义在创建以Full开头的标签时执行。
• script关键字： 定义job如何执行，一般调用脚本文件实现。
• artifacts关键字： 定义job执行结果，即说明job执行完成后将哪些文件上传到GitLab上，保留多长时间等。
• tags关键字： 定义job运行的Runner Tag。

2. 根据定义的 .gitlab-ci.yml 主动触发流水线的创建，如（提交代码、合并分支、创建tag），上面的文件的触发条件就是创建特定的标签（Full-开头的标签创建打全量包的流水线、Test-Full-开头的标签创建打全量包并上传FTP的流水线、Addition-开头的标签创建打增量包的流水线、Test-Addition-开头的标签创建打增量包并上传FTP的流水线）。下面是流水线列表图示。

3.问题及解决方法

Q1. 在linux系统上注册的runner在项目的gitlab页面上的状态一直显示未运行？

在linux系统上调用命令sudo gitlab-runner restart。

Q2. 在linux系统上注册的runner即使显示运行中，但项目的gitlab页面上流水线一直显示是pending状态。

如果是以普通用户创建的runner，则调用gitlab-runner run命令。
如果是以超级用户方式创建的runner(即用了sudo gitlab-runner register)，则调用sudo gitlab-runner run命令。

4.总结

关于GitLab CI/CD功能，GitLab官方资料很详细，所以在实际使用过程中，前期可以通过一些博客做简单的认识与环境搭建，后续适配到自己项目，还是需要查阅 GitLab CI/CD官方文档。本文最大的用处是便于自身后续回顾复习。