Ich versuche im Moment zum Thema Buildserver zu recherchieren. Dabei komme ich aber immer nur zu den üblichen CI/CD-Lösungen wie Jenkins und TeamCity. Die Testing-Pipeline ist jedoch nicht das, was ich brauche: Stattdessen geht es mir darum, aus dem Code ein Artefakt zu bauen, das mir dann anschliessend zum Download bereitsteht; öffentlich verfügbar oder etwa durch HTTP Basic Auth geschützt. Wenn dazu noch die Checksummen (SHA256 oder SHA512) berechnet und abgespeichert würden, wäre das natürlich noch schöner. (Etwa so wie bei den Debian-Images.)
Dabei möchte ich v.a. Go-Binaries bauen. Diese Buildvorgänge sind ja jeweils recht einfach und mit dem go-Tool und einem Befehl zu bewältigen. (Im Hintergrund passiert dabei eine ganze Menge; es werden Abhängigkeiten aufgelöst und heruntergeladen.) Cross-Compilation lässt sich ja mit GOARCH und GOOS recht einfach bewerkstelligen.
Kennt sich hier jemand etwas aus, was man da in der Praxis verwendet? Ich kann mir gerade nicht vorstellen, dass man bei den Debian-Leuten Jenkins verwendet.
Ich war bisher entweder im Java-Umfeld tätig, wo eben Jenkins sehr verbreitet ist. Sonst programmiere ich Python, wo die Software auf Code-Ebene deployed wird. (GitLab wäre eine mächtige Lösung, die Versionsverwaltung habe ich aber schon anderweitig gelöst.)
Ich wäre froh um ein paar Anregungen und Erfahrungen.
Grundlegendes zu Buildservern
- paedubucher
- Beiträge: 932
- Registriert: 22.02.2009 16:19:02
- Lizenz eigener Beiträge: GNU Free Documentation License
- Wohnort: Schweiz
-
Kontaktdaten:
Grundlegendes zu Buildservern
Habe nun, ach! Java
Python und C-Sharp,
Und leider auch Visual Basic!
Durchaus programmiert mit heissem Bemühn.
Da steh' ich nun, ich armer Tor!
Und bin so klug als wie zuvor.
Python und C-Sharp,
Und leider auch Visual Basic!
Durchaus programmiert mit heissem Bemühn.
Da steh' ich nun, ich armer Tor!
Und bin so klug als wie zuvor.
Re: Grundlegendes zu Buildservern
Hi,
willst Du "einfach" nur go-binaries bauen, oder sollen daraus debian Pakete oder sogar auch Pakete für andere Distributionen entstehen?
Die sogenannten Buildserver nehmen dir am Ende "nur" die Manuelle Arbeit ab, das heisst, der Buildprozess muss manuell schon mal funktionieren. Desweiteren muss der zu bauende Code eine bestimmte Verzeichnisstruktur haben und noch einige andere "Spezialitäten" je nach Buildsystem/Server. Aber das solltest Du ja kennen von Jenkins (mit dem ich gar keine Erfahrung habe). Ein weiterer Vorteil ist, dass mit einem Buildserver immer auf der grünen Wiese gebaut wird, Das heisst, wenn irgendwelche Abhängigkeiten fehlen, wird es gleich bemerkt. Wenn man sonst immer auf der privaten Maschine baut kann halt schon einiges durch das basteln installiert bzw. verfügbar sein, was normalerweise nicht installiert ist und damit fällt es niciht auf, wenn es in den Abhängigkeiten nicht erwähnt wird.
Wie sieht denn dein gewünschtes setup aus? Wie wünscht Du dir den Workflow, und was soll am Ende "rausfallen".
Bei Debian bin ich auch gerade am Schauen, da ich ein paar Pakete anpassen möchte und da gleich mal die grosse Keule rausholen will. Da mir der debian paketbauprozess auch noch nicht so geläufig ist wir beim rpm ist da noch einiges zu schauen.
Ich versuche mich da gerade in sbuild (https://tracker.debian.org/pkg/sbuild) einzulesen/einzufuchsen. Hier der Wiki-Link zu einer Einführung: https://wiki.debian.org/sbuild
Bei Fedora/redhat gibt es das tool "mock" das macht aus srpms ein rpm in einem chroot (soll auch mit docker gehen, aber das habe ich noch nicht getestet), das rpm kann mittels tito aus einem source tree in einem git repo gemacht werden.
Für andere Builds habe ich keine ahnung...
Aber ich habe zu Hause auch noch ein gitea laufen und auf meiner todo liste steht auch der plan, dass mal mit einem ci/cd tool zu verbinden, um so mal automatisch Pakete zu bauen, aber die todo liste ist schon sehr lang. Für gitea gibt es eine menge an solchen ci/cd lösungen zum "anbauen" (https://gitea.com/gitea/awesome-gitea). Aber ich kann mir denken, dass der Aufbau so einer Kette am Anfang ziemlich mühsam sein kann. das dauert bestimmt eine Weile, bis dann auch mal was gebaut werden kann.
Aber wenn Du auf Arbeit schon mit Jenkins geschafft hast, hast Du bestimmt mehr ahnung al sich , ich habe nur mittels tito und mock einige Pakete für ystem auf Arbeit gebaut, damit da saubere RPMS raus kommen, die sich ohne Probleme auf existierenden System installieren lassen...nix grosses...
Gruss
Thomas
willst Du "einfach" nur go-binaries bauen, oder sollen daraus debian Pakete oder sogar auch Pakete für andere Distributionen entstehen?
Die sogenannten Buildserver nehmen dir am Ende "nur" die Manuelle Arbeit ab, das heisst, der Buildprozess muss manuell schon mal funktionieren. Desweiteren muss der zu bauende Code eine bestimmte Verzeichnisstruktur haben und noch einige andere "Spezialitäten" je nach Buildsystem/Server. Aber das solltest Du ja kennen von Jenkins (mit dem ich gar keine Erfahrung habe). Ein weiterer Vorteil ist, dass mit einem Buildserver immer auf der grünen Wiese gebaut wird, Das heisst, wenn irgendwelche Abhängigkeiten fehlen, wird es gleich bemerkt. Wenn man sonst immer auf der privaten Maschine baut kann halt schon einiges durch das basteln installiert bzw. verfügbar sein, was normalerweise nicht installiert ist und damit fällt es niciht auf, wenn es in den Abhängigkeiten nicht erwähnt wird.
Wie sieht denn dein gewünschtes setup aus? Wie wünscht Du dir den Workflow, und was soll am Ende "rausfallen".
Bei Debian bin ich auch gerade am Schauen, da ich ein paar Pakete anpassen möchte und da gleich mal die grosse Keule rausholen will. Da mir der debian paketbauprozess auch noch nicht so geläufig ist wir beim rpm ist da noch einiges zu schauen.
Ich versuche mich da gerade in sbuild (https://tracker.debian.org/pkg/sbuild) einzulesen/einzufuchsen. Hier der Wiki-Link zu einer Einführung: https://wiki.debian.org/sbuild
Bei Fedora/redhat gibt es das tool "mock" das macht aus srpms ein rpm in einem chroot (soll auch mit docker gehen, aber das habe ich noch nicht getestet), das rpm kann mittels tito aus einem source tree in einem git repo gemacht werden.
Für andere Builds habe ich keine ahnung...
Aber ich habe zu Hause auch noch ein gitea laufen und auf meiner todo liste steht auch der plan, dass mal mit einem ci/cd tool zu verbinden, um so mal automatisch Pakete zu bauen, aber die todo liste ist schon sehr lang. Für gitea gibt es eine menge an solchen ci/cd lösungen zum "anbauen" (https://gitea.com/gitea/awesome-gitea). Aber ich kann mir denken, dass der Aufbau so einer Kette am Anfang ziemlich mühsam sein kann. das dauert bestimmt eine Weile, bis dann auch mal was gebaut werden kann.
Aber wenn Du auf Arbeit schon mit Jenkins geschafft hast, hast Du bestimmt mehr ahnung al sich , ich habe nur mittels tito und mock einige Pakete für ystem auf Arbeit gebaut, damit da saubere RPMS raus kommen, die sich ohne Probleme auf existierenden System installieren lassen...nix grosses...
Gruss
Thomas
- paedubucher
- Beiträge: 932
- Registriert: 22.02.2009 16:19:02
- Lizenz eigener Beiträge: GNU Free Documentation License
- Wohnort: Schweiz
-
Kontaktdaten:
Re: Grundlegendes zu Buildservern
Go ist mal die erste und absehbare einzige Priorität.smiler hat geschrieben:22.04.2022 20:09:15willst Du "einfach" nur go-binaries bauen, oder sollen daraus debian Pakete oder sogar auch Pakete für andere Distributionen entstehen?
Das Repository muss ich vorher schon in Ordnung bringen. Sonst funktionieren so Sachen wie go install ja schon nicht.smiler hat geschrieben: Die sogenannten Buildserver nehmen dir am Ende "nur" die Manuelle Arbeit ab, das heisst, der Buildprozess muss manuell schon mal funktionieren. Desweiteren muss der zu bauende Code eine bestimmte Verzeichnisstruktur haben und noch einige andere "Spezialitäten" je nach Buildsystem/Server. Aber das solltest Du ja kennen von Jenkins (mit dem ich gar keine Erfahrung habe).
Für die "grüne Wiese" muss ich da wohl schon jeweils einen Container aufstarten, oder aber sehr diszipliniert mit der VM umgehen, worauf der Server dann läuft. Aber mit Go kann man die Umgebung ja recht gut via Umgebungsvariablen isolieren.smiler hat geschrieben: Ein weiterer Vorteil ist, dass mit einem Buildserver immer auf der grünen Wiese gebaut wird, Das heisst, wenn irgendwelche Abhängigkeiten fehlen, wird es gleich bemerkt. Wenn man sonst immer auf der privaten Maschine baut kann halt schon einiges durch das basteln installiert bzw. verfügbar sein, was normalerweise nicht installiert ist und damit fällt es niciht auf, wenn es in den Abhängigkeiten nicht erwähnt wird.
Grundsätzlich soll beim Taggen bzw. beim Pushen eines Tags ein Build angestossen werden. Dieser wirft dann ein Binary (oder eine Reihe von Binaries für verschiedene Betriebssysteme und Architekturen) aus, sowie eine Datei m it SHA256-Checksummen. Das ganze soll dann per Internet erreichbar sein.smiler hat geschrieben: Wie sieht denn dein gewünschtes setup aus? Wie wünscht Du dir den Workflow, und was soll am Ende "rausfallen".
Nun, distributionsspezifische Pakete will ich nicht bauen. Ich will einfach, dass nach dem Pushen eines Tags ein Binary über eine URL gezogen werden kann; von mir aus mit Basic Auth geschützt.smiler hat geschrieben: Bei Debian bin ich auch gerade am Schauen, da ich ein paar Pakete anpassen möchte und da gleich mal die grosse Keule rausholen will. Da mir der debian paketbauprozess auch noch nicht so geläufig ist wir beim rpm ist da noch einiges zu schauen.
Ich versuche mich da gerade in sbuild (https://tracker.debian.org/pkg/sbuild) einzulesen/einzufuchsen. Hier der Wiki-Link zu einer Einführung: https://wiki.debian.org/sbuild
Bei Fedora/redhat gibt es das tool "mock" das macht aus srpms ein rpm in einem chroot (soll auch mit docker gehen, aber das habe ich noch nicht getestet), das rpm kann mittels tito aus einem source tree in einem git repo gemacht werden.
Für andere Builds habe ich keine ahnung...
Dann hätten unsere TODO-Listen schon einmal eine Schnittmengesmiler hat geschrieben: Aber ich habe zu Hause auch noch ein gitea laufen und auf meiner todo liste steht auch der plan, dass mal mit einem ci/cd tool zu verbinden, um so mal automatisch Pakete zu bauen, aber die todo liste ist schon sehr lang. Für gitea gibt es eine menge an solchen ci/cd lösungen zum "anbauen" (https://gitea.com/gitea/awesome-gitea). Aber ich kann mir denken, dass der Aufbau so einer Kette am Anfang ziemlich mühsam sein kann. das dauert bestimmt eine Weile, bis dann auch mal was gebaut werden kann.
Ich habe so ein Jenkins-Dings noch nie aufgebaut, ich bin immer davon zurückgeschreckt. Erfahrungen habe ich aber in OpenShift (Enterprise-Kubernetes von Red Hat) und auch etwas mit GitLab.smiler hat geschrieben: Aber wenn Du auf Arbeit schon mit Jenkins geschafft hast, hast Du bestimmt mehr ahnung al sich , ich habe nur mittels tito und mock einige Pakete für ystem auf Arbeit gebaut, damit da saubere RPMS raus kommen, die sich ohne Probleme auf existierenden System installieren lassen...nix grosses...
Ich frage mich gerade, ob ich so ein Dings nicht vielleicht selber in Go programmieren soll. Webhooks von Gitea habe ich auch schon einmal an eine eigens entwickelte Go-Server-Anwendung weitergeleitet. Dann müsste ich dem Server eine Konfiguration hinterlegen können, welche Kombinationen von Architekturen und Betriebssystemen berücksichtigt werden sollen. Anschliessend baue ich mir ein Verzeichnis auf, irgendwo in /tmp, welches ich dann als GOPATH festlege. Dort ziehe ich dann das Repo rein und baue es. (Den genauen Befehl könnte man dann immer noch konfigurieren; manchmal will man ja die Repo-Version hineinkompilieren oder dergleichen.) Der Output geht dann in ein Verzeichnis, das von einem Webserver gegen aussen angeboten wird. Es gibt die Option "offen" oder "basic auth"; je nach dem ist der Download dann geschützt. So einen proof-of-concept kriegt man an einem Wochenende schon hin. Lehrreich wäre das ganze ja...
Habe nun, ach! Java
Python und C-Sharp,
Und leider auch Visual Basic!
Durchaus programmiert mit heissem Bemühn.
Da steh' ich nun, ich armer Tor!
Und bin so klug als wie zuvor.
Python und C-Sharp,
Und leider auch Visual Basic!
Durchaus programmiert mit heissem Bemühn.
Da steh' ich nun, ich armer Tor!
Und bin so klug als wie zuvor.
Re: Grundlegendes zu Buildservern
Hallo,
Selber bauen geht natürlich auch. Aber warum das Rad neu erfinden?
Ich habe (mir war langweilig) mal bei gitea geschaut, und gleich der erste Eintrag auf der liste agola (https://github.com/agola-io/agola) hat als kurzeinführung ein go projekt. Hm...da ist zwar noch kein upload und keine sha-Berechung drin, aber...
Jetzt ist die Frage, was geht schneller/macht mehr Spass/ist sinnvoller? selbst was schreiben, oder in das dann ausgesuchte Tool einarbeiten...
Diese Entscheidung bleibt dann bei Dir
Viele Grüsse
Thomas
Selber bauen geht natürlich auch. Aber warum das Rad neu erfinden?
Ich habe (mir war langweilig) mal bei gitea geschaut, und gleich der erste Eintrag auf der liste agola (https://github.com/agola-io/agola) hat als kurzeinführung ein go projekt. Hm...da ist zwar noch kein upload und keine sha-Berechung drin, aber...
Jetzt ist die Frage, was geht schneller/macht mehr Spass/ist sinnvoller? selbst was schreiben, oder in das dann ausgesuchte Tool einarbeiten...
Diese Entscheidung bleibt dann bei Dir
Viele Grüsse
Thomas
- paedubucher
- Beiträge: 932
- Registriert: 22.02.2009 16:19:02
- Lizenz eigener Beiträge: GNU Free Documentation License
- Wohnort: Schweiz
-
Kontaktdaten:
Re: Grundlegendes zu Buildservern
Eine Motivation hier ist das bessere Verständnis des Go-Buildprozesses. Es geht also eher um einen Prototyp als um eine produktive Software.smiler hat geschrieben:22.04.2022 22:29:02Hallo,
Selber bauen geht natürlich auch. Aber warum das Rad neu erfinden?
Danke für den Tipp! Ich denke, ich sollte beides mal machen! Die Frage ist, was ich zuerst machesmiler hat geschrieben: Ich habe (mir war langweilig) mal bei gitea geschaut, und gleich der erste Eintrag auf der liste agola (https://github.com/agola-io/agola) hat als kurzeinführung ein go projekt. Hm...da ist zwar noch kein upload und keine sha-Berechung drin, aber...
Jetzt ist die Frage, was geht schneller/macht mehr Spass/ist sinnvoller? selbst was schreiben, oder in das dann ausgesuchte Tool einarbeiten...
Habe nun, ach! Java
Python und C-Sharp,
Und leider auch Visual Basic!
Durchaus programmiert mit heissem Bemühn.
Da steh' ich nun, ich armer Tor!
Und bin so klug als wie zuvor.
Python und C-Sharp,
Und leider auch Visual Basic!
Durchaus programmiert mit heissem Bemühn.
Da steh' ich nun, ich armer Tor!
Und bin so klug als wie zuvor.