No Java with AutoScan! Planned?

(Frédéric Danna) #1

Java does not belong to the list of supported languages )-;
And you say: “Non supported languages (Java, […]) will not be analyzed at all.”
Does “at all” means “never”? If so, could you explain this decision please (for sake of curiosity)?

(Benoit) #2

The reason we currently don’t support Java (and other compiled language) is that our analyzers need the binaries (i.e. compiled sources) to provide relevant results. And automatically compiling any Java project (or other compiled language) is not a trivial task. So, we currently want to fully develop the feature (with proper UI/UX) for interpreted languages only.

AFAIK we might support Java in the future, so I wouldn’t say never but we don’t have a precise plan yet.

[Beta] Automatic Analysis of your repositories with SonarCloud
(Rob Moore) #3

Thanks for the explanation. Is there a way to use the autoscan feature in combination with something like Gradle or Maven for projects that feature Javascript and Java? I ask because we initially set up the project using autoscan and would like to add Java analysis as well.

(Simon Brandhof) #4

Hi Rob, welcome on this forum.

Building a Java project is usually not only a matter of running Gradle or Maven on a fresh environment. Builds require configuration, the most basic example being the JDK version to be used. Duplicating the configuration that is set on CI side (Travis, CircleCI or others) and running the build twice is not considered as a valid option.

Nevertheless it’s easy to activate analysis in your CI. You have two options:

  1. run scanner after the Gradle or Maven build
  2. or configure and run the Gradle or Maven plugins

I hope it helps.

(Rob Moore) #5

Thanks, Simon. It sounds like what you are suggesting is running the Sonar task as part of our CI pipeline and disabling the Github analysis by renaming the properties file. Should we remove the project from Sonarcloud before the initial run using Gradle or is it fine to leave everything as is within Sonarcloud?

(Simon Brandhof) #6

I forgot to mention that the project key should be added to your configuration (see sonar.projectKey). Keeping the key generated by Autoscan is enough for switching analysis to your CI. Value is displayed in the bottom-right of project dashboard, for example:

(Rob Moore) #7

Thanks again. One of the reasons we wanted to use the autoscan feature was because it allowed us to take advantage of the Github checks on PRs. We have other services we use that indicate issues with a PR so it fits in well. Is there any way to take advantage of the Github integration using Sonar as part of our CI pipeline instead of the autoscan feature?

(Aurélie Boiteux-Cabourdin) #8

Yes sure ! You just need to configure your CI to analyse your Pull Requests, and install the SonarCloud GitHup App on the GitHub organization which host your repositories (the installation is done automatically if you bind / or have bound your organization).

Hope it helps!

(Rob Moore) #9

Thanks for the response. It sounds like you are saying that we should still see the SonarCloud Code Analysis check in Github PRs using this approach? I’m a bit surprised by this as we didn’t see that behavior when we had our repos set up using the Gradle Sonar task. In fact, that’s what motivated us to move to AutoScan. Perhaps we had something misconfigured or this functionality was added in the interim?

(Aurélie Boiteux-Cabourdin) #10

Maybe it was added in the meantime, Checks were introduced recently as you can see in the announcement.

(Rob Moore) #11

Actually, it was because I wasn’t passing in the correct parameters to the sonarqube task.

Somehow I missed this the first time around. This post was put me on the right path: