PR Branch Scanner not able to write to report files

We are using the Sonar PR Scanner on branch builds within our Jenkin’s setup, but with certain Go-Lang based repositories, we are not getting any scan results to be reported.

Through much trial and error with debugging, we continue to see the same issue arise where the console logs note that the files within our reports folder (where we store the files for logging Sonar PR Scan results). Also, the logs are noting an issue with our direction to our source files. (we designate the folder ‘src’)

It would be greatly appreciated to get another set of eyes on this issue.

I have attached example documentation of what our configurations look like, and the console outputs observed.

We are using SonarGo plug in.

Analysis properties:

sonar.projectKey=compliance_goapi
sonar.projectName=[Compliance] go
sonar.go.gometalinter.reportPaths=reports/lint.txt
sonar.go.coverage.reportPaths=reports/coverage.out
sonar.language=go
sonar.sources=./src
sonar.exclusions=**/*_test.go,src/models/**/*,src/logger/**/*,src/cmd/compliance-server/main.go,src/restapi/**/*,src/rmq/ResourceRequest/*.go,src/rmq/rmqModel/model.go,src/constants/*.go,src/**/*.json,src/rmq/rmqModel/**/*

Analysis log: ConsoleLogSonarBranchScan.txt (366.4 KB)

Hi,

Welcome to the community!

I’ve edited your OP to include the analysis properties, since they’re short, and eliminated the link to that uploaded file. Normally I’d have done the same for your analysis log, but it is nearly 3k lines long. :slightly_smiling_face:

As I understand it, the problem is that analysis doesn’t actually find any of your Go files. Starting from your analysis properties, I have a few comments:

  • sonar.language=go
    This parameter was deprecated literally years ago and was finally dropped late in the 7.x series. You can safely remove it; it’s not doing anything

  • sonar.sources=./src
    While “./blah” should have the same effect as “blah” it’s probably better at this point to remove the ambiguity and shorten this to “src”

  • sonar.exclusions=**/*_test.go,src/models/**/*,src/logger/**/*,src/cmd/compliance-server/main.go,src/restapi/**/*,src/rmq/ResourceRequest/*.go,src/rmq/rmqModel/model.go,src/constants/*.go,src/**/*.json,src/rmq/rmqModel/**/*
    First, this is a long exclusion list. IIWY, I’d comment this out for now. Get the source into the analysis and then you can worry about getting it back out. Second, it’s probably entirely coincidental that these paths don’t match the sonar.sources path (./src vs src) but I see this as another reason to simplify the sonar.sources value.

Now, looking at your analysis log, I see that analysis starts on line 1912, and finishes at 2072.

Aaaand then starts again at 2073 and finishes at 2945 after a lot of warnings from GoLintReportSensor (interesting to me that this didn’t fire in the first analysis). Since the last line of analysis is this:

WARN: Found multiple 'report-task.txt' in the workspace. Taking the first one.

I’d say your second step after cleaning up your analysis parameters is to sort this out and narrow it down to only one analysis.

And finally, there’s a lot going on early in your log with Git. I didn’t read it closely but I did scroll past a lot of warnings. This is of interest to me only because both of your analyses logged warnings on getting blame data for your files, so you probably want to sort that out once you’ve got analysis under control.

I’m sure that even after taking these preliminary steps, you’ll have follow up questions on this topic. Don’t hesitate to come back with them.

 
:slightly_smiling_face:
Ann