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:46] mga [Build Ablauf] |
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 145: | Zeile 193: | ||
Waren die Builds erfolgreich, werden die gebauten Paket-Dateien in das CurryDEBs APT-Repository hochgeladen. | Waren die Builds erfolgreich, werden die gebauten Paket-Dateien in das CurryDEBs APT-Repository hochgeladen. | ||
| | ||
- | |||
- | |||