- Eine einfache CI-Konfiguration, die durch Hinzufügen eines
post-receive-Hooks zu einem bare-Git-Repository auf einem privaten Server Tests, Builds und Dateiverschiebungen automatisiert - Im Vergleich zu bestehendem CI waren weder komplexe YAML-Konfigurationen, langsame Ausführung und schwieriges Self-Hosting noch vollständige Build-Isolation oder Secret-Management erforderlich
- Wenn Jobs direkt im Hook ausgeführt werden, wird bei Fehlern der Push abgelehnt oder der Abschluss verzögert sich; deshalb wird die minimale Job-Queue
nqfür die Hintergrundverarbeitung verwendet - Der Hook ruft nur
nqauf, und die Logs lassen sich mitssh server nqtail -aprüfen, was einen schnellen und einfachen Betrieb ermöglicht - Bei Bedarf lassen sich Builds mit landdown oder Podman isolieren, Secrets mit sops verwalten oder der Entwicklungsstil mit Git-E-Mail-Patches,
git-shellundgit http-backenderweitern
Aufbau mit post-receive-Hook und nq
- Auf einem privaten Server wird mit
ssh server git init --bare repoein Repository erstellt und mitgit clone server:repogeklont - Im hooks-Verzeichnis des bare-Repositorys wird ein
post-receive-Hook in Form eines Shell-Skripts abgelegt, der bei jedem Push die CI startet - Werden Jobs direkt im Hook ausgeführt, entstehen zwei Probleme
- Wenn das Skript fehlschlägt, wird der Push abgelehnt
- Wenn die Skriptausführung langsam ist, verzögert sich auch der Abschluss des Pushs
- Im Hook wird die minimale Job-Queue
nqaufgerufen, um Jobs in eine Hintergrund-Queue einzureihen- Die Logs lassen sich mit
ssh server nqtail -aprüfen - Der Einrichtungsprozess ist in einem kurzen Tutorial beschrieben
- Die Logs lassen sich mit
Isolation und Erweiterung des Entwicklungsstils
- Um Builds in einer Sandbox auszuführen, kann landdown verwendet werden
- Mit Podman lassen sich Builds von der Host-Umgebung isolieren, und mit sops können Secrets verwaltet werden
- Für Entwicklung im Bazaar-Stil eignet sich eine Konfiguration, die Git-Patches per E-Mail entgegennimmt
- Entwicklung im Cathedral-Stil lässt sich mit
git-shellodergit http-backendaufsetzen
1 Kommentare
Meinungen auf Lobste.rs
CI hat mindestens zwei Probleme
Das einfache Problem ist, bei Codeänderungen
make testauszuführen; das schwierige Problem ist,make testunter Linux, Windows und Mac auszuführen.Ich bin unzufrieden damit, dass Developer Experience und Debugging-Funktionen bestehender Engines immer hinten anstehen, und baue deshalb unter https://ci.pico.sh ein CI-System. DSLs mag ich ebenfalls nicht, und hierarchisch verkettetes YAML fühlt sich an, als würde es einem langsam die Lebenskraft aussaugen.
Ich habe so etwas einmal auf gitolite aufgebaut und an Temporal übergeben, um den Build-Prozess ohne Einschränkungen zu steuern.
Bei Ausführungsfehlern könnte man den Push ablehnen, aber normalerweise lässt man den Hook durchlaufen und behandelt den Fehler separat; die Konfiguration war einfach und machte Spaß.
Eine weitere minimale CI, die sich auf die Ausführung von Shell-Skripten konzentriert, ist laminar CI; sie bietet auch eine Web-UI.
Vor langer Zeit hatten wir in einer reinen Windows-Unternehmensumgebung einen Mac mini als lokalen CI-Server für das ganze Team, um iOS-Apps zu bauen; das war einer unserer frühen Versuche, Git zu nutzen.
Ich habe das auf https://mccd.space/git/ gefunden; es scheint einen Fork von stagit zu verwenden.
Bis vor ein paar Monaten betrieb ich Forgejo und Woodpecker, aber die meisten Funktionen brauchte ich nicht, also habe ich alles entfernt und suchte nach einer ähnlich leichteren Konfiguration. Da CI meine nächste Aufgabe war, kommt das zeitlich genau richtig; ich überlege, eine kleine Library, die ich bald veröffentliche, auf SourceHut zu spiegeln.
Die Repositories stelle ich mit git-daemon schreibgeschützt im Web bereit; die vollständige Einrichtung habe ich hier dokumentiert.
Durch diesen Artikel habe ich
nqzum ersten Mal kennengelernt, werde aber vermutlichsystemd-runverwenden.Da ich für fast alle Runner Nix nutze, könnte ich die CI-Anforderungen wohl über das Monitoring-System abdecken, wenn ich die Ergebnisse von
nix flake checkals OTLP-Metriken und -Logs bereitstelle.Mir gefällt eine so einfache selbst gehostete Entwicklungsplattform-Konfiguration.
Für CI lässt sich bubblewrap, ein leichtgewichtiges und einfaches Containersystem, unkompliziert einrichten und nutzen. Allerdings scheint es mit
nqnicht möglich zu sein, Pushes bei CI-Fehlern abzulehnen; ich frage mich, wie das gehandhabt wird.Wenn mehr Isolation nötig ist, kann man Podman, Docker oder bubblewrap hinzufügen. Aus demselben Grund, aus dem ich keinen Pre-Commit-Hook habe, der Tests ausführt, lehne ich Pushes bei CI-Fehlern nicht ab: Manchmal muss man auch kaputte Arbeit committen oder pushen, und Pushes können dadurch sehr langsam werden. Wenn eine Ablehnung nötig ist, kann man die CI ohne
nqsynchron ausführen und den Push blockieren, wenn der Exit-Code nicht 0 ist.Alternativ kann man Branches außer main mit
nqausführen und nur den main-Branch synchron laufen lassen.Der
landdown-Link scheint kaputt zu sein.