1 Punkte von GN⁺ 9 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • 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 nq für die Hintergrundverarbeitung verwendet
  • Der Hook ruft nur nq auf, und die Logs lassen sich mit ssh server nqtail -a prü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-shell und git http-backend erweitern

Aufbau mit post-receive-Hook und nq

  • Auf einem privaten Server wird mit ssh server git init --bare repo ein Repository erstellt und mit git clone server:repo geklont
  • 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 nq aufgerufen, um Jobs in eine Hintergrund-Queue einzureihen
    • Die Logs lassen sich mit ssh server nqtail -a prüfen
    • Der Einrichtungsprozess ist in einem kurzen Tutorial beschrieben

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-shell oder git http-backend aufsetzen

1 Kommentare

 
GN⁺ 9 시간 전
Meinungen auf Lobste.rs
  • CI hat mindestens zwei Probleme
    Das einfache Problem ist, bei Codeänderungen make test auszuführen; das schwierige Problem ist, make test unter Linux, Windows und Mac auszuführen.

    • Linux ist einfach und Windows schwierig, aber macOS ist schmerzhaft.
    • Der schwierige Teil von CI ist aus meiner Sicht die Job-Execution-Engine, die bei Fehlern auch Debugging unterstützt.
      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.
    • Dieser Ansatz löst das einfache Problem; mit QEMU ließen sich BSD-Varianten unterstützen und mit Docker mehrere Distributionen, aber darüber hinaus scheint ein vollständigeres Tool nötig zu sein.
  • 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ß.

    • Besonders gut gefallen mir die Access-Control-Tools von gitolite, und auch die Möglichkeit, durch Pushen in ein nicht existierendes Repository ein neues Repository anzulegen, ist großartig.
  • 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.

    • Ich habe stagit geforkt, eine Kontakt-E-Mail und eine Navigationsleiste hinzugefügt, IDs für CSS-Änderungen eingebaut und unnötige Informationen entfernt.
      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 nq zum ersten Mal kennengelernt, werde aber vermutlich systemd-run verwenden.
    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 check als 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 nq nicht möglich zu sein, Pushes bei CI-Fehlern abzulehnen; ich frage mich, wie das gehandhabt wird.

    • Es gibt auch ein Hilfstool, das Landlock zum Einschränken von Skripten verwendet; die Nutzung wirkt etwas einfacher.
      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 nq synchron ausführen und den Push blockieren, wenn der Exit-Code nicht 0 ist.
      Alternativ kann man Branches außer main mit nq ausführen und nur den main-Branch synchron laufen lassen.
  • Der landdown-Link scheint kaputt zu sein.