Dies ist eine alte Version des Dokuments!
Inhaltsverzeichnis
CurryDEBs Automatische 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.
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 sbuild. In Jenkins läuft ein 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 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 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 Build-Script in seiner 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 Build-Script wird wie folgt aufgerufen:
# cd $HOME/bin && ./curry-build+upload-deb-package <upstream-project> <repo-target>/<distro-codename> <git-branch>
Es checkt das Git-Repository <upstream-project>
aus (Basis-URL: ''curry''-Gruppe im GitLab der AG)