Dies ist eine alte Version des Dokuments!
Inhaltsverzeichnis
Jenkins
Auf dem Rechner LYNCH ist das Continuous-Integration-Tool jenkins
installiert, dessen Weboberfläche über https://jenkins.ps.informatik.uni-kiel.de/ erreichbar ist. Jenkins kann dafür benutzt werden eventbasiert oder zeitgesteuert bestimmte Aufgaben durchzuführen. An der Arbeitsgruppe wird Jenkins derzeit insbesondere eingesetzt um:
- Bei den installierten Webanwendungen automatisch die Installierbarkeit zu testen und alle Testfälle auszuführen
- Bei den Curry-Systemen und verwandten Repository die Installation zu testen und Testfälle auszuführen
- DEB-Pakete verschiedener Curry-Komponenten für Debian und Ubuntu zu bauen
Dem Jenkins-Master Server (welcher selbst gar keine Build-Projekte abarbeitet) nutzt view Build-Slaves:
- PORTY und CHEVALBLANC: CurryDEBs
- SIRAN: CurryTests auf Debian oldstable
- LEPIN: CurryTests auf Debian stable
jenkins
ist direkt als Debian-Paket installiert und läuft unter dem bei der Installation angelegten User jenkins
. Für etwaige Fehlersuchen ist es deshalb ratsam, den öffentlichen SSH-Key der Administratoren als autorisierten Schlüssel zu hinterlegen. Die Aktualisierung erfolgt bequem über die reguläre Paketaktualisierung, jediglich die nachträglich installierten Plugins müssen manuell über https://jenkins.ps.informatik.uni-kiel.de/pluginManager/ aktualisiert werden.
Administratoren von Jenkins sind derzeit Finn, Mike und Jan (Stand Januar 2019).
Überblick über die Jenkins-Builds der AG
Derzeit (Stand Januar 2019) gibt es an der AG zwei Kategorien von Builds der Curry-Systeme, CurryDEBs und CurryTests.
CurryDEBs Builds
Bei CurryDEBs handelt es sich um Builds, die mit den veröffentlichten
Debian-Paketen des PAKCS Curry-Compilers assoziiert sind.
Dazu zählen Builds des Curry-Frontends bestehend aus den Haskell-Paketen
curry-base
und curry-frontend
(Branch: /release/0.4.x
) sowie Builds des
PAKCS in den Versionen 1.14.x und 1.15.x.
CurryTests Builds
In die Kategorie CurryTests hingegen werden die Entwicklungsversionen der
Curry-Compiler (master
-Branches) auf ihre Installierbarkeit hin getestet.
Es gibt Builds des Curry-Frontends, also der Haskell-Pakete curry-base
und
curry-frontend
, Übersetzung der Curry-Bibliotheken curry-libs
sowie der
Curry-Werkzeuge curry-tools
mit dem PAKCS (Version 2.x) und KiCS2
(Version 1.x) Curry-Compilern sowie Testbuilds der Compiler selbst,
wobei im Falle des PAKCS auch noch eine Version ohne Typklassen (Release 1.15.x)
getestet wird.
Außerdem werden noch der Bootstrapping-Vorgang des KiCS2 mit Hilfe des PAKCS
sowie Builds der Curry-Such-API currygle
sowie des Partiellen Auswerters für
Curry-Programme peval
getestet.
Durchgeführt werden die meisten der Builds jeweils auf zwei unterschiedlichen
Testsystemen, siran
und lepin
.
Auf siran
läuft Debian 8 (jessie) und auf lepin
Debian 9 (stretch).
Falls man sich die Builds lokal auf Dateisystemebene ansehen bzw. sie debuggen
möchte, so kann man sich als Nutzer curry-tester
auf den jeweiligen Systemen
einloggen. Dazu muss nur der öffentliche SSH-Key entsprechend als autorisierter
Schlüssel hinterlegt werden.
Lokal sind die Builds auf dem jeweiligen System unter dem relativen Pfad
jenkins/workspace/<project name>
.
Bei den Haskell-basierten Builds (curry-base
, curry-frontend
und
kics2
) wird noch nach der verwendeten GHC-Version unterschieden.
Diese werden bei der Konfiguration eines Jenkins-Projekts durch die Definition
einer Umgebungsvariablen $GHC_VERSION
festgelegt (siehe unten).
Für jede angegebene Version des GHC wird das zum Jenkins-Projekt zugehörige
git-Repository ausgecheckt und ein eigener Build durchgeführt.
Die ausgecheckten Daten sowie den Build findet man dann unter dem relativen
Pfad jenkins/workspace/<name of haskell-based project>/GHC_VERSION/<ghc version>/label/currytests[-<debian version>]
.
Konfiguration eines Jenkins-Projekts
Wenn man ein neues Jenkins-Projekt anlegt, kann man einige Konfiguration vornehmen.
General
Hier kann man unter anderem eine kurze Beschreibung des Projekts angeben und festlegen, wie viele (alte) Builds pro Projekt maximal aufgehoben werden sollen.
Source Code Management
Hier wird die URL des auszucheckenden git-Repositories angegeben.
Zusätzlich kann auch festgelegt werden, welcher Branch ausgecheckt werden soll
und ob beispielsweise Submodules ausgecheckt und aktualisiert werden sollen
(vgl. kics2
).
Build Triggers
Hier kann konfiguriert werden, in welchen zeitlichen Abständen der Build
durchgeführt werden soll. Des Weiteren können hier auch Builds in Abhängigkeit
von Builds anderer Jenkins-Projekte getriggert werden.
Dies ist relevant für Projekte, die aufeinander aufbauen wie z.B. im Falle
des curry-frontend
-Projekts, das auf das curry-base
-Projekt
aufbaut.
Configuration Matrix
Hier kann man beispielsweise Umgebungsvariablen definieren, die für die Builds
verwendet werden.
Für die Haskell-basierten Jenkins-Projekte wird zum Beispiel die
Umgebungsvariable GHC_VERSION
definiert, um Builds mit unterschiedlichen
GHC-Versionen zu testen.
Des Weiteren kann man hier zuweisen, auf welchen Systemen Builds
durchgeführt werden sollen. Diese Build-Systeme werden durch sogenannte
Labels identifiziert.
Beispielsweise werden siran
und lepin
jeweils durch ein Label
identifiziert, nämlich currytests-jessie
bzw. curry-tests-stretch
.
So wird zum Beispiel für das Jenkins-Projekt curry-base.master
festgelegt, dass die Builds auf beiden Testsystemen durchgeführt werden
sollen.
Zusätzlich kann man diese Builds auch noch durch Constraints
(Combination Filter) beschränken, wenn beispielsweise nicht alle
Konfigurationskombinationen auf allen Testsystemen verwendet werden sollen.
Im Falle der CurryTests-Builds wird beispielsweise durch die Constraints
label==„currytests-jessie“ || (label==„currytests-stretch“).implies(GHC_VERSION>=„8.4.3“)
festgelegt, dass auf lepin
(Debian stretch) nur Builds mit GHC-Compilern
durchgeführt werden sollen, die mindestens die Version 8.4.3
aufweisen.
Build Environment
Hier kann man die Umgebung der Builds konfigurieren. Zum Beispiel kann man einstellen, ob der workspace vor einem Build gelöscht werden soll. Außerdem kann man unter anderem die Ausgabekonsole konfigurieren.
Build
An dieser Stelle werden die Befehle angegeben, die bei Durchführung eines
Builds ausgeführt werden sollen.
Bei den Curry-Test-Builds werden an dieser Stelle in der Regel die nötigen
Build-Tools wie der GHC oder einer der Curry-Compiler in den Pfad
eingebunden, Paketabhängigkeiten oder Pakete (z.B. mittels cabal
)
kompiliert bzw. installiert oder Befehle aus den Makefiles des zu testenden
Pakets/Compilers ausgeführt.
Post-build Actions
Hier können Einstellungen vorgenommen werden, was nach Durchführung eines Builds
gemacht werden soll.
Beispielsweise können Builds anderer Jenkins-Projekte angestoßen werden.
Dies passiert zum Beispiel im Falle der curry-base
-Builds (es werden
die curry-frontend
-Builds angestoßen, die das Paket curry-base
als Abhängigkeit benötigen).
Des Weiteren kann festgelegt werden, dass bestimmte Benutzer per E-Mail
benachrichtigt werden, falls ein Build fehlschlägt bzw. zuvor
fehlgeschlagene Builds wieder erfolgreich durchlaufen.