We are evaluating if we can install and use it in our organization in combination with Jenkins.
The problem I see is that there are rules that don’t apply to Unity specific code like errors regarding:
Unused methods: Unity’s magic “Awake, Start, …”
[SerializeField] and fields that suggest in some cases adding “readonly” or similar that we can’t because doing that it’s going to hide from inspector.
We have tried using SonarQube on Unity’s code base with moderate success. It’s quite easy to setup and it works out of the box, but it does not support adding custom rules, which means that you are stuck with what it offers in the default C# analysis profile.
I guess the only way to deal with Unity’s magic methods being identified as Unused methods and so on is to mark those issues as False Positive. Assuming your code base isn’t very large, it shouldn’t take too long, and Sonar will ignore those in future analysis iterations of your code base.
Regarding the bug reports, the first one is fixed and should be included in one of the upcoming Unity builds and the other one was answered by someone in QA (I recommend you reply to them if you have further questions).
Currently there is no direct collaboration between Unity and Sonar. Sounds like they are working on a solution to whitelist certain type of code in the rules, in which case that would allow anyone (including us) to provide more custom-based checks on Sonar for Unity code. We will keep an eye on their progress and future Sonar updates.
The problem is not with Sonar itself, its because Unity has its “magic” using reflection and that’s why we have many false-positives. Its a problem that you will face in any similar tool.
Code coverage not because with Unity it’s not possible but rules are really useful to avoid code smells or bugs that can be detected with static analysis.
In our code base we want code that it’s clean, performant and works without issues so yes, it helps.
My SonarQube instance is installed on a CentOS 7 system, so I am stuck with SonarQube 7.1 for the time being. This means that I cannot use build-wrapper-macosx-x86 as mentioned on https://docs.sonarqube.org/display/PLUG/Building+on+Mac+OS+X. I am not using the commercial version at this time. I am also doing all this through Jenkins.
My basic process is like this:
(Do this once before analyzing and periodically to update to newer releases.) Download the newest version of sonar-scanner-msbuild from https://github.com/SonarSource/sonar-scanner-msbuild/releases and extract somewhere in the $PATH. I just extracted mine in ~/bin. Run chmod +x ~/bin/sonar-scanner-*/bin/sonar-scanner* or you will get an Access Denied error when you call SonarScanner.MSBuild.exe end.
(Do steps 2-10 each time you analyze.) Optionally, set VERSIONNAME to use in SQ to set a new leak period. If VERSIONNAME was set, run a script to pull the commit date from Bitbucket (see below). If you’re not using Git (or equivalent), set COMMITDATE in the format yyyy-MM-dd i.e. 2019-05-26 (or yyyy-MM-ddTHH:mm:ssZ i.e. 2019-05-26T15:42:06-0500 for additional precision).
To avoid any Unicode issues, set LANG=en_US.UTF-8
Set the project key, name, and any other sonar options.
Run Unity in batch mode and, among other things, have it call EditorApplication.ExecuteMenuItem("Assets/Open C# Project"); to create the solution and related files for later use by Visual Studio.
If VERSIONNAME is set, run . properties.sh to pull those values in as environment variables.
Here, briefly, is where it gets spectacularly weird. You’ll have to use the second script to:
Link in the source files of any Unity Packages you’re using. This step requires the jq utility that you can install using MacPorts or Homebrew.
Move files that have been created with Windows backslash directory delimiters in the filenames into proper directory trees i.e. foo\bar\baz to foo/bar/baz
Run mono SonarScanner.MSBuild.exe begin "/k:${PROJECTKEY}" "/n:${PROJECTNAME}" "/v:${VERSIONNAME}" "/d:sonar.projectDate=${COMMITDATE}" "/d:sonar.host.url=http://sonar.foo.com:9000" /d:sonar.login=${SonarQubeToken}
@SciPlayDave I’m trying to configure sonar scanner with macOS (I already have it working on Windows) and it does all the process correctly without errors but I see tons of:
WARN: File ‘{A C# script}’ referenced by the protobuf ‘MetricsInfo’ does not exist in the analysis context
WARN: File ‘{A C# script}’ referenced by the protobuf ‘TokenTypeInfo’ does not exist in the analysis context
WARN: File ‘{A C# script}’ referenced by the protobuf ‘SymbolReferenceInfo’ does not exist in the analysis context
@goldbug are you using GitHub actions? i’d like to ask you what is the support for running Unity there? should you bring your own on-prem machine to run the actual build, or does your build pipeline need to install Unity on the VM? how does it work exactly ?
Also, is SonarQube supported “out of the box” or you had to do some initial setup to get it up and running ?