This question already has an answer here:
A project I work on (eclipse/scanning) uses Travis and Sonar for continuous integration and code analysis.
Last week, I noticed that builds were failing at the sonar step with:
ERROR: Error during SonarQube Scanner execution
org.sonar.squidbridge.api.AnalysisException: Please provide compiled classes of your project with sonar.java.binaries property
After some research, I thought I'd fixed this by updating the addons: section (sonarqube to sonarcloud) and switching to using - mvn -q sonar:sonar rather than - sonar-scanner in the script: section of the .travis.yml file.
Now though, external pull requests (from forks) which make it past the integration tests are failing for a different reason at the sonar step:
$ mvn -q sonar:sonar
...
[ERROR] SonarQube server [http://localhost:9000] can not be reached
[ERROR] Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin:3.3.0.603:sonar (default-cli) on project org.eclipse.scanning: Unable to execute SonarQube: Fail to get bootstrap index from server: Failed to connect to localhost/127.0.0.1:9000: Connection refused (Connection refused) -> [Help 1]
This appears to be related to earlier differences in the log:
Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#Pull-Requests-and-Security-Restrictions
and an entirely missing SonarCloud addon section.
To see the difference, compare the failed build #625 (which was a pull request from a forked repo) with the successful build #628 (which was a pull request from within the repo).
Around a month ago, external pulls work without issue, for instance build #536 passed, having run Setting environment variables from repository settings, SonarCloud addon and sonar-scanner correctly.
Subsequent builds however, such as build #538 passed, but only because sonar-scanner skipped analysis and exited with 0 even though they failed to run.
While I could probably just disable Sonar on external pull requests, it would be nice if I could fix our repository so we got both integration tests and code analysis on both internal and external pull requests, so
- Was my original fix the correct one?
- If so, how do I get it to work with both internal and external pull requests?
- If not, how should I have fixed the original problem?
Note, this question has been superceded by How do I get Sonarcloud to run on pull requests from forks with Travis, Maven & github which is focussed on the underlying problem rather than trying to fix some of the symptoms.
Your PR analysis is attempting (and failing) to use the default server: localhost:9000.
In another circumstance, you would update settings.xml to specify the location but since you're using Travis, you'll pass it on the command line instead: mvn sonar:sonar -Dsonar.host.url=https://sonarcloud.io
BTW, this is working in your normal Travis build because the SonarQube integration for Travis is specifically a Travis-SonarCloud integration, so server is filled in automatically.
you can try to delete the directory data/es of your Sonar Qube. then restart yoyr SonarQube, SonarQube will be recreate all the ES indexe.
来源：https://stackoverflow.com/questions/45573102/sonarcloud-failure-with-travis-maven-github