0. 前言

Gitlab从8.0开始，已经整合了一个CI工具（ GitLab Continuous Integration）并且是默认enable的。也就是说只要你所使用的gitlab版本>=8.0，那么你里边的所以项目都可以使用GitLab CI。

引入了GitLab CI后的工作流程如下：

CI workflow

我们修改代码后提交到GitLab服务器，如果当前项目是已经配置了GitLab CI,GitLab就会根据你的配置（Part 1），把当前项目丢给GitLab CI(Part 1)处理，GitLab Ci根据设定好的任务(Part 3)一步步执行（CI PIPELINE)。

1. GitLab CI

1.1 GitLab CI包含两个模块：Gitlab-ci和GitLab-Runner

• Gitlab-ci
  GitLab-CI就是一套配合GitLab使用的持续集成系统（当然，还有其它的持续集成系统，同样可以配合GitLab使用，比如Jenkins）8.0后，它是Gitlab Server的一部分（也就是说你装了Gitlab server就已经装了Gitlab-ci)。 Gitlab-CI相当于任务的管理者，负责任务检查、调度
• GitLab-Runner
  那GitLab-Runner又是干嘛的呢？上面说了，Gitlab-CI只负任务的管理（只负责指挥的包工头），它不负责任务的具体执行。GitLab-Runner则是任务的执行者，负责运行具体的任务（干力气活的打工仔）。Runner可以跟Gitlab-ci运行在同一台机器上，也可以运行在不同的机器上。Runner可以运行在一台虚拟机，一台VPS,一个Docker容器，或者一个容器集群。

一个工程如果要使用GitLab CI, 那么它就要定义一个软件集成脚本（.gitlab-ci.yml, 后面会说到）用来自动化的执行一些集成工作，例如打包、运行测试单元等等。当这个工程的仓库代码发生变动时，比如有人push了代码，GitLab就会将这个变动通知GitLab-CI。这时GitLab-CI会找出与这个工程相关联的Runner，并通知这些Runner把代码更新到Runner本地并执行预定义好的执行脚本。如下图所示：

引入GitLab-ci和Gitlab-Runner的workflow

1.2 GitLab-ci的配置

展开项目的Setting项，会有个CI/CD子项：

gitlab-ci设置

选中这CI/CD项后，右边会有4个配置章节：

• General pipelines settings
  pipelines的一些基本配置，例如超时时间、配置脚本路径（默认是.gitlab-ci.yml)。这里基本不用配，保持默认就好。

• Runners settings
  这里包含两部分：注册关联Runner时需要用的信息以及已经关联的Runner的状态信息

  
  Runner setting
  

  这URL和registration token 等会注册Runner时会用到
  最底下的是已注册的Runner列表以及它们的状态。左边的圆点绿色代表activity，红色则代表paused
  右边的则可以用来暂停或者删除该Runner

• Secret variables
  配置Runner的环境变量。当Gitlab-ci调用Runner运行任务时，会把这里配的变量export到Runner的环境变量里边。一些私密的东西就可以配置到这里，例如，我这项目希望ci build完后自动发包到我的maven服务器上，那么我在项目的build.gradle中配好maven 仓库如下：

build.gradle中的maven-publish配置

我当然不希望我的maven用户信息暴露在gitlab项目代码里边，但提交maven又必须要这信息，那么可以通过环境变量的方式来获取这信息。那这MAVEN_USER和MAVEN_PASSWD就可以配置在Secret variable里边。

• Pipeline triggers
  用来配置CI的触发器，默认是提交就自动触发。

2. Runner的安装和配置

• 安装Runner
  安装过程基本就按照官方教程一步步来（https://docs.gitlab.com/runner/install/linux-manually.html）
  (我是安装在Debian VM上)

sudo wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64
sudo chmod +x /usr/local/bin/gitlab-runner
sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash
sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
sudo gitlab-runner start

• 配置Runner
  配置过程也是按官方文档一步步来，官方文档基本都是手把手一步步的教你了（https://docs.gitlab.com/runner/register/index.html）
  在这配置过程中需要用到两个东西：gitlab-ci coordinator URL和gitlab-ci token
  这两个东西哪里拿呢？这两项就是刚才上面Runners Setting里边说到的URL和registration token
  另外，注册过程中它会要求你选择一个Runner executor,因为我的Runner是运行在我的虚拟机里边，所以选择shell。如果你的是运行在docker里边，那你就输入docker就可以了。

 Please enter the executor: ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell:
 shell

• 项目运行环境的安装配置
  因为这CI的任务是在Runner里边执行的，当满足触发条件后Runner就会把代码同步到当前环境下并执行（例如编译、单元测试）。因此我们还要在这Runner所在的机器上配置安装好自动集成所需的环境。
  由于我这CI是用来自动打包和发布Android 项目的，因此我需要在这Runner所在的VM上安装配置好Android SDK

aucean@debian:~$ wget https://dl.google.com/android/repository/sdk-tools-linux-4333796.zip
aucean@debian:~$ cd /opt
aucean@debian:/opt$ sudo mkdir android-sdk
aucean@debian:/opt$ sudo chown aucean android-sdk
aucean@debian:/opt$ cd android-sdk
aucean@debian:/opt/android-sdk$ unzip ~/sdk-tools-linux-4333796.zip
aucean@debian:/opt/android-sdk$ echo y | ./tools/bin/sdkmanager "platforms;android-27"
aucean@debian:/opt/android-sdk$ echo y | ./tools/bin/sdkmanager "platforms;android-28" 
aucean@debian:/opt/android-sdk$ echo y | ./tools/bin/sdkmanager "platform-tools"
aucean@debian:/opt/android-sdk$ echo y | ./tools/bin/sdkmanager "build-tools;29.0.0"
aucean@debian:/opt/android-sdk$ echo y | ./tools/bin/sdkmanager "build-tools;27.0.3"
aucean@debian:/opt/android-sdk$ yes | ./tools/bin/sdkmanager --licenses
aucean@debian:/opt/android-sdk$ sudo apt-get install openjdk-8-jdk

把下面两行添加到/etc/profile里边
export ANDROID_HOME=/opt/android-sdk
export PATH=$PATH:$ANDROID_HOME/tools:$ANDROID_HOME/platform-tools:$ANDROID_HOME/tools/bin

3. 编写自动集成脚本

经过上面的配置，前期准备基本已经做好，现在可以开始配置自动集成脚本了。
在项目的跟目录下添加、编辑集成脚本文件（默认是.gitlab-ci.yml如果用其他文件名，则要在上面说到的General pipelines settings里边配置一下）。所有自动集成任务都是通过这脚本文件来设定

auceanliangs-iMac:TestActivity aucean.liang$ cat .gitlab-ci.yml 
before_script:
  - chmod +x ./gradlew
stages:
  - build

assembleDebug:
  stage: build
  tags:
    - component
  script:
    - ./gradlew :androidlib:assembleRelease
    - ./gradlew :androidlib:publishReleasePublicationToMavenRepository
auceanliangs-iMac:TestActivity aucean.liang$ 

关于这yml文件的详细写法可以参考：
https://about.gitlab.com/2018/10/24/setting-up-gitlab-ci-for-android-projects/
http://gitlab.futunn.com/help/ci/yaml/README.md

编辑完这yml文件后，commit & push到gitlab。然后回到Gitlab中的Projects面板，选中CI/CD项目的piplines

CI piplines

这时候应该就可以看到你的Runner当前执行任务的状态了，如下：

push后ci正在running

需要注意的是，如果.gitlab-ci.yml脚本没有指定tags（参考上面的.gitlab-ci.yml）或这指定tags不对的时候会出现如下情况：

image.png

当前任务被“stuck"（卡住）了
可能有人又会问：这tags是什么鬼？我去哪里找到它？
回想下上面运行gitlab-runner register时，是不是有要求你输入一个tags

Please enter the gitlab-ci tags for this runner (comma separated):
component

没错，就是这个tags。
你也可以回到你Gitlab项目的Runners Setting中展开查看

查看tags

那它为何一定要加这tags呢？
你可以点下你的Runner（Runners activated for this project下的那一串数字，我这里是e9b6d0d4)。点了后，进入它的详细配置，可以看到有一项“Can run untagged jobs”被设为了No （默认设置是No)
你可以点上图中的编辑按钮（黑色锁图标旁边那个）来修改它。

编辑yml添加了tags并重新提交后，应该可以看到当前当前任务为running状态了。点击这running，可以进入到当前pipeline的详情里，看到当前正执行哪个任务（我这里正在执行assembleDebug)、有哪些任务正在等待执行等等。

pipeline详情

点击这正在执行的任务，还能看到当前Runner console的输出：

Runner console 输出

参考资料

https://about.gitlab.com/2018/10/24/setting-up-gitlab-ci-for-android-projects/
http://gitlab.futunn.com/help/ci/README.md
http://gitlab.futunn.com/help/ci/quick_start/README.md#configuring-a-runner