Jenkins Gradle pipeline build succesfully but the results are empty

We are facing an issue when scanning a short lived branch like feature/some-branch.
We are using Jenkins Grade pipeline to automate scanning every time a commit is made on BitBucket.
The analysis seems to complete OK but the results are empty on SonarQube UI, and I know there should be some code smells.
We are using SonarQube 7.6 Developer Edition

The strange thing is that when I manually run the scan on my laptop and passing the exact same parameters used in jenkins pipeline the results are uploaded successfully and reported on the project
The pipeline used to work when you don’t set the parameter but it was reporting as Master every branch it was scanning.


This is what it shows on the UI


To be clear, are the issues you’re expecting issues that are new to the code? I.e. they were added in the PR and not present in earlier versions of the code?

Also, does the project use the default quality profile?


Hi Ann,
At this point I think it is irrelevant because the same code analyzed locally on my laptop using the same arguments as jenkins file publishes the report on the target project on the UI and the same code when analyzed using jenkins pipeline finishes successfully but reports no issue.
But to answer your question there isn’t any new PR and the project is using the default security profile.

In the past we didn’t use on jenkins, and any branch scan was published under the name master under the project, later on as we upgraded to developer edition for branch analysis we introduced the parameter to jenkins and the scans were published as short living branches and that’s the time this issue was introduced.


Sorry, I’m not sure what the “it” is here.

To be clear, when you analyze from your laptop, you see issues and when you analyze from Jenkins you don’t? If so, what if any differences do you see between the two analysis logs? Also, I don’t suppose you’d share a screenshot of the result of the from-my-laptop analysis?


I was referring to the fact the is the same piece of code, analyzed from two different sources.

The only thing I see different on the logs are these lines when using jenkins


Both of your screenshots omit the Resolution facet on the issues page. Since the ‘empty’ branch was analyzed a few days ago, it’s possible that someone has marked the two missing issues False Positive or Won’t Fix. Could you check. And if that’s not the case, could you post the two analysis logs?



Actually that’s not the case because the system is isolated from the users for the time being.

jenkins_scan.txt (58.5 KB) local_scan.txt (67.7 KB)


Thanks for the logs. I think this is the crux:

Could not find ref: master in refs/heads or refs/remotes/origin

That’s from your Jenkins log, line 578 (it’s repeated at line 664). I don’t recall all the details, but PR analysis does some sophisticated narrowing of what to report based on changes in the PR versus the base. This is to make sure that all and only the issues new in the PR are reported. For instance, if an issue is fixed in master after the PR’s branch was started, without this versus-base analysis the issue would be reported as “new” in the PR when clearly it’s old-but-not-caught-up.

Anyway, back to your logs, lines 658-659 in the Jenkins log

2 files to be analyzed
2/2 files analyzed

Versus the analogous lines (782-784) from your local analysis tell the story:

3 files to be analyzed

3/3 files analyzed

And as a side note, God Bless the maintainers of the Meld diff viewer. :sweat_smile:


1 Like