gitlab-ci 持续集成配置（二）yml配置

按照之前的步骤注册好之后，我们就需要开始配置ci流程了。

gitlab-runner具体执行的功能和执行顺序，是按照项目根目录中.gitlab-ci.yml文件的内容进行的。配置好这个文件的内容才能实现持续集成。

一般来讲主要包括检查、编译、测试等等任务。
下面是一个简单的例子：

variables:
    GIT_DEPTH: 1

stages:
    - build
    - test
    - deploy

before_script:
    - source toolchains
    - cp -r /dependecies ./

build_project:
    stage: build
    script:
        - ./build_project.sh

analysis:
    stage: test
    script:
        - ./do_analysis.py
    artifacts:
        name: "$CI_JOB_NAME-$CI_COMMIT_REF_NAME"
        paths:
            - path_of_reports
        expire_in: 1 week
        when: on_failure

unit_test:
    stage: test
    script:
        - ./do_unit_test.py

check_memory:
    stage: test
    script:
        - ./do_check_memory.py
    only:
        - master

pages:
    stage: deploy
    dependencies:
        - static_code_analysis
    script:
        - mkdir -p public
        - if [ -f "path_of_reports/result.txt" ]; then mv path_of_reports/result.txt ./public/; fi
        - echo "report will be published on http://gitlab.xxxx.com"
    artifacts:
        name: "$CI_JOB_NAME-$CI_COMMIT_REF_NAME"
        paths:
            - public

release_package:
    stage: deploy
    script:
        - ./package.py
    when: manual

具体配置

上面的例子比较通用，下面我们详细说一下：
variables
用于添加变量，这些变量可以被后续的命令和脚本使用.
这里使用到GIT_DEPTH表示仓库拉取的深度，设置为 1表示只拉取分支最新的一个commit．当我们的项目开发时间比较久，相应的commit会比较多，仓库就会比较大，这样只拉取最新的一个commit会比较节省时间，也更节省空间。

stages
这里表示有两个流程，分别是build和test，即构建和测试．流程会按照顺序执行，先执行完build再执行test．而同一个stage中的job都是可以并行执行，并行执行job的数量可以在gitlabrunner的config文件中修改，这个后面会说道。

before_script
用来定义所有job之前运行的命令，这里具体是用于配置工具链的环境，可以用于解决项目的依赖问题．

build_project
这里列举了一个编译的job，实际可以根据需要添加不同系统和架构的编译job，用于检查是否编译成功．我们可以提前准备对应的编译脚本，如果只是简单的一行命令的话可以直接使用命令．
我们一般在linux x86_64环境进行开始，因此也基本在这个环境进行编译和运行测试，而忽略了其他在平台的测试．有些情况我们的修改可能在其他平台编译失败，这样就可以在merge之前及时检查出来．

接下来是几个检查相关的job

analysis
这里进行静态代码分析，与使用cpplint进行代码风格上的检查是不一样的。这里主要进行代码规范的检查。不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。例如：对空指针解引用、变量未初始化、数据类型的隐式转化等等。静态检测工具种类有多种，例如cppcheck，pc-lint，qac++等。

artifacts
用于保存一些文件，也可以用于job之间传递数据。这里do_static_code_analysis.py脚本执行检查之后会生成一些报告，保存在path_of_reports中。这样可以在gitlab页面上进行浏览和下载。例如下图点击Browse就可以查看内容。

name 这里是为保存的文件压缩包命名，"$CI_JOB_NAME"表示job名字，"$CI_COMMIT_REF_NAME"表示分支名字。
paths 表示保存的路径。
expire_in 保存的期限，超过这个时间之后文件会被自动清除。

unit_test
用于进行代码进行单元测试。单元测试的工具有gtest，vectorcast等。

check_memory
用于对编译好的程序进行内存检查。目前使用到工具是valgrind。
only表示这个job只在master分支进行，由于memory检查测试一次耗时比较长，也不用每次提交代码都进行测试，所以这里选择只在master分支进行。
对应的还可以使用except，表示这个job在除了develop分支之外的其他分支进行。

pages
可以将一些结果内容上传到gilab上，就可以通过网页的来查看各种结果。
它要求把结果都放在一个叫public/的文件夹下，并且定义artifacts的上传路径为public。可以自己编写一个index.html把各个job的结果进行组织，方便浏览。

release_package
最后这里是一个打包任务。
manual表示需要手动进行，在gitlab服务器上点击对应的按钮就可以执行。如下图右边的小三角按钮。

gitlab提供检查工具对配置文件进行检查，在提交之前最好检查一下。下图的CI Lint按钮。

小结

到目前为止我们已经配置好了一个比较通用的测试流程。其实还可以加上一起其他的功能，例如精度评测、各平台资源占用测试、api文档生成等等功能，最后完成打包。

在推送配置好的分支到gitlab服务器前，我们需要先配置代码权限。这个时候可以发现，在注册runner的服务器或者pc的home目录下多出了一个gitlab-runner用户，可以理解为这个“用户”自动的拉取你提交到gitlab服务器的最新代码，然后按照你设计的流程自动执行任务。因此我们需要将这个用户的ssh-key添加到我们的gitlab服务器上。这个时候再推送分支到gitlab服务器就会自动出发ci了。

下面将介绍gitlab-runner的一些配置。