Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
|
admin:info:currydebs [2019-01-30 16:31] mga [CurryDEBs] |
admin:info:currydebs [2019-02-11 13:00] (aktuell) mga |
||
|---|---|---|---|
| Zeile 2: | Zeile 2: | ||
| 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. | 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: | ||
| + | |||
| + | <code> | ||
| + | $ git push origin master:master && git push --tags | ||
| + | </code> | ||
| + | |||
| + | Um die CurryDEB Release-Builds dann noch anzuschubsen, muss auf die entsprechenden Release-Branches der neue Code gemerged werden: | ||
| + | |||
| + | == PACKS == | ||
| + | |||
| + | <code> | ||
| + | git checkout release/2.x | ||
| + | git merge master | ||
| + | git push origin release/2.x:release/2.x | ||
| + | </code> | ||
| + | |||
| + | == Curry Base / Frontend == | ||
| + | |||
| + | <code> | ||
| + | git checkout release-builds | ||
| + | git merge master | ||
| + | git push origin release-builds:release-builds | ||
| + | </code> | ||
| + | |||
| ==== Build Environment ==== | ==== Build Environment ==== | ||
| Zeile 130: | Zeile 178: | ||
| <code> | <code> | ||
| - | # cd $HOME/bin && ./curry-build+upload-deb-package <upstream-project> <repo-target>/<distro-codename> <git-branch> | + | # cd $HOME/bin && ./curry-build+upload-deb-package <upstream-project> <repo-target>[/<distro-codename>] [<git-branch>] |
| </code> | </code> | ||
| - | Es checkt das Git-Repository ''<upstream-project>'' aus (Basis-URL: [[https://git.ps.informatik.uni-kiel.de/curry|''curry''-Gruppe im GitLab der AG]]) | + | Es checkt das Git-Repository ''<upstream-project>'' 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 ''<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. [[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 ''<distro-codename>''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 ''<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. | ||
| + | | ||
