We have an issue since our upgrade to SonarQube 6.0 that on the issues page the link icon or the right arrow icon no longer link to the code.
In this case clicking either link takes you to another (smaller) list of issues.
This is not the case for all issues, the only difference I can spot is that on the problem issues the filename and line number are not shown. checking in the database and in the issues table the 'line' column is also null.
We are using SonarQube 6.0 with C# plugin 5.3.2 - Analysis is triggered by TFS2015 Update 3
Many thanks in advance for any ideas/advice.
Following Teryk's response I manage fine tune my investigation. It turns out that it is cased by the MSBUILD output which does not include a filename or line for certain CA warning is Microsoft.Design and Microsoft.Naming, e.g. CA1024, CA1040, CA1704, CA1716, thus:
3>MSBUILD : warning CA1040: Microsoft.Design : Define a custom attribute to replace 'ITierRepository'.
When this happens the issue is recorded against the solution but obviously cannot be assign to a specific file and the line not identified.
Having found that I was quick able to find the article which discusses the same issue:
https://groups.google.com/d/topic/sonarqube/UDIIjWbCGjs
It is caused by the fact that FxCop is not able find source for the issue as described here:
https://blogs.msdn.microsoft.com/codeanalysis/2007/05/12/faq-why-is-file-and-line-information-available-for-some-warnings-in-fxcop-but-not-for-others/
It apparently relates to changes to FxCop reporting that were introduced in v5.2 of the C# plugin which was also deployed at the same time as upgrading to SQ 6.0
Related
Just upgraded to Visual Studio 2015 and the Code Definition Window is not working.It just says "No definition selected" no matter what I select. Project is Windows Forms written in C#.
Go to Definition and Peek Definition are working fine
Went back to VS2013 to try it out and it's still working there
Tried to make a brand new project in VS2015 to see if it was project related, but it was not
Checked with a couple of colleagues and it wasn't working for them either
I have a feeling this is either a bug in VS2015 or some sort of configuration change.
Anyone found a way to configure it, or any sort of work around to get it up and running again?
I got a reply from Microsoft on my Bug report. Turns out it's not implemented and possibly never will be:
Hi,
Based on the fact that Peek Definition was introduced in VS2013,
combined with telemetry data that shows that only a tiny percentage of
users ever display the Code Definition Window, we decided not to
implement support for it as part of Roslyn. I've filed an issue on our
GitHub project to consider resurrecting it.
Thanks for the report!
-- Kevin Pilch-Bisson Visual Studio Managed Languages
Here´s the github issue Kevin created in response to my bug report in July: https://github.com/dotnet/roslyn/issues/4224
Looks like they just merged a fix for this into Roslyn:
https://github.com/dotnet/roslyn/pull/56102
We just updated SonarQube from 4.2 to 4.5.4 but we have a problem with the following Java rule:
Key : squid:MethodCyclomaticComplexity
Name: Methods should not be too complex
The rule is used in the analysis and several complexity issues are correctly found, but it's not possible to edit the rule (to change the Threshold value, for example) because the rule is not displayed in the web interface:
Steps to reproduce the issue:
Log in SonarQube
Click on Rules
Search for "MethodCyclomaticComplexity"
Click on MethodCyclomaticComplexity rule found at the left side of
the window
Result: Nothing appears at the right side of the window!!!
Please, could someone help to resolve this?
The "data/es" folder should not be copied when doing a SonarQube upgrade (see the "upgrading" guide).
So to solve your issue:
Stop SQ
Drop the "data/es" folder
Restart SQ, et voilà!
Recently we upgraded our SONAR from 3.x to 4.3. There was an error in our Jenkins build (squidindex was null) which triggered the upgrade of the java from 2.2 to 2.2.1 along with the plugins for JaCoCo, Findbugs, Squid for Java, and Surefire.
Once SonarQube was up and running again, we discovered that although no code changes had taken place, we now had over 200 critical issues as well as a high number of major ones. Upon research, it became apparent that all of our previously marked false-positives had now reappeared.
Obviously we want to find a way to fix this besides walking through over a thousand various issues and re-marking them.
We have done some research in the database and have discovered a puzzle that we think might be related. In the Issues table, we have found that there are duplicate entries where the first difference is that one entry has the simple file name and the other entry has the file name along with the extension.
(I had an image of a few lines from the database to put here, but as I do not yet have a 10 reputation, I cannot. Please contact me and I will be glad to email the image. Sigh.)
As you can see, Lines 2 & 3 both refer to line 134 in the file PersistentObjectCollection.java. Line 2 shows that the issue is FIXED and CLOSED while Line 3 shows the same issue as Open and null resolution.
We are wondering if we could safely use SQL to find matched pairs like this and copy the necessary columns across to register the issues properly?
Can you please take a look and tell me if this is something feasible to do, or if there is a better alternative to try.
Question already asked on the SonarQube mailing list : http://sonar.markmail.org/thread/kpx3une24lwoilli
Please don't duplicate question !!
I am trying to follow this writeup (http://pwigle.wordpress.com/2009/12/11/code-metrics-statistics-with-team-city/) to add code statistics to my TeamCity 6.0 Ci server. I have gotten everything to work as described in the writeup except the last part where the results of the SourceMonitor are displayed in the statistics page. Is there something different that I need to do in TeamCity 6.0 to get this to work?
FYI you have to edit (TeamCity path).BuildServer\config\main-config in 6.0 instead of (TeamCity path).BuildServer\config(project name)\plugin-settings.xml. The plugin-settings.xml file is still present in 6.0 but doesn’t appear to do anything anymore. After that all works as detailed in the write up I posted before.
I've set up TeamCity to notify the whole team when a new internal release is ready. The email contains links to server folders where the distributive has been placed. The link pattern is quite simple, the only thing that's 'dynamic' is the lowest-level folder - it's name matches the version number.
The folder is generated by MsBuild using TeamCity's "build.number" property. All is good with it, its name contains only what has been specified in the pattern (e.g. 1.0.0.0). But the strange thing is that {BUILD_NUMBER} in notifications template returns **#**1.0.0.0 (with the # sign).
So the email ends up with bad links.
Has anyone noticed this? Is there a fix?
Someone else asked essentially the same question on the JetBrains TeamCity blog, as well as on the Developer Community forums.
It appears the community has already seen this issue, but there doesn't seem to be a easy fix or workaround:)
The reported bug seems to have got a fix in version 5.1.