===== CurryDEBs ===== Bei CurryDEBs handelt es sich um [[admin:info:jenkins|Jenkins]]-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. ==== Hinweise zum Release-Workflow ==== Für das Veröffentlichen von Releases reicht das einfach "taggen" eines Git commits nicht aus, um die CurryDEBs ordnungsgemäß bauen zu lassen. Daher hier eine Empfehlung für den Release-Workflow: * Arbeiten am Code soweit abschließen, dass der Code bereit ist für eine Veröffentlichung als neue Version Die Code Änderungen dann erstmal auf den (meist) "master" Branch des jeweiligen Git Projekts pushen. Nach einigen Minuten starten die Jenkins-Builds für das Software-Projekt auf dem Jenkins-Server der AG: https://jenkins.ps.informatik.uni-kiel.de/view/CurryDEBs/ Auch die Curry-Tests sollen entsprechend erfolgreich sein: https://jenkins.ps.informatik.uni-kiel.de/view/CurryTests/ Laufen die entsprechenden Tests und die Builds gegen alle konfigurierten Distributions-Versionen durch, dann kann das Release gemacht werden: * Upstream-Version auf die neue Version setzen (z.Bsp. im Makefile, im .cabal File, o.ä.) * insb. bei curry-frontend: Abhängigkeit zu curry-base im .cabal File anpassen * Upstream-ChangeLog updaten (falls noch nicht up-to-date) * debian/changelog: Paketversion auf Upstream-Version anpassen, ggf. Datum des changelog-Dummy-Eintrags anpassen * debian/control: versionierte (und andere) Abhängigkeiten prüfen und ggf. anpassen * insbesondere: curry-frontend, curry-base Abhändigkeiten (unter Build-Depends: und unter Depends:) Alle Änderungen als Release-Commit ins Git Repository committenm, dann auf diesen Commit den Git Release-Tag setzen. Das ganze dann ist Git pushen: $ git push origin master:master && git push --tags Um die CurryDEB Release-Builds dann noch anzuschubsen, muss auf die entsprechenden Release-Branches der neue Code gemerged werden: == PACKS == git checkout release/2.x git merge master git push origin release/2.x:release/2.x == Curry Base / Frontend == git checkout release-builds git merge master git push origin release-builds:release-builds ==== Build Environment ==== Für die CurryDEBs-Builds nutzt das Jenkins der AG die Build-Nodes CHEVALBLANC und PORTY (beide Debian stable). Das grundlegende Build-Tool ist [[https://wiki.debian.org/sbuild|sbuild]]. In Jenkins läuft ein [[https://git.ps.informatik.uni-kiel.de/curry/curry-buildscripts/blob/master/bin/sbuild-deb-package|Build-Script]], welches via ''sbuild'' in dedizierten chroot-Umgebungen Debian- und Ubuntu-konforme Pakete baut und diese dann in ein APT-Paketarchiv zur Installation unter gängigen Debian- und Ubuntu-Versionen bereitstellt. Hier die APT-Archiv Info-Seite: https://packages.ps.informatik.uni-kiel.de/curry/ Die Übersicht über die CurryDEBs Builds ist hier: https://jenkins.ps.informatik.uni-kiel.de/view/CurryDEBs/ Es gibt verschiedene Build-Klassen: * nightly Builds (Endung: ''.deb+nightly'') * release Builds (Endung: ''.deb+release'') * PAKCS 1.14 (legacy) Builds (Endung: ''.deb+pakcs-1.14'') * PAKCS 1.15 (legacy) Builds (Endung: ''.deb+pakcs-1.15'') Diese unterschiedlichen Build-Klassen werden von folgenden Git Branches gebaut: * nightly Builds: master Branch * release Builds: release-builds Branch (master wird nach Release gemerged auf diesen Branch * PAKCS 1.14 (legacy) Builds: release/1.14.x Branch (''pakcs''), release/0.4.x (''curry-base'', ''curry-frontend'') * PAKCS 1.15 (legacy) Builds: release/1.15.x Branch (''pakcs''), release/0.4.x (''curry-base'', ''curry-frontend'') ==== Build Konzept ==== Jedes Paket, dass via CurryDEBs gebaut wird, muss für jede Distro-Version mindestens einmal gebaut werden (amd64 arch:all und arch:any Builds). Pakete, die architekturabhängig sind, werden dann nochmal für i386 gebaut (arch:any only Builds). Nachdem jedes einzelne Paket gebaut wurde, werden alle Source- und Binär-Pakete in das [[http://packages.ps.informatik.uni-kiel.de/curry|APT-Paketarchiv]] (gehostet auf dem Webserver der AG) hochgeladen. Auf den Build-Nodes CHEVALBLANC und PORTY existiert je ein User-Account ''curry-builder''. Der Jenkins-Master kontaktiert diese Build-Accounts via SSH und startet darüber den Jenkins-Slave Prozess, mit dem Jenkins-Master seine Slave-Nodes kontrolliert. Die Distro-spezifischen Builds werden von Jenkins über eine im Build-Job definierte 1dim Matrix aufgerufen (Liste der Debian und Ubuntu-Distros, für die Pakete gebaut werden sollen). ==== Build Voraussetzungen ==== === Upstream Code Maintenance === In den Upstream-Projekten der CurryDEBs Builds (aktuell: ''curry-base'', ''curry-frontend'', ''pakcs'') müssen die Upstream-Maintainer den Ordner ''debian/'' adequat pflegen. Hierzu gehört: * vor jedem Upstream-Release die Datei debian/changelog mit der neuen Upstream-Version (mit Präfix "2:" und Suffix "-0") aktualisieren * nach jedem Release, den master-Branch des Projekts mergen auf den Branch "release-builds". Diese Merges sollten immer fast-forward Merges sein. Falls nicht, dann stimmt was nicht. * master Branch und release-builds Branch sowie Release Tags ins Upstream Git Repo pushen * nach jedem offiziellen Debian-Upload alle sinnvollen Änderungen des Debian-Paket-Maintainers integrieren in Upstream's ''debian/'' Ordner === Build-Node Maintenance === **Hinzufügen einer neuen Distro-Version: ** Auf den Build-Nodes CHEVALBLANC und PORTY müssen mehrere Build Chroots für Tool [[https://wiki.debian.org/Schroot|schroot]] angelegt worden sein (''sbuild'' setzt auf ''schroot'' auf). Für jede neu hinzukommende Debian- und/oder Ubuntu-Version muss solch ein Chroot einmalig angelegt werden. Es werden pro Distro-Version immer ein amd64-Chroot und ein i386-Chroot angelegt (solange i386 noch unterstützt wird). Hier z.Bsp. für Debian unstable: # cd /srv/schroot/curry-builder # debootstrap sid ./sid-amd64-sbuild http://localhost:3142/debian # chroot sid-amd64-sbuild # apt install eatmydata build-essential # exit # debootstrap --arch=i386 sid ./sid-i386-sbuild http://localhost:3142/debian # chroot sid-i386-sbuild # apt install eatmydata build-essential # exit Analog für Ubuntu bionic: # cd /srv/schroot/curry-builder # debootstrap sid ./bionic-amd64-sbuild http://localhost:3142/ubuntu # chroot bionic-amd64-sbuild # apt install eatmydata build-essential # exit # debootstrap --arch=i386 sid ./bionic-i386-sbuild http://localhost:3142/ubuntu # chroot bionic-i386-sbuild # apt install eatmydata build-essential # exit Jede Build-Environment muss dann dem Tool schroot bekannt gemacht werden, z.Bsp. durch folgende Konfigurationsdatei (zu platzieren in ''/etc/schroot/chroot.d/'': [curry-sid-amd64-sbuild] type=directory command-prefix=eatmydata union-type=overlay union-overlay-directory=/dev/shm/schroot/overlay description=Debian sid/amd64 autobuilder directory=/srv/schroot/curry-builder/sid-amd64-sbuild groups=root users=curry-builder root-groups=root,curry-builder root-users=curry-builder profile=sbuild aliases=curry-sid,curry-sid-amd64 [curry-sid-i386-sbuild] type=directory command-prefix=eatmydata union-type=overlay union-overlay-directory=/dev/shm/schroot/overlay description=Debian sid/i386 autobuilder directory=/srv/schroot/curry-builder/sid-i386-sbuild groups=root users=curry-builder root-groups=root,curry-builder root-users=curry-builder profile=sbuild aliases=curry-sid-i386 Die unterstützten Chroots / Distributions-Versionen müssen dem [[https://git.ps.informatik.uni-kiel.de/curry/curry-buildscripts/blob/master/bin/sbuild-deb-package|Build-Script]] in seiner [[https://git.ps.informatik.uni-kiel.de/curry/curry-buildscripts/blob/master/home/.buildscripts/curry.conf#L12|Config]] bekannt gemacht werden. Am besten macht man das über das Git-Repo die genannte Config Datei und aktualisiert dann den Ordner (ein Git working copy) ''~/buildscripts'' des Users ''curry-builder'' jeweils auf CHEVALBLANC und PORTY. **Aktualisierung der Build-Chroots: ** Eine Paket-Aktualisierung der Build-Chroots sollte regelmäßig, spätestens bei Build-Problemen auf neueren Distro-Versionen, durchgeführt werden (ca. vierteljährlich). Hierfür gibt es ein Skript auf jedem Build-Node (CHEVALBLANC und PORTY): # /root/bin/curry-upgrade-buildenv ==== Build Triggers ==== Die automatischen CurryDEBs-Builds werden von Jenkins selbst getriggert (durch Polling auf den Upstream Git-Repos). ==== Build Ablauf ==== Das [[https://git.ps.informatik.uni-kiel.de/curry/curry-buildscripts/blob/master/bin/sbuild-deb-package|Build-Script]] wird wie folgt aufgerufen: # cd $HOME/bin && ./curry-build+upload-deb-package [/] [] Es checkt das Git-Repository '''' aus (Basis-URL: [[https://git.ps.informatik.uni-kiel.de/curry|''curry''-Gruppe im GitLab der AG]]) und baut den darin enthaltenen Code mittels des Tools ''sbuild''. Das Skript kennt verschiedene ''''s (''nightly'', ''release'', ''pakcs-1.14'' und ''pakcs-1.15''). Diese Repo-Targets finden sich in der URL des Paket-Archivs wieder (vergl. [[http://packages.ps.informatik.uni-kiel.de/curry|Doku des CurryDEBs APT Archiv]]). Das Skript kann ein Upstream-Projekt (mit enthaltenem Debian-Ordner) gegen verschiedene ''''s bauen (vergl. [[https://git.ps.informatik.uni-kiel.de/curry/curry-buildscripts/blob/master/home/.buildscripts/curry.conf|Konfiguration im Buildscripts Git Repo]]). Lässt man den '''' aus, wird gegen alle unterstützen Distro-Versionen gebaut. Falls man von einem ganz bestimmten Git Branch des Upstream-Projekts das Paket bauen will, kann ein '''' optional auch mit angegeben werden. Für arch:any Pakete werden dann je Distro-Version zwei Builds durchgeführt (amd64, i386). Pakete vom arch:all Typ werden nur auf amd64 gebaut (und können auf i386-Rechner installiert werden). Waren die Builds erfolgreich, werden die gebauten Paket-Dateien in das CurryDEBs APT-Repository hochgeladen.