Jenkins (Ausgeschaltet)

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

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):

  • BELLECOMBE: CurryTests auf Debian buster
  • PORTY und CHEVALBLANC: CurryDEBs

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).

Ü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 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>].

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.

/srv/dokuwiki/adminwiki/data/pages/admin/info/jenkins.txt · Zuletzt geändert: 2024-03-13 12:46 von hbs
CC Attribution-Noncommercial-Share Alike 4.0 International
Driven by DokuWiki Recent changes RSS feed Valid CSS Valid XHTML 1.0