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.

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