10.4.1.88267 (SonarQube, Scanner, Plugin, and any relevant extension)
Docker
Hello everyone, I have used Sonarqube before, which is a great tool that helps me identify and solve many coding problems. However, due to some reasons, I haven’t used it for a while. Recently, I tried to use it again. After using Docker to build version 10.4, I scanned the code using Gitlab ci. However, I encountered an issue with a multi module project for Maven, Nested a lot (as a dependency library), when I scanned this project, it prompted me that the name of a certain project file exceeded the preset 400 character length limit. This was not encountered before when I used Sonarqube. Later, I checked community support and found that due to database field length limitations, Sonrqube can only store data up to 400 words long. I think this limitation is somewhat unreasonable, Can we consider using hash values as an alternative? I should be able to solve this problem, thank you
By the way, the current LTS version (9.9) does not have this issue and all work is running well. I hope the new version can solve this problem as soon as possible. To be honest, I really like the new UI, hahaha
Are you saying that if you run exactly the same analysis against 9.9 and 10.4.1, the 9.9 analysis succeeds and the 10.4.1 analysis fails?
If so, can we have the logs from both analyses?
The analysis / scanner log is what’s output from the analysis command. Hopefully, the log you provide - redacted as necessary - will include that command as well.
[ERROR] Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin:3.9.0.2155:sonar (default-cli) on project xxxxxxxxx: Component key (xxxxxxxxxxxx:xxxxxxxx.java) length (403) is longer than the maximum authorized (400) → [Help 1]
I used gitlab ci, which is the error he encountered. In version 9.9, projectKey was passed through the mvn command, while in version 10.4, it was passed through the pom file attribute of Maven. Therefore, in 10.4, if it is a multi-module project, there will be a problem of duplicate keys. Through the community, I used the moduleKey attribute to mark different modules, but the problem of names exceeding the limit still exists
Firstly, all the commands I used came from the boot page after Sonarqube introduced the Gitlab project. In 9.9, Sonarqube did not add the properties attribute of projectKey in the pom file, but instead provided this attribute in the Gitlab ciyml mvn - s. m2/settings.xml verify Sonar: Sonar - Dsonar. projectKey=xxxx. In 10.4, by adding the properties attribute of projectKey in the pom file, there is no additional - Dsonar.projectKey parameter in gitlab ciyml. All commands come from the Sonarqube project creation guide. In order to control variables, I used a unified Docker image as the runner (Maven: 3 eclipse temurin-17). As for the complete logs, since I have migrated to 9.9, only the error logs in GitLab are available. I have intercepted the error section, and the rest are normal Maven
I have discovered and exposed this issue by official personnel in the community, and the reason is also clear. It is because the default generated projectKey is too long, and in projects with multiple nested modules, the file name path is too long. Adding the two to identify a file exceeds the limit set by sonarqube. However, in 9.9, the default generated projectKey is shorter, so this problem did not occur (since this problem was not encountered before, it is uncertain whether earlier versions have this limit). I hope that the official can discover and increase the priority of solving this problem, as this restriction cannot be proactively lifted by the client. If it is necessary to adjust the project structure to adapt, I think it is unreasonable.
The root cause: did the server change (I’m skeptical), the scanner behavior, or did your change in scanner invocation uncover something that was there before?
I first used 10.4 and then went back to 9.9, both using the same ci image and mvn command. However, 10.4 encountered an issue with excessively long paths. To test this issue, I only need to build a Maven project that contains a single file and use overly long package names internally to wrap a file