pipeline 0.2.0

Pipeline verbindet Gitea Actions, den vorhandenen Patronage-Paketkern und die Registry mit isolierten KVM-Builds, nativen Installationstests, signierten Releases und einer persistenten HTTPS-Demo. Der Steuerungskern ist in Go geschrieben. Im installierten Betrieb wird keine AI benötigt.

Der Quellcode liegt direkt im Hauptverzeichnis dieses Repositorys. Hinweise zum Entwickeln und Bauen stehen unter Quellbuild.

Stand: Der vollständige Bootstrap wurde in dieser Iteration auf frischen Fedora-Server-44-Hosts für beide Engineprofile tatsächlich ausgeführt: Setup, Build in einer Ein-Job-KVM-VM, native Installationstests auf frischen Fedora- und Debian-Gästen, signierte Releases 1.0.0 und 2.0.0 mit Migrationstests, Veröffentlichung in Registry und Gitea und Deployment auf das behaltene Ziel. Die Hosts sind verschachtelte KVM-Gäste in einem Testlabor auf der Entwicklerarbeitsstation; diese selbst wurde nicht verändert. Die unabhängige Abnahme A–N lief am 2026-10-09 je Profil auf zwei weiteren frischen Laborhosts vollständig durch: A, B, C, H und I bestanden auf beiden Profilen, G, J, K und N teilweise, L und M teilweise unter rootless Podman; D, E und F sind nicht ausgeführt. VERIFY.md trennt tatsächliche Ergebnisse von ungeprüften Abläufen und nennt die Abnahmeergebnisse A–N je Profil mit Zeiten und Grenzen; PROGRESS.json und requirements.json halten die offenen Anforderungen fest.

Start aus der vollständigen Lieferung

Auf einem dafür vorgesehenen frischen Fedora-44-x86_64-Host die vollständige Lieferung entpacken, in deren Verzeichnis wechseln und ausführen:

sudo ./setup.sh

Der Default ist Docker. Für den ausdrücklich gewählten Podman-Aufbau auf einem eigenen frischen Host:

sudo ./setup.sh --engine podman

Erforderlich sind Administratorrechte, Internetzugang und nutzbares KVM, bei einem VM-Host also tatsächlich freigegebene verschachtelte Virtualisierung. Die Planungsreferenz beträgt 8 CPU-Threads, 16 GiB RAM, 80 GiB freie SSD und 100 Mbit/s nutzbare Downloadbandbreite; die auf solchen Hosts gemessenen Zeiten, der tatsächliche Speicher- und Plattenverbrauch sowie die Downloadmengen stehen in VERIFY.md. Ein kleinerer Mindestbedarf wurde nicht ermittelt. Build-VMs erhalten 4 GiB, Ziel-VMs 2 GiB; diese Budgets sind zugewiesene Grenzen, keine gemessenen Minima. Der Host muss die Fedora-44-Paketstände des Locks installieren können; ein neuerer Host bricht mit einem klaren Fehler ab, statt abweichende Versionen zu akzeptieren.

setup.sh wird zusammen mit dem frisch gebauten Binary und dem gehashten delivery.json erzeugt. Der Wrapper kopiert das Binary in ein privates Verzeichnis unter /run, prüft dessen SHA256 und startet den gebundenen Bootstrap. Ein einzelnes aus dem Quellbaum kopiertes Binary ersetzt die vollständige Lieferung mit Images, Schlüsseln und Lockdateien nicht.

Die Runtimewahl wird gespeichert. Derselbe Aufruf setzt angefangene Schritte fort und überprüft vorhandene Identitäten. Ein späterer Aufruf ohne --engine verwendet die gespeicherte Auswahl; ein Widerspruch wird vor der Installation abgewiesen. Ein anderer Engine-Name ist kein Migrationsbefehl.

Zugriff und Betrieb

Nach einem vollständig erfolgreichen Setup erscheinen die konkrete Gitea-URL, der reale Release-Link, das Ziel und der Timing-Bericht. Gitea verwendet lokal https://gitea.pipeline.test:8443; die lokale CA und Namensauflösung werden vom Bootstrap eingerichtet. Die Zieladresse wird aus dem konfliktgeprüften eigenen Subnetz vergeben. Für einen Browser mit eigenem Zertifikatsspeicher muss die öffentliche Installations-CA bewusst in dessen Vertrauensspeicher übernommen werden; keine TLS-Ausnahme verwenden. Browserzugriff wurde auf dieser Entwicklungsmaschine noch nicht nachgewiesen.

Der initiale Administrator heißt pipeline-admin. Sein Passwort wird ausschließlich aus der privaten Datei gelesen:

sudo cat /var/lib/pipeline/secrets/gitea-admin-password

Status und ausführlichere, lesende Überprüfung einer installierten Umgebung:

sudo pipeline status --json
sudo pipeline verify --json

verify prüft die vorhandene Installation. Es ersetzt keinen frischen Hostaufbau, Reboot- oder Restore-Test. Systemdienste und der Controller laufen über systemd; die Podman-Dienste verwenden eigene Rootless-Identitäten und Linger. Ein erfolgreicher Prozessstart allein gilt nicht als betriebsbereites Ziel.

Builds verwenden den offiziellen Gitea Runner ausschließlich im Host-Modus einer frischen Ein-Job-VM. Tasks laufen dort in begrenzten Containern. Unterstützte Branch-Pushes erzeugen Prüfungen; ein geschützter Main-Commit wird zum Kandidaten. Die Veröffentlichung benötigt eine dauerhaft gebundene Release-Anforderung. Die ersten beiden Demo-Anforderungen werden im Setup automatisch erzeugt. Eine explizite Anforderung verwendet den vollständigen Commit:

sudo pipeline release --commit FULL_COMMIT_SHA --version 2.0.0 --json

Der Demo-Controller unterstützt die vorbereiteten Versionen 1.0.0, 2.0.0 und den ausdrücklich von veröffentlichtem v2 abgeleiteten Folgerelease 2.0.1. sudo pipeline demo-update --version 2.0.1 --json erzeugt dessen echten neuen Commit, autorisiert den Release und wartet auf den normalen Build-/Veröffentlichungs-/Deploymentpfad, beispielsweise nach Restore. Er bietet keinen allgemeinen Freigabemechanismus für beliebige Programme oder Versionen. Nicht unterstützte Workflow-Funktionen, einschließlich Docker-Actions und frei deklarierter Servicecontainer, werden vor der Ausführung abgewiesen. PRs aus demselben Repository dürfen nur den geprüften Testpfad verwenden; Fork-PRs werden vor der VM-Zuweisung abgewiesen. Ein PR-Label erteilt keine Veröffentlichungsrechte.

Diese Grenze setzt vertrauenswürdige Betreiber des Steuerungshosts und Gitea-Site-Administratoren voraus. Normale Benutzer erhalten keine Berechtigung, zusätzliche Repositories oder Forks anzulegen. Gitea-Site-Administratoren können diese Quoten umgehen und Richtlinien ändern; sie gehören daher nicht zur eingeschränkten Build-Benutzergruppe. Eine manuell erweiterte Quote oder ein administrativ angelegter Fork ist kein unterstützter Weg, fremde PRs in den Runnerpfad aufzunehmen.

Jeder Release enthält das tatsächliche Binary pipeline-demo-linux-amd64, RPM, DEB, release-manifest.json und release-manifest.sig. Das Manifest bindet Commit, offiziellen Job, Lockdateien, Taskimage, Binärbytes und native Prüfungen. V2 verlangt zusätzlich je einen v1→v2-Test auf einer weiteren frischen Fedora- und Debian-VM. Erst nach abgeschlossener Veröffentlichung wird das behaltene Fedora-Demoziel aktualisiert. Das ursprüngliche v1-Datum muss per authentifiziertem HTTPS-GET unverändert lesbar bleiben.

Sicherung und Wiederherstellung

Die Sicherung hält die betroffenen Schreiber an und verwendet den bestehenden, erweiterten volume-backup-Kern für Daten und Metadaten. Der private Sicherungspfad muss neu und absolut sein:

sudo pipeline backup --output /srv/private-backups/pipeline.backup --json

Die Ausgabe enthält die Identität des Sicherungsauftrags. Sicherungen enthalten notwendige private Identitäten und gehören in einen geschützten Speicher; sie sind keine öffentlichen Release-Dateien. Auf einem frischen geeigneten Ziel benötigt Restore dieselbe gebundene Lieferung und den getrennt vertrauenswürdig aufbewahrten SHA256 der Sicherung:

sudo ./setup.sh restore \
  --archive /srv/private-backups/pipeline.backup \
  --sha256 TRUSTED_BACKUP_SHA256 --json

Wiederaufnahme erfolgt anhand des ausgegebenen Auftrags mit pipeline backup --recover ID beziehungsweise pipeline restore --recover ID. Der Datenzustand wird dabei geprüft; eine unklare oder fremde Ressource wird nicht blind überschrieben. Ob der Restore auf einem frischen Host einschließlich anschließendem neuen Release für ein Profil praktisch abgenommen wurde, steht in VERIFY.md (Abnahmen I und M).

Infrastruktur-Upgrade

Seit Version 0.1.1 enthält die Lieferung den ausführbaren Übergang Gitea 28.0.0 → 28.1.0 mit Datenbankschema 356 → 358. Beide Lieferungen müssen dieselben Controller-, Paket-, Registry- und Backup-Binaries, Task-/Registry-Images und nativen Abhängigkeiten enthalten. Andere Versionssprünge werden vor Änderungen abgewiesen. Der alte Lieferstand bleibt unverändert im Katalog; historische Releases behalten ihre ursprüngliche Identität.

sudo pipeline upgrade --plan --bundle /ABS/target-delivery --sha256 TARGET_DELIVERY_SHA256 --json
sudo pipeline upgrade --bundle /ABS/target-delivery --sha256 TARGET_DELIVERY_SHA256 --json

Der Vorgang hält Dienste und Demo-Daten konsistent an, erzeugt mit volume-backup einen vollständigen privaten Sicherungssatz, prüft native Abhängigkeiten und startet ausschließlich das neue gepinnte gitea migrate ohne Netzwerk. Danach werden Datenidentitäten, Repository-/Anhangbytes, DB-Integrität, Dienste, bestehendes Release und ursprüngliches Demo-Datum geprüft. Erst dann wird die neue Lieferung aktiviert und der Controller gestartet. Die Sicherung bleibt unter /var/lib/pipeline/backups/; der erfolgreiche Migrationscontainer wird anhand seiner aufgezeichneten ID entfernt.

Bei Unterbrechung denselben Zielstand und --recover ID verwenden. Die ID und Phase stehen im Fehler beziehungsweise JSON-Ergebnis. Unbekannte Engine-Antworten werden durch konkrete Containerbeobachtung abgeglichen; ein fehlgeschlagener oder nicht eindeutig beobachtbarer Migrationsstart hält den Vorgang an. Eine automatische Rückkehr zur alten Binary findet nicht statt. Für eine Wiederherstellung wird der vollständige Sicherungssatz auf einem frischen geeigneten Host mit seiner ursprünglichen Lieferung verwendet.

Die installierbare 28.0-Ausgangslieferung für den Test entsteht aus dem gelieferten Quellbaum auf einem Entwicklungsrechner mit Python und Podman (alternativ --engine docker):

python3 tools/upgrade_source.py --target /ABS/target-delivery \
  --sha256 TARGET_DELIVERY_SHA256 --output /ABS/gitea28-upgrade-source

Das Werkzeug prüft das Quellimage einschließlich sämtlicher Layer gegen seine feste Config-ID, erhält die Programmbytes, passt Lockstand/Quellarchiv/Provenienz an und erzeugt eine neue versiegelte ZIP. Auf je einem ausdrücklich bereitgestellten Fedora-Wegwerfhost wird zuerst deren normales sudo ./setup.sh --engine docker beziehungsweise --engine podman ausgeführt, dann der obige Upgrade-Aufruf mit der 28.1-Ziellieferung. Anschließend: sudo pipeline verify --json, Wiederholung des Ziel-setup.sh und sudo pipeline demo-update --version 2.0.1 --json. Die beiden vollständigen Upgrade-Hostläufe sind in dieser Iteration nicht ausgeführt.

Quellbuild

Dieses Repository enthält die Go-Workspace-Module pipeline, package, registry, volume-backup und demo direkt im Hauptverzeichnis. Voraussetzungen sind Linux, Go ab 1.26.0 und GNU Make; make check benötigt außerdem einen C-Compiler für den Race-Detector und native Werkzeuge wie gpgv und RPM (siehe VERIFY.md).

Unter Windows in WSL im Linux-Dateisystem klonen, beispielsweise unter ~/CICD. Unter assets/debian/ existieren sowohl die Datei Packages als auch der Ordner packages; ein Checkout auf NTFS benötigt dort aktivierte Groß-/Kleinschreibung.

cd ~
git clone https://git.patronage.systems/rick/CICD.git
cd CICD
make build
make check

Die Programme entstehen unter bin/. Versioniert werden Quellen, Tests, Dokumentation, Schemas, Lockdateien und benötigte Test- und Paketdaten. Die signierten Eingaben unter assets/ und die OpenSnitch-Beispiele bleiben wegen ihrer Prüfsummen und direkten Verwendung durch Tests bzw. Build-Rezepte enthalten. Fertige Lieferungen, Container-Images, kompilierte Programme, Caches und historische Testprotokolle sind über .gitignore ausgeschlossen und bleiben bei vorhandenen Arbeitskopien lokal erhalten. Historische Belege aus der Dokumentation liegen in den bisherigen Lieferungen bzw. den lokalen Evidence-Verzeichnissen.

In vollständigen Lieferungen liegt der Quellbaum zusätzlich unter source/pipeline.zip. Die konkrete Toolchain wird in der Lieferprovenienz aufgezeichnet; die bisherige Lieferung wurde mit Go 1.26.9 gebaut.

make check führt die Modulprüfungen mit Race-Detector und go vet aus. Optionale Live-Integrationsprüfungen haben eigene Voraussetzungen, die in VERIFY beschrieben sind. Das neu gebaute Demo-Binary wird im normalen Ablauf nur in der Build-VM erzeugt; der Quellbuild des Steuerungsprogramms ist kein Ersatz für diesen Nachweis.

Die vollständigen Versions-, Paket-, Schlüssel- und Hashbindungen stehen in versions.lock.json, native.lock.json, assets/debian.lock.json, delivery.json und provenance.json. Der Paketkern und die Registry verwenden beide Version 0.15.1; Task- und Registry-Image werden mit python3 tools/build_images.py --version 0.15.1 aus dem Quellbaum neu gebaut und mit Smoke-Test exportiert. Die nativen Hostpakete werden mit python3 tools/lock_native.py auf frischen Referenz-VMs neu aufgelöst (Anleitung in VERIFY.md).

Grenzen dieser Iteration

Der Deploymentexecutor unterstützt Dienst, CLI und begrenzten einmaligen Job. CLI-Installation führt nur den deklarierten Funktionscheck aus; ein ausdrücklicher Aufruf erfolgt auf dem gebundenen Ziel mit sudo pipeline invoke --request /privater/aufruf.json --json. Eingabe und Ausgabe sind auf 64 KiB begrenzt. Jobs verlangen den Vertrag idempotent-operation-id und den vollständigen Argumentwert {pipeline.operation_id}; sichere Wiederholung der Anwendung bleibt eine ausdrücklich erklärte Voraussetzung. Unklar beendete CLI-Aufrufe werden nicht automatisch wiederholt. pipeline stop, start, uninstall und ausdrücklich purge --installation ID trennen Betrieb, Entfernung und Datenlöschung; Uninstall und Purge belassen Hostpakete, Dienstkonten, Netzisolation einschließlich des eigenen /etc/hosts-Blocks und den Speicherpool. pipeline upgrade führt ausschließlich die oben beschriebene gepinnte Gitea-Migration aus; dessen Hostlauf bleibt offen. Paketpayloads bis 16 MiB werden auf Zielen vollständig inspiziert; größere Programme sind in dieser Iteration nicht unterstützt. Welche Abnahmen A–N je Profil bestanden, teilweise bestanden oder offen sind, steht ausschließlich in VERIFY.md. Es wird keine Produktionsreife behauptet.

Der unabhängige, teilweise automatisierte Wegwerfhost-Testweg steht in tools/ACCEPTANCE.md im Quellarchiv; tools/testlab.py und tools/acceptance_lab.py stellen die in dieser Iteration verwendeten verschachtelten KVM-Wegwerfhosts bereit. Der Treiber steuert ausschließlich fest inventarisierte und separat markierte Hosts über geprüfte SSH-Schlüssel. Vollständige A–N-Abdeckung wird auch durch diesen Treiber nicht behauptet; D, E und F besitzen keine Live-Proben.