Sonar Migration
Das Problem
Häufig kommt es vor, dass ein Projekt von einer Sonar-Instanz in eine andere umziehen muss. Das kann ein aktuellerer Server oder eine andere Sonar-DB sein. Bei einem Umzug sind zwei Dinge wichtig: Die Historie sollte erhalten bleiben und besondere Einstellungen wie z.B. gekennzeichnete False Positives sollen übernommen werden.
Lösungen
Im Netz finden sich für diese beiden Punkte zwei Vorschläge. Unter https://github.com/awltech/sonar-data-migrator/wiki/iii.-Using-Sonar-Data-Migrator gibt es eine Anwendung “Sonar Data Migrator”, die Sonardaten für von einer Sonar-Instanz in eine andere Sonar-Instanz kopiert und unter https://gist.github.com/aslakknutsen/2422117 findet man ein Blogpost mit einem Shellskript, das die Historie eines Projekts “nachbaut”, indem für jedes git Tag dieser Stand mit dem zugehörigen Datum nach Sonar importiert. Dieses Skript funktioniert prinzipiell, aber bei größeren Projekten sind einige Randbedingungen zu beachten. Wenn man beide Lösungen gegenüberstellt, ergeben sich folgende Vor- und Nachteile.
Methode
|
Pro
|
Kontra
|
---|---|---|
Sonar Data Migrator |
|
|
Import via Shellskript |
|
|
Unser Vorgehen
Wir schlagen daher vor, zuerst die Historie mit dem Shellskript zu erzeugen und anschließend die zusätzlichen Sonardaten mittels des Sonar-Data-Migrators zu übernehmen. Zuvor sind aber einige Probleme des alten Shellskripts zu beheben.
Tagproblematik
Mögliche Probleme:
- Es gibt ein Start-Tag, aber es sollen oder können nicht alle folgenden Tags importiert werden.
- die Tags sind nicht rein numerisch, so dass diese sich nicht einfach über eine Größer-Abfrage wie im originalen Skript Zeile 16 unterscheiden lassen.
Diese beiden Punkte lassen sich nach meiner Erfahrung dadurch umgehen, indem man sich die Tags vorher ausgeben lässt, diese in eine Datei speichert, anpasst und dann über die Zeilen in dieser Datei iteriert. Im neuen angepassten Shellskripts (s.u.) stehen die zu importierenden Tags in der Datei tags.list
.
Profile und Parameter
Der nächste Punkt sind eventuelle Profile und sonstige Einstellungen, mit dem die bisherigen Sonarimporte abliefen. In der Regel sind das CI-Jobs, bei denen man in die Konfiguration schauen sollte. Diese Einstellungen sind dann in das neue Shellskript zu übernehmen. Im neuen Shellskript sind diese in der Variablen SONAR_COMMAND
enthalten.
Sonarkonfiguration
Als nächstes Punkt ist zu beachten, das der Projekt-Pom möglicherweise keine Einstellungen für Sonar enthält. Insbesondere wenn die Sonar-Jobs über Jenkins oder Hudson laufen, sind dort die notwendigen Konfigurationsdaten hinterlegt und fehlen damit für das Skript. Im neuen Shellskript sind diese in der Variablen SONAR_PROPERTIES
enthalten.Zusätzlich ist wichtig, dass der JDBC-Treiber für die benutzte Datenbank (MySQL in diesem Beispiel) unter der URL $SONAR_URL/jdbc-driver.jar
erreichbar ist, da es ansonsten zu Fehlermeldungen der Art "Fail to download the file: http://localhost/sonar/jdbc-driver.jar"
kommt.
Hier jetzt das neue Script
#!/bin/bash GIT_REPO=$1 MVN_COMMAND="mvn clean install" SONAR_COMMAND="mvn -Pbootstrap sonar:sonar" SONAR_PROPERTIES="-Dsonar.jdbc.driver=com.mysql.jdbc.Driver \ -Dsonar.jdbc.url=jdbc:mysql://localhost:3306/sonar?useUnicode=true&characterEncoding=utf8 \ -Dsonar.host.url=http://localhost/sonar" if [ -z "$GIT_REPO" ]; then echo "Missing program argument: repository" echo "Usage: ./sonar_history.sh git_repository_path" exit fi pushd $GIT_REPO for tag in `cat ../tags.list` do TAG_DATE=`git show $tag --date=iso | grep Date: -m1 | cut -d' ' -f 4` echo "Checking out source from $TAG_DATE tagged as $tag" git checkout $tag > /dev/null 2>&1 git clean -df > /dev/null 2>&1 SONAR_PROJECT_COMMAND="$SONAR_COMMAND $SONAR_PROPERTIES -Dsonar.projectDate=$TAG_DATE" echo "Executing Maven: $MVN_COMMAND" $MVN_COMMAND > /dev/null 2>&1 echo "Executing Sonar: $SONAR_PROJECT_COMMAND" $SONAR_PROJECT_COMMAND > /dev/null 2>&1 done popd