在项目开发的过程中，为了保证代码质量，我们会使用诸多代码质量检测工具，这些工具或是在本地，或是在云端，虽然工具可以检测出异常问题，但是这些问题还是需要我们程序员来修复，如果我们不强制所有人必须修复异常问题，某些人可能就会跳过异常检测，将代码合入主干。为了解决这个问题，我们需要强制门禁系统，所谓门禁就是通过检测的才能合入，不通过检测的不能合入。GitLab本身就为我们提供了这样的设置，我们只需要配置检测规则就可以了。

开启代码合入门禁

在项目设置中，配置只允许流水线成功的合并请求

GitLab Runner

要实现流水线的执行，当然需要有执行进程和环境了。GitLab为我们提供了CI工具-GitLab Runner，通过配置GitLab Runner，将环境注册到GitLab上，提交代码的时候，GitLab才能使用执行环境来跑我们的检测功能。

下载安装

虽然也可以通过docker进行安装，但是GitLab Runner只是一个二进制文件，下载后直接就可以在机器上运行，而且使用docker部署的话，执行命令也是在docker中，如果需要一些其他的环境配置，也必须在docker中安装，这是比较麻烦的。

https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64

# 拷贝下载的文件到 /usr/local/bin 目录下
mv gitlab-runner-linux-amd64 /usr/bin/gitlab-runner

# 增加执行权限
chmod +x gitlab-runner

# 安装生成配置
gitlab-runner install --user=root --working-directory=/data/gitlab-runner

# 启动服务
gitlab-runner start

注册服务到GitLab

安装以后我们需要把GitLab Runner注册到GitLab上，我们可以选择共享Runner和指定Runner的方式。共享Runner就是我们使用管理员账号获取的全局注册信息，注册后此Runner可以给所有代码库使用；指定Runner是给每一个仓库配置的特定Runner，只能跑本仓库的流水线。我建议大家注册成共享Runner，因为共享Runner也可以设置为多个代码库的Runner，这样比较方便。

• 使用管理员账号登录Git Lab后台

• 注册共享Runner

gitlab-runner register

url和token就是上图中展示的，描述和tag自己随便输入，tag要记住，后面要使用的

• 查看Runner注册是否成功

• 启动Runner服务

# 这个是前台运行的命令，需要使用nohup转为后端运行
# 也有人说通过sudo注册的gitlab-runner直接就是后台运行
gitlab-runner run

测试GitLab流水线

• 创建.gitlab-ci.yml

在项目根目录创建 .gitlab-ci.yml 文件，内容可做如下配置：

stages:
  - sonarcheck

sonarcheck:
  stage: sonarcheck
  script:
    - echo $CI_PROJECT_DIR
    - cd $CI_PROJECT_DIR
    - sonar-scanner
  tags:
    - sonar

stages：指定流水线所有步骤

script：当前步骤的执行命令

$CI_PROJECT_DIR：默认环境变量，本次流水线执行时下载的代码目录

tags：使用的runner

如果想要查看所有内置的环境变量，可以做如下配置

script:
  - export  // linux下使用此命令
  - 'dir env:'  // Windows使用此命令

提交代码后，就会看见流水线自动执行

对接sonarqube

gitlab流水线配置好以后，我们就可以对接sonarqube来实现代码上库门禁了

搭建sonarqube环境

请参考我们的上一篇文章：搭建 sonarqube 代码质量扫描环境

配置门禁关联

这一块我耗费了很长时间，在网上也没找到相应的教程，在最终要放弃之前，终于搞定了。本来我的想法是每个人在向主干提交MR的时候，启动流水线，如果流水线通过就运行合入，如果流水线不通过就不能合入。基于这种想法我搞了很久都没有实现，最后才搞明白，GitLab里面配置的“只允许合并流水线成功的合并请求”意思是在合并请求当中，如果流水线是成功的就允许。这里并不是在提交MR的时候才去跑流水线，而是跑完流水线以后，在提交MR，此时GitLab会获取本次合入所对应的流水线状态，如果状态是成功，那么就允许合入，如果不成功就不允许合入。因此我最后配置为每次提交都跑一次流水线任务，这样在合入的时候就能正确地拿到状态，并阻止不成功的合入。

配置流水线任务

在项目根目录创建.gitlab-ci.yml文件，这样GitLab就会在提交的时候自动检测此文件的配置，按照配置跑任务。对于文件的配置方式这里不做详细的描述，网上有很多类似的文章，而且我们一般使用的都比较简单，主要逻辑都是在script里面取实现的。

stages:
  - sonarcheck
  - checkresult

variables:
  access_token: xxxx
  secret: xxxx
  check_path: /data/xxxx/sonardata
  project: xxxx

sonarcheck:
  stage: sonarcheck
  script:
    - echo $CI_PROJECT_DIR
    - cd $CI_PROJECT_DIR
    - sonar-scanner
  tags:
    - sonar

checkresult:
  stage: checkresult
  script:
    - cd $check_path
    - python3 sonar.py $project $access_token $secret
  tags:
    - sonar

• stages：配置执行阶段，如果不配置的话，会有默认的几个阶段。
• variables：配置变量。
• sonarcheck/checkresult：这是属于任务名，可以随便起，我这里使用和阶段相同的名称。
• stage：用来指定当前任务对应的是哪个阶段。
• script：任务执行命令。
• tags：当前任务需要跑到哪个Runner上，这里配置的是Runner的标签。
• only：配置执行分支、条件等，如果不配置那么所有分支提交时都会跑任务
• $CI_PROJECT_DIR：本次任务所下载的代码路径，这个是环境变量，可以使用上面介绍的方式答应所有的

结果检测脚本

因为我们使用的sonarqube进行代码质量检测，Runner执行的sonar-scanner 只是把sonarqube扫描命令调起来，成功或者失败结果是不会收到的，因此即使sonarqube检测的代码有问题，流水线也不会报失败，所以需要我们自己写代码来检测sonarqube是否检测到异常，如果有异常就抛出错误。

import os
import sys
from sonarqube import SonarQubeClient
from dingtalkchatbot.chatbot import DingtalkChatbot, CardItem, ActionCard

# 获取sonarqube检测结果
def getSonarqubeInfo(branch="master", component=None, url=None, username=None, password=None):
    sonar = SonarQubeClient(sonarqube_url=url)
    sonar.auth.authenticate_user(login=username, username=username, password=password)
    component_data = sonar.measures.get_component_with_specified_measures(
        component=component,
        branch=branch,
        fields="metrics,periods",
        # metricKeys="""
        # code_smells,bugs,coverage,duplicated_lines_density,ncloc,
        # security_rating,reliability_rating,vulnerabilities,comment_lines_density,
        # ncloc_language_distribution,alert_status,sqale_rating
        # """
        metricKeys="code_smells,bugs,vulnerabilities"
    )
    result_dict = {}
    for info_dict in component_data["component"]["measures"]:
        result_dict[info_dict["metric"]] = info_dict["value"]
    return result_dict

# 发送钉钉消息，通知本次异常结果
def send_dingding_msg(access_token, secret, result_dict, project, url):
    webhook = f'https://oapi.dingtalk.com/robot/send?access_token={access_token}'
    chatbot = DingtalkChatbot(webhook, secret=secret)

    btns = [CardItem(title="查看详情", url=f"{url}/project/issues?id={project}&resolved=false")]
    actioncard = ActionCard(title='亲，本次修改有问题哦！！！',
                             text=f'代码检测结果如下：\n\nBug：{result_dict["bugs"]}\n\n漏洞：{result_dict["vulnerabilities"]}\n\n异味：{result_dict["code_smells"]}',
                             btns=btns,
                             btn_orientation=1,
                             hide_avatar=1)
    chatbot.send_action_card(actioncard)


if __name__ == '__main__':
    url = "http://192.168.1.123:9000"
    username = "admin"
    password = "123456"
    branch = 'master'
    project = sys.argv[1]
    access_token = sys.argv[2]
    secret = sys.argv[3]
    sonarqube_data = getSonarqubeInfo(branch=branch, component=project, url=url, username=username, password=password)
    if (sonarqube_data['bugs'] != 0) or (sonarqube_data['vulnerabilities'] != 0) or (sonarqube_data['code_smells'] != 0):
        print('代码检测异常：', sonarqube_data)
        send_dingding_msg(access_token=access_token, secret=secret, result_dict=sonarqube_data, project=project, url=url)
        sys.exit(1)
    else:
        print('本次提交非常完美！Perfect')

写好脚本后，我们将它放到执行机器上，是否上库根据个人需求，我们的目的是在sonarqube执行完后，跑这个脚本来执行。

测试门禁效果

我使用的门禁配置如下：

stages:
  - sonarcheck
  - checkresult
  - build
  - deploy

variables:
  access_token: xxxxx
  secret: xxxxx
  check_path: /data/xxxxx/sonardata
  project: xxxxx
  deploy_path: /data/xxxxx/frontend

sonarcheck:
  stage: sonarcheck
  script:
    - echo $CI_PROJECT_DIR
    - cd $CI_PROJECT_DIR
    - sonar-scanner
  tags:
    - sonar
  except:
    - master

checkresult:
  stage: checkresult
  script:
    - cd $check_path
    - python3 sonar.py $project $access_token $secret
  tags:
    - sonar
  except:
    - master

build:
  stage: build
  script:
    - cd $CI_PROJECT_DIR
    - yarn
    - yarn build
  tags:
    - sonar
  only:
    - master
  cache:
    paths:
      - dist/

deploy:
  stage: deploy
  script:
    - rm -rf $deploy_path/*
    - cd $CI_PROJECT_DIR
    - cp -r $CI_PROJECT_DIR/dist/* $deploy_path
  tags:
    - sonar
  only:
    - master
  dependencies:
    - build
  cache:
    paths:
      - dist/
    policy: pull

总共有四个执行阶段：

• sonarcheck

在非master分支下，执行sonar-scanner检查

• checkresult

在非master分支下，执行sonar.py脚本获取sonarqube检测结果

• build

在master分支下，执行前端打包，然后将dist目录缓存下来

• deploy

在master分支下，build任务执行成功后才能执行，将上一步缓存的内容下载到dist/目录，清空前端部署目录，再将打包好的dist目录中文件拷贝到前端部署目录下。

提交代码启动流水线任务

当我们提交代码时，会触发流水线任务

点击流水线任务，可以看到执行阶段

如果要查看具体的执行日志，可以点击具体阶段进行查看

当执行完以后，可以提交合入请求

提交合入请求

可以看到合入请求中会显示流水线任务状态，当流水线任务还未执行完成时，会看到如下界面

等流水线执行完成后，显示如下界面：

如果流水线执行失败，合并按钮不可点击，这样就保证了每次合入都必须通过检查。因为我们配置了master分支打包部署，因此当合并代码后，会自动启动打包部署流水线。

执行打包部署

总结

在配置的过程中，有一些需要了解的问题，Runner的配置和CI文件的配置。在CI文件的配置中需要注意缓存的处理，默认情况下每一个阶段的执行都会清理环境到最干净的状态，也就是生成的所有中间文件或者修改文件都会在下一阶段执行前恢复成与Git仓库同步的状态。针对这种情况，CI为我们提供了缓存机制，缓存分为本地缓存和服务器缓存，服务器缓存主要是为了解决分布式流水线执行，一般采用本地缓存就可以了。本地缓存会在本地生成一个cache目录，我们想要缓存某个阶段的文件或者目录，就在某个阶段配置cache，当然也可以在全局进行配置，这样缓存就是对每个阶段都生效的。我们在示例中只配置了缓存路径path，这样所有的流水线都会缓存到一个目录中，如果需要每个分支缓存到不同文件，那么就需要增加key的配置，除了配置key以外，还有缓存策略配置，默认的策略是下载/上传，但是在有些任务中，我们只需要使用上一阶段的缓存文件即可，因此我们可以配置为pull策略，这样就只会下载上一步的缓存文件，不会继续上传到缓存地址。

搭建 sonarqube 代码质量扫描环境