Short-lived branch analysis without PR

SonarQube Cloud
1
  • ALM used: Gitlab
  • CI system used: Jenkins
  • Languages of the repository: C++
  • Scanner command used:
    sonar-scanner.bat
    -Dsonar.organization=myCompany
    -Dsonar.sourceEncoding=UTF-8
    -Dsonar.cfamily.compile-commands=bin/sonar-build-wrapper/compile_commands.json
    -Dsonar.projectBaseDir=someDir
    -Dsonar.branch.name=someShortLivedBranch
    -Dsonar.cfamily.internal.reduceAnalysisScope=false

Hello,

I run a build from Jenkins with the command given above, but I get strange behavior related to the raised issues. The analyzed branch is a short-lived branch created from a long-lived branch.
Should there be a sonar.branch.target in the command above ?

2

I added the parameter (hard-coded for now) sonar.branch.target=develop for the analysis which are not pull request, and I new get correct results.

But when I am in the pull request mode, by using the parameters:

  • sonar.pullrequest.key=...
  • sonar.pullrequest.branch=...
  • sonar.pullrequest.base=develop

with the same branch, I get some (old) errors, and also errors accepted from the analysis which was not in pull request mode. Among the old issues, there are some files whicj has not been touched in the short-lived branch.

develop is a long-lived branch, and it has not issues when I analyze it.

3

Hi,

PRs don’t ‘inherit’ issue status from branches. It’s the other way around.

You should be letting analysis discover those values from the environment and set them automatically.

This sounds like a problem with the SCM metadata available to analysis. It’s what’s used to understand what changed in the PR.

 
HTH,
Ann

4

Hello,

Thanks for your answers.

It’s not clear in the documentation you’re pointing. A sentence expliciting that would be welcome.

You mean I should remove all these 3 parameters when asking analysis from Jenkins ?

5

Hi,

Here you go (emphasis mine):

If you’re using short-lived branch and pull request analysis, issues marked as false positive or accepted will retain that status after merge. This is the preferred approach.

Yes.

 
HTH,
Ann

6

Hello,

Actually are raised some issues related to touched files, but on lines which have not been modified. Is it the expected behavior ?

7

Hi,

In the context of short-lived branches and PRs, this is not the expected behavior. Again

 
Ann

8

OK, so it would be a problem with Git.

Bu what I am supposed to check ? I don’t know how Sonar and Git interoperate.

9

Hi,

You’ve already marked this topic solved. Are you still asking about what analysis parameters to use for a short-lived branch?

If you want to take this up, please create a new thread.

 
Ann

10

I’ll start a new thread. Thanks.