整合Sonarqube对于确定大型代码库中的破坏变化和技术债务至关重要。自动化单元测试并设置Sonarqube作业以进行代码分析可以帮助解决此问题。但是，配置管道可能很困难，并且对于像我这样的新devops的人来说，可用的文档可能不会直观。本指南旨在协助开发人员在自己的机器上设置和测试CI/CD作业。一个案例示例是将代码覆盖范围报告与可以在本地测试的gitlab作业中集成到Sonarqube分析中。

1.安装Sonarqube

请访问here以获取直截了当的Sonarqube安装指南。企业通常有一个集中的声音仪表板，您可以连接到。但是，为了学习目的，我们将安装并运行在我们的机器上。

2.在项目根部设置声纳配置

转到项目的根源并创建一个新的sonar-project.properties文件。

# Project specification
sonar.projectKey=project-key-example
sonar.projectName=project-name-example
sonar.projectVersion=project-version-example

# Analysis specification
sonar.language=go
sonar.exclusions=**/mocks/**,**/vendor/**
sonar.qualitygate.wait=true

# Testing specification
sonar.go.coverage.reportPaths=./coverage.out
sonar.go.coverage.minimumCoverage=80
sonar.test.exclusions=**/*_test.go,**/mocks/**,**/vendor/**

项目规范对于确定您的项目以及将共享您的Sonarqube仪表板的其他项目规范。因此，请确保密钥是唯一的，并且名称是描述性的。

分析规范对于告诉声纳在运行分析中需要使用什么框架很重要。他们默认将分析的内容是：代码气味，代码重复和错误。默认情况下，除非我们将报告添加到本文结束时，否则将无法进行覆盖分析。

指定您在sonar-language中使用的语言，在这种情况下，我们将使用。排除不需要分析的文件夹，例如模拟文件或供应商文件，并在sonar.exclusions下指定。您也可以使用sonar.inclusions来指定需要分析的文件夹。但是，由于默认情况下，我们希望每个人都在仔细检查中进行审查，因此只有指定排除就足够了。 sonar.qualitygate.wait=true将告诉Sonarqube分析在完成分析之前等待质量门评估的完成。

质量门可能是另一个话题，但是简而言之，这是一组门槛，可以使您的代码有资格准备好生产。此阈值可能包括代码覆盖率的百分比，代码闻到的数量等。除非您要确保每个部署都准备就绪，否则等待此评估可能根本不需要。

接下来是指定测试。 sonar.go.coverage.reportPaths=./coverage.out告诉Sonar需要阅读覆盖范围报告，而sonar.go.coverage.minimumCoverage=80设定了最低覆盖范围的百分比。您还需要在sonar.test.exclusions下列出未经测试的文件，包括测试文件。

就是这样！我们完成了配置声纳文件的完成。

3.设置Gitlab CI工作

在您的项目中的现有.gitlab-ci.yml下找到这些阶段，或者如果不存在，则创建一个新阶段。

stages:
   - build
   - test
   - deploy

通常，CI有三个主要阶段：构建，测试和部署。但是现在，我们不仅想作为舞台的一部分进行测试，而且还要分析整个代码库。您可以在test之后添加新的analyze阶段，也可以将它们都放在一个阶段。就我而言，我更喜欢在analyze阶段将它们分组在一起。

stages:
   - build
   - analyze
   - deploy

接下来，我们将创建两个作业：unit-test和sonar-analysis。

unit-test:
  stage: analyze
  image: golang:1.18
  script:
    - go test -v -coverprofile=coverage.out -covermode=set ./...

sonar-analysis:
   stage: analyze
   image: sonarsource/sonar-scanner-cli:latest
   script:
     - sonar-scanner

看到这两个作业都属于同一analyze阶段，同时还可以在不同的Docker图像上运行，这将使每个作业都具有自己的依赖关系。以这种方式设置后，这两个作业都将同时运行，这将不允许我们将覆盖范围报告与声纳分析集成。相反，我们想要的是首先运行unit-test，生成覆盖范围报告，然后在报告的顶部运行总体代码分析。

为此，我们将添加artifacts.paths来保存我们生成的覆盖报告。然后，告诉sonar-analysis Job通过添加needs.job等待unit-test，然后下载并使用unit-test通过添加needs.artifacts生产的工件。

unit-test:
  stage: analyze
  image: golang:1.18
  script:
    - go test -v -coverprofile=coverage.out -covermode=set ./...
  artifacts:
     paths:
       - coverage.out

sonar-analysis:
   stage: analyze
   image: sonarsource/sonar-scanner-cli:latest
   script:
     - sonar-scanner
   needs:
     - job: unit-test
       artifacts: true

您也可以添加其他配置，例如allow_failure: true，因此任何故障都不会阻止舞台的其余部分。您还可以通过添加only来指定运行这些分支。

   ...
   allow_failure: true
   only: 
     - develop
     - master
  ...

也要注意的是一个重要的事情，此示例并不能涵盖所有内容。例如，您必须将sonar-analysis连接到您的Sonarqube仪表板中，我们在本文中不介绍。

4.在当地环境中测试Gitlab CI工作

测试.gitlab-ci.yml更改是较棘手的部分，因为它在gitlab runner上运行，无法使用常规Docker命令进行测试。为了做到这一点，我们需要在计算机上安装GitLab Runner，然后在其顶部测试.gitlab-ci.yml文件。

GitLab Runner安装

安装Gitlab Runner here，或从linux repository

设置Gitlab Runner

• 确保通过运行gitlab-runner help成功安装成功
• 注册gitlab-runner

sudo gitlab-runner register

您将被提示输入gitlab实例URL和令牌，可以在CI/CD Mennu下找到您的存储库的Settings。扩展Runners部分并在Specific runners下找到令牌

• 输入跑步者描述和标签
• 选择执行人，我们将使用Docker进行我们的项目。 See here其他选项
• 有关详细说明，see here

运行测试

成功设置Runner后，您可以启动服务，然后转到项目的根目录。要测试一项特定的工作，您可以运行

gitlab-runner exec docker job_name

这样做以测试整个管道

gitlab-runner run

如果未检测到您的gitlab-ci.yml，则可以添加配置标志以指定文件的位置

gitlab-runner run --config /path/to/project/.gitlab-ci.yml

就是这样！您现在应该能够在计算机上执行Gitlab CI并查看Sonarqube分析实时运行。

abioqian12 on freepik