Manchmal ist es hilfreich, wenn man in einem Jenkins Job Zugriff auf Maven Projekt Properties wie project.artifactId oder project.version hat. Beispielsweise lässt sich so die nächst höhere Versionsnummer in einem Release Job ermitteln und setzen. Ein anderer Use Case, den ich vor kurzem in einem Projekt hatte, ist das Kopieren von Build Ergebnissen auf ein Netzlaufwerk mittels eines Shell Skripts. Damit dies funktioniert, muss dem Shell Skript der Name des zu kopierenden Artefakts übergeben werden. Aber wie soll das funktionieren, wenn sich der Artefaktname ständig ändert, weil die Version in der pom hochgezählt wird? Glücklicherweise gibt es in Jenkins eine einfache Möglichkeit auf diese Informationen zuzugreifen.

Gemappete maven Properties in Jenkins

Jenkins stellt allgemeine maven Projekt Properties als Umgebungsvariablen zur Verfügung. Natürlich funktioniert dies nur bei maven Build Jobs aber nicht bei Freestyle Jobs, welche nur maven Goals aufrufen. Dieses Feature wurde vor einer Weile implementiert , aber überraschender Weise ist es bisher noch nicht sonderlich gut dokumentiert. Die folgende Tabelle listet alle maven Projekt properties auf, welche auf Jenkins Umgebungsvariablen gemappt werden:

Beispiel

In meinem Projekt verwende ich ein gemanagetes Skript um die Ergebnisse eines maven Webstart Builds auf ein Windows Netzlaufwerk zu extrahieren. Das Build Ergebnis liegt als Zip Archiv vor. Da ich vom trunk deploye und sich die Versionsnummer dort häufig ändert (nach jedem Produktionsdeployment), muss ich den Namen des Archivs herausfinden und an das Skript übergeben. Mein Deployskript sieht in etwa so aus:

1DEPLOY_PATH=/mnt/webstart_deploy
2rm -rf $DEPLOY_PATH/*
3unzip target/$1 -d $DEPLOY_PATH

Das einzige, was ich jetzt noch machen muss, ist den Namen des Archivs als Parameter an das Skript übergeben: $POM_ARTIFACTID-$POM_VERSION.zip.

Sofern sie dies in ihrem Projekt ausprobieren: Ich hatte Schwierigkeiten die Windows Freigabe, auf die ich deployen will, richtig zu mounten. Man sollte deshalb sicher stellen, dass der User, welcher Jenkins ausführt, Schreibrechte in dem gemounteten Pfad hat. Wenn Jenkins als Service ausgeführt wird, ist der user „jenkins“. Die einzige Möglichkeit, um die Berechtigungen in meiner Umgebung richtig hinzubekommen, war beim Mounten die UID vom Jenkins User zu übergeben und diesen somit zum Besitzer des gemounteten Ordners zu machen. Außerdem benötigt man einen User in der Windows Domäne, welcher Zugriff auf die Freigabe hat:

1su root
2JENKINS_UID = id -u jenkins
3mount -t cifs -o user=<domain-user>,password=<domain-users-pw>,uid=$JENKINS_UID //remote_host/remote_dir /mnt/mount_point

Eine Alternative zur hier gezeigten Lösung ist die Verwendung des maven-antrun-plugins . Ich persönlich mag aber die Ant Syntax zur Beschreibung dieser Schritte nicht.