Zusammenfassung

  • Die Concurrency-Funktion von GitHub Actions erfasst Jobs oder Workflow-Läufe, die sich in dieselbe benannte Gruppe auflösen; wartende Arbeit kann je nach Einstellung ersetzt, eingereiht oder abgebrochen werden.
  • GitHub dokumentiert Concurrency und environment als nicht automatisch verbunden. Ein anderer Workflow im gleichen Environment unterliegt nicht zwingend der gewählten Gruppenregel.
  • Die Aussage, ein Deployment sei serialisiert gewesen, braucht den expandierten Gruppenschlüssel, Mitgliedschaft und Disposition, Ausführungsaufzeichnungen und eine Zielbeobachtung — nicht bloß einen konfigurierten Gruppennamen.

„Produktion wird serialisiert“ benennt oft eine Absicht statt einer Beobachtung. GitHub Actions erlaubt, einem Workflow oder Job eine Concurrency-Gruppe zuzuweisen. Damit lässt sich parallel laufende benannte Arbeit begrenzen, ein wartender Lauf durch einen neueren ersetzen oder — wenn Queueing ausdrücklich gewählt wird — weitere wartende Arbeit erhalten. Das ist ein nützliches Scheduling-Control. Die Gruppe erfasst jedoch nicht automatisch jeden Pfad, der ein Ziel berühren kann. Ihr Geltungsbereich beginnt bei den Jobs und Läufen, die sich tatsächlich in diese Gruppe auflösen.

Schon das Standardverhalten verlangt Genauigkeit. GitHub beschreibt für eine Gruppe einen laufenden und einen wartenden Eintrag; ein weiterer wartender Kandidat kann den früheren wartenden Eintrag ersetzen. queue: max verändert dieses Verhalten durch eine begrenzte Warteschlange. cancel-in-progress: true kann dagegen auch bereits laufende Arbeit abbrechen. Das sind unterschiedliche Dispositionen. Der Nachweis, dass ein Lauf in die Warteschlange kam, beweist nicht, dass der vorher wartende Lauf erhalten blieb. Ein Abbruchnachweis sagt auch nicht, welche Schritte bis dahin fertig waren. Daraus folgt weder, dass kein externer Aufruf geschah, noch dass kein Artefakt veröffentlicht oder kein Ziel verändert wurde.

Auch die Reihenfolge darf nicht aus dem Namen abgeleitet werden. GitHub beschreibt eine FIFO-Behandlung eingereihter Arbeit ab dem Zeitpunkt, zu dem ein Lauf zu warten begann, und weist darauf hin, dass die tatsächliche Startzeit variieren kann. Eine Gruppe ist deshalb keine Kurzform für eine universelle Zeitgeschichte. Wer eine Reihenfolge behauptet, braucht den wirksamen expandierten Schlüssel, die Identitäten der relevanten Jobs oder Läufe, ihre Warte-, Start- und Abschlusszeiten sowie die Identitäten von Quelle und Artefakt. Allein die sichtbare Dispatch-Zeit beantwortet diese Frage nicht.

Für Deployment-Aussagen ist der Unterschied zwischen Concurrency und environment besonders wichtig. GitHub sagt ausdrücklich, dass beides nicht verbunden ist: Der Concurrency-Wert kann ein beliebiger String sein; ein Workflow, der dasselbe Environment benutzt, aber die Gruppe nicht angibt, fällt nicht unter deren Regel. Ein Environment kann eigene Controls wie Schutzregeln und Secrets haben. Sie ersetzen keinen gemeinsamen Gruppenausdruck. Umgekehrt ist ein gemeinsamer Gruppenausdruck kein universelles Schloss für das Environment. Es sind getrennte Konfigurationsflächen.

Die API für Concurrency-Gruppen kann aktive Gruppenmitglieder samt Run- oder Job-IDs und Status pending oder in-progress anzeigen. Das ist wertvolle operative Evidenz. Ihr Umfang bleibt gegenwartsbezogen und plattformgebunden: Sie bildet weder alle vergangenen Befehle noch den Zustand eines Ziels ab. Eine spätere Zielprüfung bleibt eine eigenständige Aufzeichnung mit Methode und Zeitpunkt.

Daniel Kade empfiehlt einen Serialisierungsbeleg aus sieben Teilen: Concurrency-Ausdruck und expandierten Schlüssel bewahren; Queue- und Abbruchpolitik bewahren; jede relevante Run- und Job-Mitgliedschaft mit Zeit und Disposition festhalten; exakten Commit und unveränderliches Artefakt festhalten; Environment-Auswahl separat sichern; Ausführungsevidenz sichern; und eine zeitlich begrenzte Zielbeobachtung festhalten. Sensible Zieldetails können geschützt bleiben. Fehlende Verbindungen sollten sichtbar bleiben, statt durch das beruhigende Etikett einer Gruppe ergänzt zu werden.

Quellen

  1. GitHub Docs — Concurrency
  2. GitHub Docs — Workflow syntax
  3. GitHub Docs — Deploying with GitHub Actions
  4. GitHub Docs — Actions concurrency groups REST API