Installation

Um Jenkins nun zu verwenden, ist zuerst einmal das entsprechende Software-Repository einzubinden:

# sudo wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat/jenkins.repo
# sudo rpm --import http://pkg.jenkins-ci.org/redhat/jenkins-ci.org.key
# sudo yum install -y jenkins
# sudo /etc/init.d/jenkins start

Für nicht RPM-basierte Distributionen steht auf der Jenkins-Projektseite ein entsprechendes War-Archiv zur Verfügung.

Im Anschluss lauscht Jenkins auf Port 8080 auf eingehende Requests. Ruft man die Seite nun also im Webbrowser auf, steht auf der linken Seite ein Auswählmenü zur Verfügung. Um ein neues Projekt anzulegen, wählt man hier dann »New Job« aus. Über den Menüpunkt »Build a freestyle Software project« ( Abbildung 2 ) gelangt man dann schließlich in den eigentlichen Konfigurationsdialog. Hier ist das Versionskontrollsystem, das Build-Tool und optional das Test-Tool zu spezifizieren. Für das automatische Erzeugen von RPM-Pakten, um das es hier geht, benutze ich das einfache Skript in Listing 1 . Es ist als Build-Tool in Jenkins einzutragen und stößt den entsprechenden RPM-Build an ( Abbildung 3 ).

Abbildung 2: Mit Jenkins lassen sich unterschiedlichste Software-Projekte managen.

Das Ganze setzt natürlich voraus, dass der Subversion-Checkout in einem Unterordner »foo« erfolgt. Diese Info kann ich Jenkins mit übergeben. Hier sollten dann neben dem RPM-Spec-File und dem Build-Skript natürlich alle Dateien liegen, die in das RPM zu integrieren sind. Um ebenfalls ein sauberes SRPM zu erhalten, wird aus den Sourcen noch ein Archiv gebaut, welches mit in das SRPM einfließt. Die For-Schleife erzeugt dann im Projektordner unterhalb von »/var/lib/jenkins/workspace/« eine entsprechende RPM-Buildstruktur.

Makros definiert

Damit der Aufruf von »rpmbuild« auch tatsächlich funktioniert, muss das Tool wissen, dass seine Build-Umgebung jetzt im Jenkins-Projektordner liegen soll. Diese Information kann ich beim Aufruf mittels des »topdir« -Makros zwar mit angeben, eleganter ist es jedoch, diese Info einfach mit in das Spec-File aufzunehmen. Im Header der Datei definiere ich hierfür einfach zwei neue Makros, die ich dann im weiteren Verlauf der Spec-Files verwenden kann:

%define _topdir %(echo `pwd`)
%define BUILD_NUMBER %(echo $SVN_REVISION)

»BUILD_NUMBER« bezieht sich auf die SVN-Revision. Hierfür stellt Jenkins netterweise eine entsprechende Variable zur Verfügung. Von diesen Variablen kennt Jenkins eine ganze Menge, die Dokumentation [2] stellt eine ganze Liste davon zur Verfügung. Die »BUILD_NUMBER« verwende ich im RPM-Spec-File dann einfach als RPM-Revision. Der Header im Spec-File kann somit beispielsweise folgende Zeilen enthalten:

Name : foo
Summary : foo application
Version : 42
Release : %{?BUILD_NUMBER}

Durch den Aufruf von »Build Now« oder durch einen neuen Checkin ins Repository, wird der Build angestoßen. Hat alles geklappt, sollte das neu gebaute RPM-Paket im Jenkins-Projektverzeichnis im Unterorder RPMS zu finden sein. Jenkins stellt eine Reihe von unterschiedlichen URLs zur Verfügung, mit denen man beispielsweise auch auf das zuletzt erzeugte RPM-Paket referenzieren kann. Eine solche URL könnte dann wie folgt lauten:

http://localhost:8080/job/foo-jenkins-project/lastSuccessfulBuild/

Eine Übersicht sämtlicher URLs und RSS-Feeds stellt Jenkins auf der Projektseite zur Verfügung. Dort ist auch eine entsprechende Grafik zu finden, die einen Build-Trend für das Projekt anzeigt. Hoffentlich scheint dort meist die Sonne.

An dieser Stelle sind dann natürlich jede Menge weitere Aktionen möglich. Beispielsweise könnte man das soeben erzeugte RPM automatisch auf einen Spacewalk-Server laden, um es von dort auf die Test-Systeme zu deployen. Jenkins bietet hier noch viele Möglichkeiten – nicht zuletzt durch die vielen nützlichen Plugins. (cth/ofr)

Der Autor

Thorsten Scherf arbeitet als Senior Consultant für Red Hat EMEA. Er ist oft als Vortragender auf Konferenzen anzutreffen. Wenn neben Arbeit und Familie noch Zeit bleibt, nimmt er gerne an Marathonläufen teil.