Issue-Question-FeatureRequest

[TomerFi]

Hello

First off, Great plugin - Thank you! 👏 👏

I have a Java Maven project on my Gitea, with it I use Drone for CI purposes and your plugin to communicate between Drone and SonarQube.

I have an Issue/Question/FeatureRequest, I'm not sure what category the following belongs to...

I'm trying to fix three issues I've encountered using this plugin:

1. SonarQube says its result could have been better if had passed the location on the my byte-code classes.
2. JUnit reports doesn't show up after configuring the correct path of the reports created by Maven's Surefire plugin.
3. The SonarScanner that runs by this plugin takes to long since it's downloading all the plugins from the SonarQube server every time it runs. I tried to solve it using Meltwaters's Drone Cache Plugin and caching the /root/.sonar folder the downloaded plugin are saved, but to no avail.

I was able to workaround all these issues using the Scanner Analysis Parameters:

1. Using sonar.java.libraries=target/classes fixed the first issue, since now SonarQube knows where the class files are, I'm no longer seeing the warning.
2. Using sonar.tests=src/test/java fixed the second issue, since now SonarQube knows where the test files are and can match Surfire's reports to them. The Junit Reports are displayed.
3. Using sonar.userHome=sqplugins fixed my third and final issue, since the sqplugins is a new folder I've created and can be cached using Meltwaters's Drone Cache Plugin. The plugin runtime has reduced from 4-8 minutes (depending on the amount of plugins I use) to less then 20 seconds, since the previous downloaded plugins are now accessible.

Going through your code, I've noticed this plugin is not handling these three "life-saving" arguments.

So as a workaround, I ended up with this step in my .drone.yml configuration:

  - name: sonar-scanner
    image: aosapps/drone-sonar-plugin:1.0
    commands:
      - mkdir -p sqplugins
      - >-
        sonar-scanner -Dsonar.projectKey=tomerfi:selfhost-test2
        -Dsonar.projectName=tomerfi/selfhost-test2
        -Dsonar.host.url=[REDUCTED]
        -Dsonar.login=[REDUCTED]
        -Dsonar.projectVersion=0.0.1
        -Dsonar.links.scm=[REDUCTED]
        -Dsonar.sources=src/main/java
        -Dsonar.tests=src/test/java
        -Dsonar.java.libraries=target/classes
        -Dsonar.scm.provider=git
        -Dsonar.userHome=sqplugins

The sqplugins folder, is of course cached in the next step and restored in the previous one using Meltwaters's Drone Cache Plugin. As you can see, It's a messy solution, it works, but it's messy.

My main issue now is that I don't have access to the plugin configuration or the repository secrets, so the arguments values, especially the host url and host token needs to manually added to the .drone.yml file, which is of course a very bad practice.

To sum it up:

1. Can you perhaps think of a better, less messy workaround, one that won't require adding the url/token manually to the configuration file?
2. Do you know of a way I can gain access to the secrets in SonarQube?
3. Do you have any future plans on adding more arguments to the plugin which will allow more control of the Sonar Scanner, I wouldn't mind PR'ing it myself, but I'm not familiar with Go, so it might take some time.

Thank you very much!

[cruddasj]

Hey @TomerFi - coincidentally we've just had the exact same challenge reporting on a Spring project. Your notes above were super useful! Whilst longer-term, an update to this plugin which passes in the command args for the sonar.java.libraries variables etc. would be ideal, in the meantime, we've managed to avoid keeping sensitive credentials in the drone.yml file using the below approach:

 - name: sonar scan
    image: aosapps/drone-sonar-plugin
    environment:
      sonar_host:
        from_secret: sonar_host
      sonar_token:
        from_secret: sonar_token
    commands:
      - sonar-scanner -Dsonar.projectKey=${DRONE_REPO}
        -Dsonar.projectName=${DRONE_REPO}
        -Dsonar.host.url=$sonar_host
        -Dsonar.login=$sonar_token
        -Dsonar.tests=src/test/java
        -Dsonar.sources=src/main/java
        -Dsonar.java.libraries=./target/classes
        -Dsonar.java.binaries=./target/classes

Effectively, the host and token can be injected through env vars 👍

[TomerFi]

@cruddasj

Weird... 😕 I actually tried that based on the documentation example before opening this issue and it didn't work for me.

I'm going to try that again, maybe I missed something the first time.

Thanks!!

[cruddasj]

@TomerFi - no worries. If it helps (purely from a baselining perspective), we're currently running Drone 1.1.0 with the above working well. It's also worth noting that the $sonar_host and $sonar_token vars won't work if they are wrapped in braces (unlike the drone repo variables).

[TomerFi]

@cruddasj

won't work if they are wrapped in braces

That did the trick! Thank you! 👍