Sonar Scanner plugin version is sonar-maven-plugin:3.7.0.1746 . The server is SonarQube version: 6.7.6 and the database backend is PGSQL version 9.6.10
Log file (debug in TRACE mode) : ce.log.gz.txt (714.7 KB) (this is a gzip file renamed to .txt in order to upload)
Reproduced by analyzing the project GitHub - xwiki/xwiki-platform: The XWiki platform , source code from tag xwiki-platform-11.8.1. The issue happen when the analysis trigger on server side (on scanner side, everything runs successfully).
potential workaround: find out the field name that cause the problem and strip it, but I can’t say what it is for sure !
You can look at the log file for the error specified in the topic’s title ERROR: value too long for type character varying(2000). I’m unable to understand what’s going on.
You’re right that there’s not a lot to go on, but I do notice this in the error message:
Visit failed for Component {key=org.xwiki.platform:xwiki-platform-store-transaction,type=MODULE}
I also notice that you’re on 6.7.6. We dropped server-side treatment of modules on the way to 7.9.1, the current LTS. Could you try upgrading to either 7.9.1 or 8.0, the current version, and seeing if the problem persists?
Hi, thank you for the answer. The thing is we have external systems that rely on SonarQube webservice API so I need to make sure that it’s not gonna break anything. Is there a way to see backward compatibility changes in the API?
I’m afraid I don’t have an easy answer for you. You can check the release notes of the intervening versions to see what web service changes there are. Or you could stand up a test instance of 8.0 and point the test instances of those external systems at it and see what breaks.
But generally we follow our deprecation/removal policy pretty strictly, so unless those external systems are using services that were already deprecated in 6.7 you’re probably okay. If you know what web services they’re using, you can check the onboard documentation (there’s a link in your footer) for deprecation notices.