Gitlab CI 持续集成爬坑记(2019-3-13最新)

阅读量

之前因为做了一套基于fastlane的自动化打包措施，该方案需要我们通过手动操作命令行，可以说基于之前的手动打包已经非常方便了。可是万事不能仅仅于此，对于公司来说，多个项目的情况下，版本变动又比较频繁，后期如何能通过在gitlab中打个tag，或者提交一段代码，或者发个邮件等等操作，即可立即响应打包等一系列操作呢。在这里引入了Gitlab CI相关操作，研究了几天后解决了问题，在这里记录一下。

1. 简介

从 GitLab 8.0 开始，GitLab CI 就已经集成在 GitLab 中，可以把GitLab CI 理解为一个集成的服务器，它里面可以执行很多自动化操作，就跟Jenkins一样，如果我们使用Jenkins的话，就需要我们自己搭建Jenkins服务器，然后做各种自动化操作。我们只要在项目中添加一个 .gitlab-ci.yml 文件，然后添加一个 Runner，即可进行持续集成。 而且随着 GitLab 的升级，GitLab CI 变得越来越强大，本文将介绍如何使用 GitLab CI 进行持续集成，以及结合fastlane自动打包过程中碰到的坑点。

2. 一些概念

  • Pipeline

    一次 Pipeline 其实相当于一次构建任务，里面可以包含多个流程，如安装依赖、运行测试、编译、部署测试服务器、部署生产服务器等流程。

    任何提交或者 Merge Request 的合并都可以触发 Pipeline

  • Stages

    Stages 表示构建阶段，说白了就是上面提到的流程。

    我们可以在一次 Pipeline 中定义多个 Stages，这些 Stages 会有以下特点：

    • 所有 Stages 会按照顺序运行，即当一个 Stage 完成后，下一个 Stage 才会开始
    • 只有当所有 Stages 完成后，该构建任务 (Pipeline) 才会成功
    • 如果任何一个 Stage 失败，那么后面的 Stages 不会执行，该构建任务 (Pipeline) 失败

  • Jobs

    Jobs 表示构建工作，表示某个 Stage 里面执行的工作。

    我们可以在 Stages 里面定义多个 Jobs，这些 Jobs 会有以下特点：

    • 相同 Stage 中的 Jobs 会并行执行
    • 相同 Stage 中的 Jobs 都执行成功时，该 Stage 才会成功
    • 如果任何一个 Job 失败，那么该 Stage 失败，即该构建任务 (Pipeline) 失败

3. GitLab Runner

  • 简介

    理解了上面的基本概念之后，有没有觉得少了些什么东西 —— 由谁来执行这些构建任务呢？
    答案就是 GitLab Runner 了！

    想问为什么不是 GitLab CI 来运行那些构建任务？

    一般来说，构建任务都会占用很多的系统资源 (譬如编译代码)，而 GitLab CI 又是 GitLab 的一部分，如果由 GitLab CI 来运行构建任务的话，在执行构建任务的时候，GitLab 的性能会大幅下降。

    GitLab CI 最大的作用是管理各个项目的构建状态，因此，运行构建任务这种浪费资源的事情就交给 GitLab Runner 来做

    因为 GitLab Runner 可以安装到不同的机器上，所以在构建任务运行期间并不会影响到 GitLab 的性能。

  • 安装

    安装 GitLab Runner 太简单了

    1
    2
    # For CentOS
    curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh | sudo bash

    其他平台安装可以参考官网地址

    1
    2
    3
    4
    安装runner

    # For RHEL/CentOS/Fedora
    sudo yum install gitlab-runner

  • 注册 Runner

    安装好 GitLab Runner 之后，我们只要启动 Runner 然后和 CI 绑定就可以了：

    • 打开你 GitLab 中的项目页面，在项目设置中找到 runners，具体路径是Settings — CI/CD — Runners — 右侧展开按钮 — Setup a specific Runner manually
    • 运行 gitlab-runner register
    • 输入 CI URL （Specify the following URL during the Runner setup:后面对应的url）
    • 输入 Token （Use the following registration token during setup: 后面对应的token）
    • 输入 Runner 的名字 （不重要）
    • 是否输入tag标记 (因为我在这里是以本机作为服务地址的，这里的tag千万别输入东西，要不然后面运行总是卡住，找不到对应服务器，默认到Docker上了。直接回车即可)
    • 选择 Runner 的类型，输入 Shell

​ 当注册好 Runner 之后，可以用 gitlab-runner list 命令来查看各个 Runner 的状态

image.png

4. gitlab-ci.yml

  • 简介

    配置好 Runner 之后，我们要做的事情就是在项目根目录中添加 .gitlab-ci.yml 文件了。
    当我们添加了 .gitlab-ci.yml 文件后，每次提交代码或者合并 MR 都会自动运行构建任务了。

    还记得 Pipeline 是怎么触发的吗？Pipeline 也是通过提交代码或者合并 MR 来触发的！
    那么 Pipeline 和 .gitlab-ci.yml 有什么关系呢？
    其实 .gitlab-ci.yml 就是在定义 Pipeline 而已.

    image.png

先在对应分支下，创建.yml文件，我这里选择的是junjieCI分支

image.png

  • 基本写法

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    # 定义 stages
    stages:
      - build
      - test

    # 定义 job
    job1:
      stage: test
      script:
        - echo "I am job1"
        - echo "I am in test stage"

    # 定义 job
    job2:
      stage: build
      script:
        - echo "I am job2"
        - echo "I am in build stage"

    写起来很简单吧！用 stages 关键字来定义 Pipeline 中的各个构建阶段，然后用一些非关键字来定义 jobs。
    每个 job 中可以可以再用 stage 关键字来指定该 job 对应哪个 stage。

​ job 里面的 script 关键字是最关键的地方了，也是每个 job 中必须要包含的，它表示每个 job 要执行的命令。

​ 运行结果：

1
2
3
4
I am job2
I am in build stage
I am job1
I am in test stage

根据我们在 stages 中的定义，build 阶段要在 test 阶段之前运行，所以 stage:build 的 jobs 会先运行，之后才会运行 stage:test 的 jobs。

贴一个我自己写的.yml文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
# 定义 stages
stages:
  - build
  - test

# 定义 job1
job1:
  stage: test
  only:
    - develop
  script:
    - echo "I am job1"
    - echo "I am in test stage"

# 定义 job
job2:
  stage: build
  only:
    - junjieCI
  script:
    - echo "I am job2"
    - echo "I am in build stage"
    - cd ./govBaseApp
    - pod install
    - cd ../
    - bash ./bag.sh

我在这里用到了only关键字，我这边区分的是不同的分支，设置 Job.only 后，只有当 对应的分支有提交的时候才会触发相关的 Jobs。

我的项目层级如下：

image.png

先执行cd ./govBaseApp命令是因为gitlab ci执行操作的时候，从仓库中拉取新的代码到本地，但是仓库里的代码是没有podfile过的，所以需要先到工程目录里进行pod install一下。

另外Gitlab Runner执行fastlane的操作时候，可能会报错误

1
fastlane requires your locale to be set to UTF-8

这时候需要在本地文件夹下创建一个profile文件，内容是

1
export LANG=en_US.UTF-8

image.png

bag.sh是我自己写的一个自动打包的脚步文件，内容如下：

1
2
3
4
5
6
7
8
9
#!/bin/bash
echo "我是大帅哥啊啊啊啊啊，超有钱啊啊啊啊啊"
echo "计算机等级20级，神级操作完成双杀"
sleep 1
echo "即将打包了哦"
sleep 2
cd ./govBaseApp
fastlane TestBag
exit

自动打包可以参考我之前写的fastlane自动打包

5. 删除注册过的Gitlab-Runner

有可能一个项目我们注册了多个，需要删除之前的话，有两种方式

  • 第一种我们在设置的Runner里面进行删除，如下图

    image.png

这种删除是不彻底的，我们还要在终端中输入gitlab-runner list, 找到对应的config.toml文件路径，进行删除

image.png

  • 第二种方式直接在终端运行如下命令

    1
    gitlab-runner unregister --url urlxxx --token tokenxxx

    这里的urlxxx对应上图中的URL后的链接，tokenxxx对应上图中的Token后的字母数字组合

6. 查看Gitlab Runner运行过程

gitlab-ci.yml中的代码运行的工作台在哪查看呢，如下图：

image.png

点击对应红框里的，进去后，点击对应的jobs，再点击对应jobs里的构建任务即可查看了

image.png

工作台部分如下：

image.png

到此，Gitlab CI持续集成已初步完成。如果还想有更多的操作或更多的想法，建议多参考官方文档

赏

谢谢你请我吃糖果

支付宝
微信

扫一扫，分享到微信

微信分享二维码
本站总访问量次

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

<br><br>目前就职于比心陪练<br>iOS开发<br><br>能力一般，水平有限<br>待秋实果茂，与君共勉。