Schnelleinstieg: Die erste Pipeline starten und ihr Protokoll lesen

Der kürzeste Weg von „Plugin ist installiert“ zu „ein Lauf ist verzeichnet, Ihnen zugeschrieben, und seine drei Protokollströme sind lesbar“. Drei Schritte, etwa zehn Minuten.

Voraussetzungen

wkdopipelines, wkdocore, wkdostorage und wkcore sind installiert und aktiviert.
Ein Projekt, und darin eine definierte Pipeline. Gibt es keine, meldet der Bildschirm das: Für dieses Projekt sind noch keine Pipelines definiert.
Die Berechtigung zum Starten. Sie ist nicht dieselbe wie die zum Ansehen — siehe Schritt 1.
Der Server kann ausführen, was die Pipeline aufruft, und zwar als der Benutzer, unter dem der Webserver läuft.

Schritt 1: Nachsehen, welche Berechtigung Sie haben

Zwei verschiedene Fragen steuern dieses Plugin:

Handlung	Gefragt wird nach
Läufe und Protokolle ansehen	Ihrer Projektrolle
Einen Lauf starten	dem weiteren Berechtigungszusammenhang

Eine Pipeline sehen zu dürfen heißt nicht, sie starten zu dürfen. Diese Unwucht ist beabsichtigt: Eine Historie zu lesen ist gewöhnliche Projektmitgliedschaft, einen Prozess auf dem Server zu starten ist es nicht.

Schritt 2: Starten

Öffnen Sie den Hub Pipelines des Projekts:

/doku.php?id=de:projects:acme:pipelines&do=wkdopipelines

Wählen Sie eine Pipeline aus der Liste und starten Sie sie.

Schritt 3: Das Protokoll lesen

Öffnen Sie den Lauf. Das Protokoll ist in drei getrennten Strömen festgehalten:

Strom	Inhalt
`out`	Was der Prozess auf die Standardausgabe geschrieben hat.
`err`	Was der Prozess auf die Standardfehlerausgabe geschrieben hat.
`sys`	Was der Ausführer selbst getan hat — sein eigener Bericht über den Versuch.

Der dritte ist der, den niemand erwartet, und der, der die erste Frage nach einem Fehlschlag beantwortet.

Ergebnis prüfen

Der Lauf steht in der Liste mit Status (wartet, läuft, erfolgreich, fehlgeschlagen, abgebrochen), Gestartet, Beendet, Exit-Code und Ausgelöst von — und dort steht Ihr Name.
Alle drei Ströme sind einzeln lesbar.
Die Laufhistorie enthält frühere Läufe mit ihren Handelnden und Ergebnissen. „Gestern ging es noch“ ist damit nachprüfbar statt erinnert.

So unterscheiden Sie mit sys die beiden Fehlschläge, die sonst gleich aussehen — der Prozess ist gescheitert, oder der Ausführer hat ihn nie gestartet:

Etwas in out/err und ein Fehlschlag → der Prozess lief und scheiterte.
Nichts in out/err, etwas in sys → er wurde nie gestartet, und sys sagt warum.

Ein zusammengelegtes Protokoll macht genau diese Unterscheidung am schwersten. Getrennte Ströme machen sie zum Ersten, was man sieht.

Nächster Schritt

wkdopipelines — Referenz: die Ausführungsregeln, der Ausführer und der Protokollschreiber.
wkdodashboard — die Pipelines des Projekts auf der Eingangsseite.