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:
Der Rechner LYNCH ist ein Jenkins-Master-Server, der selbst keine Builds ausführt. Der Jenkins-Master Server delegiert alle Jobs an folgende Build-Slaves (oder -Nodes):
Die Software jenkins
ist direkt als 3rd-party 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, Henrik und Jan (Stand November 2019).
Derzeit (Stand Januar 2019) gibt es an der AG zwei Kategorien von Builds der Curry-Systeme, CurryDEBs und CurryTests.
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.
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 unterschiedlichen
Testsystemen, bellecombe
und talbot
.
Auf bellecombe
läuft Debian 10 (buster) und auf talbot
Debian 11 (bookworm).
Man aktualisiert die agent.jar Dateien unter /var/lib/curry-tester/jenkins
mit
wget jenkins.ps.informatik.uni-kiel.de/jnlpJars/agent.jar
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>]
.
Wenn man ein neues Jenkins-Projekt anlegt, kann man einige Konfiguration vornehmen.
Hier kann man unter anderem eine kurze Beschreibung des Projekts angeben und festlegen, wie viele (alte) Builds pro Projekt maximal aufgehoben werden sollen.
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
).
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.
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.
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.
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.
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.