Je reçois l'avertissement Missing blame information for the following files
lors de l'analyse par SonarQube.
[INFO] [22:19:57.714] Sensor SCM Sensor
[INFO] [22:19:57.715] SCM provider for this project is: git
[INFO] [22:19:57.715] 48 files to be analyzed
[INFO] [22:19:58.448] 0/48 files analyzed
[WARN] [22:19:58.448] Missing blame information for the following files:
(snip 48 lines)
[WARN] [22:19:58.449] This may lead to missing/broken features in SonarQube
[INFO] [22:19:58.449] Sensor SCM Sensor (done) | time=735ms
J'utilise SonarQube 5.5, l'analyse est effectuée par Maven dans un travail Jenkins, sur un multi-module Java. Le plugin Git 1.2 est installé.
L'exécution manuelle de git blame dans un shell bash, sur l'un des fichiers incriminés, donne une sortie attendue.
Les questions connexes que j'ai trouvées concernaient toutes SVN, mon problème est avec Git.
Comment obtenir des informations sur Git Blame sur Sonarqube?
La cause était un bogue JGit . JGit ne prend pas en charge .gitattributes
. J'avais ident
dans mon .gitattributes
. Console simple git
extrait la source, appliqué ident
sur $Id$
macros, mais JGit a ignoré cela et a vu une différence qui n'était pas engagée, alors qu'il n'y en avait pas.
Les gens sympathiques de la liste de diffusion SonarQube m'ont aidé et ont suggéré le débogage avec distribution de ligne de commande JGit autonome :
chmod +x /where/is/org.Eclipse.jgit.pgm-<version>-r.sh
/where/is/org.Eclipse.jgit.pgm-<version>-r.sh blame -w /path/to/offending/file
Ce bogue particulier de JGit n'a pas été résolu depuis plus de 5 ans et je n'ai aucun espoir qu'il le sera bientôt, donc j'ai supprimé le $Id$
macros de toutes mes sources.
Voici le code (Bash) que j'ai utilisé pour supprimer tous les $Id$
macros:
find */src -name "*.Java" | xargs -n 1 sed -i '/$Id.*$/d'
find */src -name "*.Java" | xargs git add
git commit -m "Remove $Id$ macros"
git Push
J'ai eu un problème similaire: un fichier de mon projet a été créé pendant le processus de génération et n'a pas été stocké dans le contrôle de code source. Dans mon cas, c'était api.json
.
Dans l'étape de génération du runner SonarQube dans Team City, j'ai ajouté ce fichier aux exclusions dans les paramètres supplémentaires
-Dsonar.exclusions=**/spec/api.json
et l'erreur a disparu.
J'ai rencontré ce problème avec une version qui a cessé de fonctionner après une mise à niveau de Sonar.
Le problème pour moi était que le travail Jenkins était configuré pour faire un clone peu profond lors du tirage depuis git . Cela ne récupère pas suffisamment d'historique, de sorte que Sonar 5.6.6 n'a pas pu effectuer une analyse car les informations sur le blâme n'étaient pas incluses dans la copie superficielle. J'ai utilisé l'option X lors de l'exécution de Sonar pour afficher le numéro de validation réel sur lequel il s'étouffait.
Je suis dans mon cas J'ai simplement décoché la case de copie peu profonde et BAM, cela a fonctionné à nouveau (mais plus lentement)!