====== 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: [[admin:info:currydebs|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 [[admin:info:currydebs|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/''. 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//GHC_VERSION//label/currytests[-]''. ===== 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.