SonarSource
NET-1809 Consider the configured file exclusions when doing the analysis
When file exclusions are configured we do analyze the files, generate the metrics, and later raise warnings since they are not part of the analysis context.
Source: https://community.sonarsource.com/t/improvement-dont-log-does-not-exist-in-the-analysis-context-warnings-for-excluded-files/73799
Any progress here? We're still having Thousands of warnings just because we excluded a folder.
Hi @devopsjam, we did not have yet any progress on this front.
@pavel-mikula-sonarsource This is done only in the context of SonarLint. When using the scanner, it doesn't work yet since we don't have the project root path in the analyzer.
We should plan a sprint for this. Maybe 2024 Q1?
Hi @bdovaz, I have no news yet. Probably, it will not happen in Q2 this year.
@costin-zaharia-sonarsource Do you have any update on this issue? It has been 2 years since it was raised - it feels like that would be enough time to plan to fix it.... Thanks
This would be a great improvement, specially considering the warnings that appear from auto-generated files like RegexGenerator.g.cs and LoggerMessage.g.cs that we have little control of.
Grpc.Tools generate deliberately empty .cs files.
Those files produce warnings and excluding those files still produces warnings.
Very frustrating experience.
The generated files seems like an unrelated problem. Do you intentionally analyze generated files? As those, by default, would not be analyzed and therefore should not raise warnings.
These files seem totally generic and are placed in the obj folder. Neither their filename or their content (which is empty) give any indication about them being generated, so I suspect sonar doesn't catch them.
E.g.:
\obj\Debug\netstandard2.0\Protos\FileGrpc.cs
Should be trivial to exclude anything in the obj folder from ever being analyzed. I can't think of any reason to examine anything there - it is intermediate build output and as such should not be relevant to source code analysis IMO
Should be trivial to exclude anything in the obj folder from ever being analyzed. I can't think of any reason to examine anything there - it is intermediate build output and as such should not be relevant to source code analysis IMO
It's relevant when analysis of generated files is turned on. Form Roslyn's (or analysis in general) point of view, the content of obj doesn't differ from any other directory.
To improve general generated-code detection based also on the obj/ directory (or wherever it was redirected in custom scenarios) is interesting idea. cc @denis-troller
Should be trivial to exclude anything in the obj folder from ever being analyzed. I can't think of any reason to examine anything there - it is intermediate build output and as such should not be relevant to source code analysis IMO
Sure is and I got it working, but that brings us back to this issue about being spammed by warnings despite configured excludes.
Should be trivial to exclude anything in the obj folder from ever being analyzed. I can't think of any reason to examine anything there - it is intermediate build output and as such should not be relevant to source code analysis IMO
It's relevant when analysis of generated files is turned on. Form Roslyn's (or analysis in general) point of view, the content of
objdoesn't differ from any other directory.
Ok so when analysis of generated files is turned off then you should be able to simply ignore the obj folder completely and that should satisfy most users right?
Unless you think that most people have analysis of generated code turned on?
thanks
Should be trivial to exclude anything in the obj folder from ever being analyzed. I can't think of any reason to examine anything there - it is intermediate build output and as such should not be relevant to source code analysis IMO
Sure is and I got it working, but that brings us back to this issue about being spammed by warnings despite configured excludes.
I meant for Sonar to exclude this - I agree for users, it is not a good experience being spammed about useless files we don't care about which are not meant to be included anyway
@pavel-mikula-sonarsource tells me that I don't have access. Are tickets private in Jira?
I'll reopen this one so you get an update here once it's done. We've generally left open mainly FPs and moved most of the tooling/improvement ones
We have close to 10MB logs due to this warning. Would be nice to get rid of it.
This issue causes problems with multi language analysis of projects (C# and NodeJS) because it scans all the node_modules subfolders and in a sufficiently large project causes github actions to report a timeout.
It would be nice to have this issue resolved expecially since it's been reported 3 years ago now
