SonarQube is a great tool for code quality and security checks. It is one of the tools we use to ensure quality of our products is measured and improved over time.

We also use GitLab – code management and CI/CD tool on some of our projects. SonarQube code analysis is integrated as a step in our GitLab CI pipelines.

For a long time I had a custom-built docker image for those purposes, automatically built and published to GitLab Container Registry.

Although quite automated, this custom-build docker image was adding to maintenance of the pipelines. I was happy to see that SonarSource has recently published official SonarScanner CLI docker image, and announced a support for GitLab integration in v8

GitHub logo SonarSource / sonar-scanner-cli-docker

Docker image for SonarScanner CLI

The docker image expects code being mounted on $PWD, which is set to /usr/src. This is different to where GitLab is mounting sources directory by default.

To make it all work the following environment variable needs to be set:

sonar:
  image: sonarsource/sonar-scanner-cli
  script:
    - sonar-scanner -Dsonar.qualitygate.wait=true
  allow_failure: true
  variables:
    SONAR_PROJECT_BASE_DIR: "${CI_PROJECT_DIR}"

Environment variable SONAR_PROJECT_BASE_DIR overrides default behavior. Predefined GitLab environment variable CI_PROJECT_DIR refers to the location where GitLab is mounting project source code.

Without this variable set the following misleading error will appear in GitLab log:

ERROR: Error during SonarScanner execution
java.lang.IllegalStateException: Unable to create user cache: /usr/src/.sonar/cache
    at org.sonarsource.scanner.api.internal.cache.FileCache.createDir(FileCache.java:147)
    at org.sonarsource.scanner.api.internal.cache.FileCache.<init>(FileCache.java:46)
    at org.sonarsource.scanner.api.internal.cache.FileCache.create(FileCache.java:52)
    at org.sonarsource.scanner.api.internal.cache.FileCacheBuilder.build(FileCacheBuilder.java:48)
    at org.sonarsource.scanner.api.internal.JarDownloaderFactory.create(JarDownloaderFactory.java:42)
    at org.sonarsource.scanner.api.internal.IsolatedLauncherFactory.createLauncher(IsolatedLauncherFactory.java:68)
    at org.sonarsource.scanner.api.EmbeddedScanner.doStart(EmbeddedScanner.java:185)
    at org.sonarsource.scanner.api.EmbeddedScanner.start(EmbeddedScanner.java:123)
    at org.sonarsource.scanner.cli.Main.execute(Main.java:73)
    at org.sonarsource.scanner.cli.Main.main(Main.java:61)
Caused by: java.nio.file.AccessDeniedException: /usr/src/.sonar
    at java.base/sun.nio.fs.UnixException.translateToIOException(Unknown Source)
    at java.base/sun.nio.fs.UnixException.rethrowAsIOException(Unknown Source)
    at java.base/sun.nio.fs.UnixException.rethrowAsIOException(Unknown Source)
    at java.base/sun.nio.fs.UnixFileSystemProvider.createDirectory(Unknown Source)
    at java.base/java.nio.file.Files.createDirectory(Unknown Source)
    at java.base/java.nio.file.Files.createAndCheckIsDirectory(Unknown Source)
    at java.base/java.nio.file.Files.createDirectories(Unknown Source)
    at org.sonarsource.scanner.api.internal.cache.FileCache.createDir(FileCache.java:145)
    ... 9 more
ERROR: 
ERROR: Re-run SonarScanner using the -X switch to enable full debug logging.

Improvements

It might be a good idea to cache Sonar Scanner directories to be re-used in future pipeline runs:

sonar:
  image: sonarsource/sonar-scanner-cli
  script:
    - sonar-scanner -Dsonar.qualitygate.wait=true
  allow_failure: true
  variables:
    SONAR_PROJECT_BASE_DIR: "${CI_PROJECT_DIR}"
  cache:
    key: "sonar-${CI_PROJECT_ID}"
    paths:
      - ".scannerwork"
      - ".sonar"

In my particular case, SonarQube analysis was not dependent on any other steps in the pipeline, so I've used needs and dependencies properties to make it run ahead of time and skip downloading artifacts of other steps.

sonar:
  image: sonarsource/sonar-scanner-cli
  needs: []
  dependencies: []
  script:
    - sonar-scanner -Dsonar.qualitygate.wait=true
  allow_failure: true
  variables:
    SONAR_PROJECT_BASE_DIR: "${CI_PROJECT_DIR}"
    GIT_DEPTH: 0
  cache:
    key: "sonar-${CI_PROJECT_ID}"
    paths:
      - ".scannerwork"
      - ".sonar"

Finally, I've used GIT_DEPTH environment variable to enforce Shallow Clone of our fairly large repository.

# docker # devops
Logo
CI/CD

CI/CD社区为您提供最前沿的新闻资讯和知识内容

更多推荐

Jenkins环境变量、参数及groovy脚本使用介绍。

这是系列中的第三篇文章 使用 Jenkins 将 Django 应用程序部署到 AWS EC2 实例。 Jenkins的温和指南。 在本文中,我们将介绍如何在 Jenkins 中使用变量和参数以及如何使用 groovy 脚本。我们将使用与以前相同的项目。您需要事先阅读过之前的文章。 1.如何在 JenkinsFile 中配置和使用变量。 在编写 JenkinsFile 管道脚本时,您可能需要注入和

avatar CI/CD

Rust 中的 OpenTelemetry 分布式跟踪指南

在本文中,我将分享我将 OpenTelemetry 分布式跟踪添加到 Rust 应用程序的经验。 我将尝试回答以下问题: 如何在 Rust 中检测 Opentelemetry? 如何在 Rust 应用程序中添加手动和自动检测? 如何使用tracing来调试Rust应用? 如何可视化跟踪和跨度? 如何在多线程环境中保存我们的 span 上下文? 在 Rust 中进行跟踪时,你必须知道哪些 crat

avatar CI/CD

Jenkins 管道,用于构建 Django 映像并将其推送到 dockerhub 和 GitHub webhook 集成。

这是系列文章的第四篇 使用 Jenkins 将 Django 应用程序部署到 AWS EC2 实例。詹金斯的温和指南。 在本文中,您将拼凑您所学的所有基础知识,并构建一个完整的 Jenkins 管道,该管道将构建 Django 映像并将其部署到 Dockerhub。您需要事先阅读过之前的文章 1.添加 init 阶段并加载script.groovy文件。 在您的 JenkinsFile 中,添加加

avatar CI/CD