Sonarqube closed issue and reopen it next time automatically

csharp

(Chuck Lu) #1

Template for a good bug report, formatted with Markdown:

  • versions used (SonarQube, Scanner, Plugin, and any relevant extension)
    sonarqube version 7.4.0.18908
    SonarScanner for MSBuild(sonar-scanner-msbuild-4.3.1.1372-net46)
    Plugin( sonar C# 7.9.1 (build 7622) installed)

  • error observed (wrap logs/code around triple quote ``` for proper formatting)
    When nobody edit the source code, sonarqube will auto close and open issue

  1. the issue was closed automatically
  2. the same issue was opened automatically
  3. loop step1 and step2
  • steps to reproduce
    Have no idea about it

By the way, I have found someone else report the same problem on stackoverflow https://stackoverflow.com/questions/40915708/sonar-issue-auto-closed-and-reopen


(G Ann Campbell) #2

Hi,

The issue change log might give you an idea of what’s going on. Also, the docs on which issues are considered new might help as well.

In terms of giving you further help in this thread though, there’s too little here to go on to go any further than that.

 
Ann


(Chuck Lu) #3

Hi @ganncamp,
Thanks for your quick response.

1.I try to google “issue changelog sonarqube”, but I can’t find the document about how to find the issue change log in sonarqube. Could you tell me how to check this?

2.About “which issues are considered new”, I think it’s not possible caused by this since nobody modify the source code, we just build the project in Jenkins and send it to sonarqube by scanner.

3.Another new situation I found is:
We build multi projects in one Jenkins project with pipeline, but only one project has the problem. The others will not auto close and reopen issues. I am not sure if we configured that project correctly. I will check the scripts with our configuration engineer later.

I will come back, if we have any progress.


(Chuck Lu) #4

After compare with the other project’s activity in sonarqube, we found the project which has problem with weird behavior.
It will stop using sonar way(python) , stop using sonar way(xml).
What did this mean? The source code of our project is C# .


(Chuck Lu) #5

My colleague is using pipeline to build several projects.
Project B has a reference of Project A.
Project C also has a reference of Project A.

When Project B rebuild, it output dlls to a common folder, and send a request to sonarqube.
However when Project C rebuild, it output the dlls to the same common folder.
We guess the problem might caused by the second rebuild, it will overwrite the first rebuild. We will try to split the output target folder between different projects to see if it can solve the problem.


(G Ann Campbell) #6

Hi,

Sorry, I probably should have sent a screenshot with my first reply but I was lazy. I was talking about the issue-level changelog, which you can find here:

If the same issue was closed and then reopened, it will show up in the issue changelog. If however, the issue matching algorithm wasn’t able to make the connection between the old one and the new one, your “new” issue will only have creation in it. That’s why I referred you to the docs about what issues are new.

But noow, looking at the activity log from your most recent followup I see that your use of the relevant profile fluctuates from analysis to analysis. It looks like your analyses alternately do and then don’t include your Python code. If all your analyses included Python, then you’d see multiple events on each analysis:

  • Stop using ‘Sonar way’ (Python)
  • Start using ‘Other profile’ (Python)

The only time you use no profile at all for a language is when that language isn’t found in the project. So, your investigation needs to back up to why Python

  • is being excluded from the checkout
  • is being deleted before analysis
  • is being excluded from analysis
  • is …?

 
Ann


(Chuck Lu) #7

My colleague fixed this problem according https://stackoverflow.com/questions/49870071/sonarqube-quality-profiles-are-not-being-used-during-the-sonarqube-scan
Use clean and build instead of only build to fix this problem.


(Chuck Lu) #8

Hi,
The same problem happened again. And here is the issue change log


The issue was auto closed then re-opened again and again.

I re-check the activity of the sonarqube project, I found the project the profile was in a weird loop
1.start using sonar way in first build and scan
2.stop using sonar way in second build and scan
3.loop 1 and 2


(Chuck Lu) #9

Since new user can not upload multi images in one post, so I attached the activity of the sonarqube project here. The sonar way with used and stopped alternately.


(Chuck Lu) #10

I find there are some *.py files in our project, and these files are referenced from third party.
How every these files will not be compiled by msbuild, they will only be copied to the bin folder by *.bat in post-build event of visual studio project.

I do not know how sonarqube works with msbuild scanner, what kind of files will be scanned?
We have a .bat file to copy *.py files as following
set projectDir=%~1
set targetDir=%~2
xcopy “%projectDir%\fckeditor” “%TargetDir%\fckeditor” /e /y
I am not sure if the post-build event will finish the copy action before msbuild scanner starts to work.
I could try to move the operation from post-build event to pre-build event.

However, the problem still exists, why the python sonar way would affect the result of C#? Since they are two different quality profiles.


(G Ann Campbell) #11

Hi,

As discussed in the StackOverflow answer you referenced earlier in your thread, you need to investigate your CI to see why you’re having these fluctuations every other analysis.

From your issue change log screenshot, my best guess is that analysis of a branch where the issue is fixed is interleaving with analysis of a branch where it’s not. This interleaving of branches or analysis configurations or methods could also explain why XML, and Python analysis turns off and on.

 
Ann


(Chuck Lu) #12

It seems the previous solution works, my colleague forget to apply the solution to another Jenkins build project which makes me think the problem still exists.