Action Runs¶

Ein ActionRun ist die Ausführung einer Block-Action in einem Workspace — zum Beispiel install, deploy, status oder eine benutzerdefinierte Action. Die Polycrate API protokolliert jede Ausführung als ManagedObject, speichert Logs und erzeugt Aktivitäten im System.

Wer wissen will "wer hat wann welche Action auf welchem Block ausgeführt und was ist dabei herausgekommen?" — der fragt ActionRuns.

Kernfelder¶

Feld	Bedeutung
`action`	Name der ausgeführten Action (z. B. `install`)
`block`	FK auf den Block, dessen Action gelaufen ist
`workspace` / `organization`	Kontext der Ausführung
`user`	Wer hat die Ausführung ausgelöst
`status`	`pending` → `running` → `success` / `failed`
`log_stdout` / `log_stderr`	Vollständige Ausgabe der Action (in der DB gespeichert)
`exit_code`	Exit-Code des Ansible-Playbooks / Block-Skripts
`start_time` / `end_time`	Zeitstempel — Grundlage für Dauer-Metriken

Bemerkenswert:

Logs stehen in der Datenbank. Es ist keine externe Log-Pipeline nötig, um die Ausgabe eines Runs wiederzufinden.
Keine Parent-Hierarchie: ein ActionRun hat keinen WorkflowRun-Parent. Workflows werden aktuell über Activity-Einträge korreliert, nicht über ein eigenes Parent-Objekt.
cancelled ist kein Status: erlaubte Endzustände sind ausschließlich success und failed. Wer einen Lauf hart abbricht, landet je nach Ursache in failed.

Statusfluss¶

   pending ──▶ running ──▶ success
                     └───▶ failed

pending — der Run ist akzeptiert, steht aber noch in der Warteschlange (z. B. weil der zuständige Agent gerade beschäftigt ist).
running — die Action läuft aktuell. start_time ist gesetzt, end_time noch nicht.
success — die Action ist mit exit_code=0 fertig geworden.
failed — die Action hat abgebrochen (exit_code ≠ 0, Timeout, Agent-Abbruch).

Woher ActionRuns kommen¶

Ein ActionRun wird erzeugt, wenn eine Action über einen dieser Wege gestartet wird:

UI — Action-Button auf einem Block oder dessen Objekten.
CLI — polycrate run <block> <action>, sofern das Workspace mit der API verbunden ist.
Operator — der Polycrate-Operator ruft eine Action via API-Token aus (z. B. status als Reconciler-Loop oder install bei neuem K8sApp-CR).

Aktivitäten im System:

block_action_run_start beim Start
block_action_run_finish nach Beendigung (mit Ergebnis)

Diese Aktivitäten landen im Activity-Feed des Workspaces und der Organisation und können im Prometheus-Export pro Minute aggregiert werden.

Detail-View¶

Der Detail-View eines ActionRuns enthält:

Metadaten: wer, wann, Block, Action, Status, Exit-Code, Dauer.
Logs: stdout und stderr separat, per Default live-streamend, wenn der Run noch läuft.
Links: zum ausgeführten Block, zur Action-Definition, zum verursachenden Objekt (z. B. K8sApp, wenn die Action durch den Operator angetriggert wurde).
Related Activities: Vor und nach dem Run entstandene Aktivitäten im selben Kontext.

Typische Use Cases¶

Troubleshooting nach fehlgeschlagenem Deploy: Ein Deployment schlägt fehl — Benutzer klickt im K8sApp-Detail auf den letzten Run und sieht stdout/stderr direkt im Browser, inkl. Ansible-Task-Trace.
Audit: "Wer hat am Dienstag die uninstall-Action des Vault-Blocks angestoßen?" — über die ActionRun-Liste mit Filter auf Block, Action und Zeitraum in Sekunden beantwortet.
Operator-Observability: Der Operator erzeugt regelmäßig status-Runs pro K8sApp. Deren Dauer und Erfolgsrate sind über die System-Metriken sichtbar und ein Gradmesser für Cluster-Gesundheit.

Zugriffskontrolle¶

Ein ActionRun ist über Organisation und Workspace ge-scoped.
Wer Leserechte auf den Workspace hat, sieht die Liste seiner ActionRuns.
Wer Leserechte auf den Block hat, darf dessen stdout/stderr einsehen.
Das Starten neuer Actions erfordert Schreibrechte auf den Workspace (siehe User Management & RBAC).

Aufbewahrung¶

Logs bleiben in der Datenbank gespeichert — kein externer Storage notwendig. Eine Retention-Policy kann per Management-Command gesetzt werden, um alte Runs automatisiert zu archivieren oder zu löschen (siehe Management Commands).