Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- admin:info:jenkins [2016-08-31 12:32]
bjp
+++ admin:info:jenkins [2024-03-13 12:46] (aktuell)
hbs [CurryTests Builds]
@@ Zeile 1: / Zeile 1: @@
-====== Jenkins ======
+====== Jenkins (Ausgeschaltet) ======
-Auf dem Rechner ''siran'' ist das Continuous-Integration-Tool ''jenkins'' installiert, dessen Weboberfläche über http://siran.informatik.uni-kiel.de:8080/ erreichbar ist. Jenkins kann dafür benutzt werden eventbasiert oder zeitgesteuert bestimmte Aufgaben durchzuführen. An der Arbeitsgruppe wird Jenkins derzeit insbesondere eingesetzt um:
+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
-''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 authorisierten Schlüssel zu hinterlegen. Die Aktualisierung erfolgt bequem über die reguläre Paketaktualisierung, jediglich die nachträglich installierten Plugins müssen manuell über http://siran.informatik.uni-kiel.de:8080/pluginManager/ aktualisiert werden.
+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):
-Administratoren von Jenkins sind derzeit Björn, Jan und Mike (Stand August 2016), langfristig ist es sicherlich sinnvoll den Dienst unter einem eigenen Rechner zur Verfügung zu stellen und die Administration dem Administrator der AG zu überlassen.
+  * 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/<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.