Bei CurryDEBs handelt es sich um 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.

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:

git checkout release/2.x
git merge master
git push origin release/2.x:release/2.x

git checkout release-builds
git merge master
git push origin release-builds:release-builds

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)

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

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

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

Die automatischen CurryDEBs-Builds werden von Jenkins selbst getriggert (durch Polling auf den Upstream Git-Repos).

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) und baut den darin enthaltenen Code mittels des Tools sbuild.

Das Skript kennt verschiedene <repo-target>s (nightly, release, pakcs-1.14 und pakcs-1.15). Diese Repo-Targets finden sich in der URL des Paket-Archivs wieder (vergl. Doku des CurryDEBs APT Archiv).

Das Skript kann ein Upstream-Projekt (mit enthaltenem Debian-Ordner) gegen verschiedene <distro-codename>s bauen (vergl. Konfiguration im Buildscripts Git Repo). Lässt man den <distro-codename> 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 <git-branch> 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.