Debian Buildserver

[reox]

Irgendwie finde ich bei meiner suche immer nur die selben Seiten die mir aber nicht weiterhelfen, wie zB buildd...

Ich suche eine Möglichkeit um Debian Pakete auf meinem Server zu bauen und dann zB in ein reprepo einzuchecken. Sehr schön wäre es, wenn nur in VMs gebaut wird und die für jeden Build neu aufgesetzt werden um zB Probleme mit lokalen Setups zu vermeiden. Mir reicht mal fürs erste nur amd64 als Arch - wenn man ganz einfach andere auch integrieren kann ist das aber kein Fehler.
Auch ideal wäre wenn für verschiedene releases gebaut wird (also jessie, stretch, buster, sid, ...)
Die Pakete die ich bauen will sind eigentlich fast immer in git repos vorhanden. Also ein git clone && dpkg-buildpackage sollte meistens ausreichen (+abhängigkeiten installieren...).
Gebaut werden soll dann zB in periodischen abständen, falls neue commits da sind - also ein daily build system. Wenn man manuell die Builds anwerfen kann ist das auch nicht schlecht.
Sehr gut wäre auch noch wenn stabile versionen (anhand von tags im git) ebenfalls gebaut werden und im repo bleiben, so dass man gleich zwei varianten hat: testing und stable.

Gibt es da irgendwas?
Vermutlich kann man sich so eine Lösung mit jenkins o.Ä. auch selber bauen... Auch gibt es dieses Ding: https://build.opensuse.org/ wie ich erfahren habe, nur scheinbar kann man das nur komplett auf einem server installieren und nicht als dienst laufen lassen.
Und dann gibts ja zB Lauchpad, haben die ihr system vllt auch irgendwo?

[maltris]

Bezüglich deiner Idee, beim Buildprozess immer wieder neue VMs aufzubauen (wenn auch automatisiert), empfehle ich dir hierfür einfach Docker-Container für die unterschiedlichen Debian-Versionen. Dies ist in Benutzung einfacher sowie sauberer und im Hinblick auf verwendete Ressourcen meist effizienter. Laut Docker-Hub kommst du mit dem offiziellen Image zurück bis auf Wheezy [1], unter Zuhilfenahme des EOL-Repositories bis Potato [2].

Die Methode solltest du mehr oder weniger unabhängig von deiner Build-Pipeline (ob nun Jenkins, ein eigenes Konstrukt oder noch was anderes) einsetzen können. Ich hatte seinerzeit ein solches Konstrukt im Einsatz, um die in vielen Unternehmen, welche die eigene Paketierung von Software verfolgen, vorherrschenden, nie aktualisierten und verbastelten "Build-Maschinen" abzulösen. Durch die Containerisierung kann theoretisch der Build-Prozess sogar auf dem eigenen Desktop-PC stattfinden.

Eine Übersicht zu den Build-Services habe ich gefunden, dort ist auch launchpad und OBS aufgelistet und oberflächlich die Funktionsweise von OBS beschrieben [3].

[1] https://hub.docker.com/_/debian/
[2] https://hub.docker.com/r/debian/eol/
[3] https://en.opensuse.org/openSUSE:Build_ ... comparison

[TRex]

Ich schieb sowas auch noch vor mir her. Mir wurde nahegelegt, mal in #debian im IRC zu fragen (was ich vermutlich auch tun werde, sobald ich mit prokrastinieren fertig bin), ansonsten ziehe ich meine Erfahrung aus der Arbeit: Es gibt Plugins für Jenkins, mit denen dann Builds auf docker-Containern ausgeführt werden. Fallstricke sind wohl maßgeblich die immerwährenden Kompatibilitätsprobleme zwischen jenkins<->plugin<->docker. Hat man das im Griff, ist der Rest mit ein wenig Experimentierfreudigkeit relativ einfach zu meistern.

Ach ja: man will sich irgendwie die docker-Images bauen. Für mich selbst hätte ich gerne etwas kompaktes, und daran bin ich zuletzt gescheitert (Wunschvorstellung: ein jenkins-Job, der die Images baut und in die lokale registry committet). Wenn man das nicht nachvollziehbar aufzieht, hat man dasselbe Problem wie mit den

vorherrschenden, nie aktualisierten und verbastelten "Build-Maschinen"

(mir nicht unbekannt).

Jenkins hat da mittlererweile selbst ein "Portal" zu dem Thema docker:
https://jenkins.io/solutions/docker/

[novalix]

Hi,
möglicherweise reicht Dir ja schon pbuilder für Deine Anforderungen. OK, ist nur ein einfaches chroot. Das lässt sich nicht so eindrucksvoll stapeln wie die ganzen Docker-Container.

https://pbuilder.alioth.debian.org/

[reox]

Ich dachte mir das schon, dass es wohl eine halbe selbstbaulösung werden wird

vom pbuilder hatte ich schonmal gehört, den sollte ich mir vllt nochmal genauer ansehen.
Der Vorteil von einem Jenkis wäre aber, dass man jederzeit vermutlich noch andere Distributionen dazupacken kann... Ich hatte schonmal die Aufgabe rpms zu bauen, dann kann man sich schnell ne CentOS VM holen und das recht schnell integrieren.
Oder wenn man python pakete auch als wheel bauen will...
Docker Container klingt jetzt auch nicht falsch. kvm hab ich halt schon am laufen und mir auch ein script gebaut, welches neue VMs recht schnell erstellen kann. Damit hab ich derzeit manche pakete so semiautomatisch gebaut.

[tijuca]

KVM, Docker oder was man sonst noch so an Vorstellungen hat ist alles nicht nötig um eigene Pakete zu bauen. Die "offiziellen" Paketbauer und Maintainer benutzen entweder pbuilder oder sbuild dafür. Beide Systeme setzen über eine unterschiedliche Art ein chroot auf in dem jeweils unabhängig vom benutzen System ein komplettes Debian System installiert wird und beim Verlassen bzw. beim Beenden des Builds wieder komplett gelöscht wird.

SBuild wird auf den Debian Buildaemons benutzt um alle benötigten Architekturen automatisch zu bauen nachdem jemand eine Version ins Archiv geladen hat. Allerdings hat sbuild eine etwas längere und steilere Lernkurve. Wie man das benutzt findet man im Debian Wiki. https://wiki.debian.org/sbuild

Deutlich einfacher lässt sich da pbuilder benutzen, dafür ist es nicht so hochflexibel wie sbuild. Dies benötigt man aber meistens auch nicht wenn sich "nur" eine eigene Version bauen will. Sehe beleibt ist ebenfalls das Paket git-buildpackage was ein komplettes Tooling mitbringt um wirklich mit wenigen Kommandos eigene Paket erstellen zu können. So bringt es zum Beispiel den Befehl git-pbuilder mit womit man sehr einfach seine Basis Chroots verwalten kann.

Mit dem Anpassen bzw. Erweitern der Datei /etc/sudors gemäß dem Wiki auf Tanglu ist es nun sehr einfach zu benutzen wenn man in einem Git Tree steht. Bitte benutzt von dort nur das Anpassen der Datei /etc/sudoers wenn Ihr was bauen wollt! Tanglu ist zwar Debian basierend aber eben nicht gleich.

Code: Alles auswählen

$ gbp buildpackage --git-pbuilder -j4
gbp:info: Building with (cowbuilder) for sid
gbp:info: Creating /home/tijuca/tmp/build/kopano-webapp_3.4.0+dfsg1.orig.tar.xz
Building with cowbuilder for distribution sid
I: using cowbuilder as pbuilder
...

Übrigens ist Docker keine gute Idee, es gibt keine offiziellen Docker Images von Debian so das Docker Images die so findet immer unterschiedlich zu dem sind was eben pbuilder oder sbuild benutzen. Da wird man irgendwann auf die Nase fallen wegen der Abhängigkeiten. Wenn man schon Pakete bauen will dann bitte genau so wie es DDs oder DMs machen. Und das ist per pbuilder oder sbuild

[maltris]

Übrigens ist Docker keine gute Idee, es gibt keine offiziellen Docker Images von Debian so das Docker Images die so findet immer unterschiedlich zu dem sind was eben pbuilder oder sbuild benutzen. Da wird man irgendwann auf die Nase fallen wegen der Abhängigkeiten.

Du magst mit vielem Recht haben, jedoch bitte ich Dich, vor dem Absenden Deine Quellen zu prüfen.

OFFICIAL REPOSITORY

Maintained by:
Debian Developers tianon and paultag

https://hub.docker.com/_/debian/

[tijuca]

Ich bitte vielmals um Entschuldigung, ich habe hier versäumt täglich die möglichen Quellen zu verifizieren und Du hier vermutlich einen Informationsvorteil hast.
Vor rund einem Jahr, als ich mich mit Docker und möglichen Containern beschäftigt hatte, gab es keine "offiziellen" Debian Docker Container. Wobei das Debian Projekt hier eine eigene Meinung hat was offizielles Debian bedeutet. Meiner Erfahrung nach wird dies vom Großteil der DDs nicht als Offiziell betrachtet da dies ein Projekt einzelner DDs ist und nicht irgendwo auf debian.org angesiedelt ist. Mir ist keine Announcing E-Mail über offizielle Liste debian-devel-announce bekannt. Insofern könnte man sicherlich vorzüglich darüber streiten. Da diese Images wohl im Umfeld des Reproducible Buiulds Projekts entstandenen sind, PaulTag auch kein ganz unbekannter DD ist kann man wohl davon ausgehen, dass die Images offiziell genug sind.

Ist aber alles etwas Offtopic, da es hier um Paketbau selber geht und Docker dafür im Grunde eigentlich nebensächlich ist da auch in einem Docker Container dafür die gleichen Programme und Tools benötigt werden. Da bin ich mit deutlich weniger Overhead am gleichem Ziel.

[reox]

Also ich denke immer noch, dass eine VM Umgebung schon sinnvoll ist. Wenn ich irgendwann mal für irgendein anderes Betriebsystem bauen will kanns ja nicht schaden die Infrastruktur schon zu haben.

[reox]

mal ein update zu dem thema hier:
Ich hab zwischenzeitlich mal jenkins und docker aufgesetzt aber dieses debian build system hab ich nicht in polynomieller zeit aufgesetzt bekommen. Nachdem der jenkins dann mein /var/log innerhalb von wenigen Minuten komplett vollgeschrieben hat weil er wohl irgendeine endlosschleife erzeugt hat, hab ich die pakete wieder gekübelt.
Ich hab mir jetzt mal einen pbuilder aufgesetzt und das rennt eigentlich sehr gut. Hab gleich mal einige dependency probleme in meinen paketen festgestellt.
Ich überlege jetzt wie man das ganze geschickt automatisieren kann. Die pakete sind alle in git repos - dH regelmäßig pullen, schauen ob neue änderungen, wenn ja neue version erzeugen und bauen. Das sollte sich ja alles mit hausmitteln erledigen lassen.