Coverage Missing only when some Params passed in ./gradlew command

I’m trying to hunt down some odd behavior I’m seeing. After some daily sonar scans, coverage information isn’t being uploaded.

I’ve been trying to play around with implementation, so I don’t think it’s a flakiness issue. Specifically, I’m trying to split the sonar scan param definition between the build.gradle file and the ./gradlew sonar command.

What I seem to have found is that if I place the login token in the ./gradlew sonar command, it uploads the scan but not Coverage. But if I place the token in the build.gradle file the Coverage also gets uploaded. Am I wrong in thinking that we should be able to split up setting sonar scan params with some in build.gradle and others in the ./gradlew command?

I’m trying to hunt down what is going on, but I’m wondering if you’d have any suggestions. I assume this isn’t expected behavior. Any idea what might be happening?

For what it’s worth, the gradle command in question is not just running “sonar”. It’s also running builds and tests, and just tacks on “sonar” at the end. i.e. ./gradlew build -PbuildParam=true test -PtestParam=true sonar -Psonar.login=12345abcde -Psonar.projectKey=mySonarProject

What I’m finding is working consistently is if I define every sonar parameter in the build.gradle.kts file, and do not include any sonar params in the gradlew command, this correctly uploads with coverage and everything. i.e. ./gradlew build -PbuildParam=true test -PtestParam=true sonar.

But I would like to be able to store the login token in a credentials store and pass it along into the gradlew command, not store it openly in the build.gradle.kts file.

Also, I would like to support pull request decorations. So I would like to be able to pass in the pull request params through the gradlew command.

One option could be to modify the build.gradle.kts file with the CI pipeline code to dynamically add in the right params there before running the graldew command without any params. But that seems like it shouldn’t be necessary.

I’m just wondering if there’s something I’m missing here?

^ I’d like to bump this thread. I tried some work arounds, but it still seems to be an issue which is blocking the ability to use SonarQube for coverage analysis.


Sorry this got overlooked.

Where your token is passed from shouldn’t have any impact on what does/does not happen in analysis, other than whether analysis has the permissions to run.

It would be interesting to see --info logs from both variants.

That said… what’s your CI? I’m wondering if embedding the token in project files is really the best option, versus configuring globally.