I have a SonarQube 5.3.1 in place with the C# Plugin 4.5.0 installed.
Basic included rules are detected as expected.
Now, I want to use the Roslyn SDK project (https://github.com/SonarSource-VisualStudio/sonarqube-roslyn-sdk) to add my tailor made analyzers into account.
I'm pretty sure they are okay because they are raised in both Visual Studio and when using msbuild in command line.
My problem now is to be able to upload those issues into Sonar, I must be missing something.
I obviously use the SonarQube Scanner for MSBuild v2.0, have installed my generated jar and have activated the rules (the appear in "Code Smell"), try to build a project with which my rules should break (and they do, as I said earlier), but it does not seem to pick up my rules.
The doc (https://blogs.msdn.microsoft.com/visualstudioalm/2016/02/18/sonarqube-scanner-for-msbuild-v2-0-released-support-for-third-party-roslyn-analyzers/) says it should "produce an error report containing analysis errors and warnings for all of the analyzers" and then upload it to SonarQube, but I cannot find this report. At the very least, just a SonarLint output file with no related rule whatsoever.
I've also tried with the Wintellect Analyzer as the github page suggests (https://github.com/SonarSource-VisualStudio/sonarqube-roslyn-sdk) with no success.
My guess is there's something wrong somewhere in the configuration but I don't know where, any idea ?
For each custom analyzer you want to use in SonarQube (example: Wintellect), you need to use the Roslyn SDK for SonarQube tool to create plug-ins that can be imported into SonarQube. Directions and info can be found here.
Related
I'm having trouble getting IntelliJ to recognize which source files correspond to the thing I'm trying to attach a debugger to. The project in question is a Gradle project running locally, using Java 1.7. (EDIT: I'm actually also running that project from within IntelliJ, and that's also what's building it. It's a Gretty task defined in the project's build.gradle file. I'm passing
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5006
to the JVM to open the debugging port.)
I can tell that the debugger is attaching to the process correctly since I get the "Connected to the target VM" message. But breakpoints do not get the checkmark, and they aren't hit during execution. (EDIT: This is leading me to believe that the sources aren't being attached -- The debugger is attaching to a process successfully, and I have reason to believe that process is the one I want since I'm using JVM arguments on it to open the debugging port, but it appears to me that the IDE doesn't recognize what source files correspond to the running code.)
The other person who works on this code does not seem to have this issue. He's on an older version of IntelliJ. His "use module classpath" dropdown has a <whole project> option and mine does not (though it does have <no module> -- is that the same?). Unsure which version of IJ he's on specifically; I'm on Ultimate 2018.3.
I'm sure that I need to include more information than this, but due to my unfamiliarity with Gradle as a build/run tool and with how remote debugging works in general, I don't know what information I'm missing -- of course I will provide it as soon as someone asks me for it.
BIG EDIT (and probably the real answer here): I have a feeling I'm attaching to Gradle itself rather than the task. If I choose Run -> Attach to Process, the dialog shows me "45039 org.gradle.launcher.daemon.bootstrap.GradleDaemon (5006)".
I am currently working on Guidewire Studio built on top of IntelliJ. I have installed the codenarc plugin into the studio but it seems like the rules of codenarc is not running for my codes. After analyzing the codes it does not give me any violation which i know, is there. Can someone please tell me what am i missing here.
You probably can't, but there's a workaround.
Guidewire provides their customers with GosuCodeNarc which is basically CodeNarc extended with several gosu rules' implementations, possibly some glue code as well. If you are missing any rules they provide documentation on creating any new ones.
This isn't shipped as a plugin, but rather a set of jars with instruction how to run them as gradle task (intended to be run on CD/CI).
EDIT
There is a way if you are on v9 or v10!
The inspection plugin to studio was intensively developed and is most likely meant to replace GosuCodeNarc entirely. Most importantly it provides all the inspections within the GW Studio.
The only requirement is to be on GW Studio v1.14 or higher and to turn inspections of choice within the inspections settings (use quick search to find this one).
Starting from v9.0.5 there's also a gradle task meant for command line use, so feel free to give it a try with
gwb inspect
More on it in
gwb help --task :inspect
gwb inspect will not work on Windows because of Intellij issue IDEA-152045
I'm using Mule Server 3.8 EE which brings commons-lang 2.4 with it. A third-party library in my project needs commons-lang 2.6, because it uses a method that was introduced in this version.
So when I just start my application, I get a java.lang.NoSuchMethodError
Is there a way to update the dependency in the runtime? What I tried so far:
including commons-lang 2.6 in my app -> no effect, the one from the runtime is picked up first
replacing the jar directly in the runtime -> errors in studio, that the 2.4 jar is missing
so maybe i am late BUT -- this is your answer. Add the libraries that are newer in the jar distribution to the Build Path. Under Java Build Path screen you should see the libraries listed. I needed to use Apache http-client 4.5.6 and that's very interesting because it brings with it a lot of other dependencies, so your question was VERY relevant. The solution is to rely on JAVA (and not mule -- oops Anypoint or whatever) conventions and make sure the JVM loads my class files first. Then, it won't load the old ones from mule's jar. And so I went to the tab Order and Export, and moved Mule to the bottom. This simple, trivial change makes it work. I think if we would work with command line and vim, we would all know this. But all the IDE gui and everything else makes us forget the simplest things. Please use it in good health. :)
Using bamboo v5.7 with msbuild v12, how do I fail a build if there are any static code analysis warnings? We do have our projects all set to treat all warnings as errors so the project itself doesn't build, but bamboo is not detecting this and continues on.
This seems basic, what might I be doing wrong?
The simple answer is you are doing nothing wrong, nor are you missing anything.
While it seems like basic functionality, Bamboo's MSBuild task currently doesn't support reading, reporting or failing the build on Warnings or Errors. The task only fails because MSBuild (or XBuild if you are using Mono) returns with an error code when a compiler error occurs.
Also, MSBuild doesn't actually support failing on all warnings either, as you can see here.
You have a couple options.
You can use one of the options in the referenced post
You could roll your own MSBuild log parser plugin using Atlassian's Plugin SDK.
You could make a simple script that is executed after the build, reads the logs and returns a non-zero integer if there were compiler warnings.
You can vote for the issue in the Atlassian Jira and also for the related issue for parsing build details.
Whatever your solution, I hope you share it with the many of us that have run into the same problem. It seems to be something quite common, so I was surprised there wasn't an issue already open for this in Atlassian's Jira instance
For VS 2008 and later, a new project setting was added for this. See this link.
I'm using the Sonar Eclipse plugin v3.3.
After I've fixed a rule violation, not a new issue, but one that exists on the sonar server, I re-run the analysis on my project in Eclipse. I expected that the fixed issues would no longer be flagged by the analysis, but they appear to be still flagged even though they have been fixed.
In my Eclipse SonarQube preferences I have the severity marked as warning and Force full preview... unchecked.
In the view options I have Show->All Issues on Selection checked.
How do I set up the plugin so that once I've fixed the issue locally, the issue is no longer flagged when I re-run the analysis on my project?
Edit:
Full analysis is run nightly by a conditional build step in Jenkins using SonarQube Runner.
When I run the analysis via Eclipse, the first thing it does is wipe out the existing issue annotations, but then as soon as it contacts the server it immediately adds them back in. The issues stay flagged regardless of whether they were fixed locally or not.
If I intentionally put in the wrong projectKey in the org.sonar.ide.eclipse.core.prefs file, then the local analysis runs similar to what I would expect. It flags all existing issues as new, which is expected, since it can't reach the server to ask if they were preexisting. It doesn't flag any fixed issues.
The problem was that I was using 3.7.3 on the server and not 4.0 or above. I upgraded the server install to 4.1 and all is well now.
BTW - The Sonar console output clearly stated :
SonarQube version 4.0 is required to perform local analysis.