Übersicht
Standardmäßig erlaubt GitHub Actions die gleichzeitige Ausführung mehrerer Aufträge innerhalb desselben Workflows, mehrerer Workflow-Läufe innerhalb desselben Repositorys und mehrerer Workflow-Läufe über das Konto eines Repository-Eigentümers. Das bedeutet, dass mehrere Instanzen eines Workflows oder Auftrags gleichzeitig und mit denselben Schritten ausgeführt werden können.
GitHub Actions ermöglicht auch das Deaktivieren paralleler Ausführungen. Dies kann nützlich sein, um die Ressourcen deines Kontos oder deiner Organisation in Situationen zu kontrollieren, in denen die gleichzeitige Ausführung mehrerer Workflows oder Aufträge zu Konflikten führen oder mehr Actions-Minuten und Speicherplatz als erwartet verbrauchen könnte.
Die Möglichkeit, Workflows gleichzeitig laufen zu lassen, bedeutet zum Beispiel, dass, wenn mehrere Commits kurz hintereinander in ein Repository gepusht werden, jeder Push einen separaten Workflow-Lauf auslösen kann und diese Läufe dann gleichzeitig ausgeführt werden.
Verwenden der Parallelität in verschiedenen Szenarien
Du kannst jobs.<job_id>.concurrency verwenden, um sicherzustellen, dass immer nur ein einzelner Auftrag oder Workflow mit der gleichen Parallelitätsgruppe ausgeführt wird. Eine Parallelitätsgruppe kann eine beliebige Zeichenfolge oder ein beliebiger Ausdruck sein. Zulässiger Ausdruckskontext: github, inputs, vars, needs, strategy und matrix. Weitere Informationen zu Ausdrücken findest du unter Auswerten von Ausdrücken in Workflows und Aktionen.
concurrency kann auch auf Workflowebene angegeben werden. Weitere Informationen findest du unter concurrency.
Das bedeutet, dass es in einer Parallelitätsgruppe zu jedem Zeitpunkt höchstens einen ausgeführten und einen ausstehenden Auftrag geben kann. Wenn ein gleichzeitiger Auftrag oder ein Workflow in die Warteschlange gestellt wird, wenn ein anderer Auftrag oder Workflow, der dieselbe Übereinstimmungsgruppe im Repository verwendet, in Bearbeitung ist, wird pending der Warteschlangeauftrag oder der Workflow ausgeführt. Eventuell vorhandene Aufträge oder Workflows mit dem Status pending in derselben Parallelitätsgruppe werden abgebrochen und durch neue in die Warteschlange gestellte Aufträge oder Workflows ersetzt.
Du kannst auch mit cancel-in-progress: true alle derzeit ausgeführten Aufträge oder Workflows in derselben Parallelitätsgruppe abbrechen. Um aktuell ausgeführte Aufträge oder Workflows in derselben Parallelitätsgruppe bedingt abzubrechen, können Sie cancel-in-progress als Ausdruck mit einem der zulässigen Ausdruckskontexte angeben.
Note
- Beim Namen von Parallelitätsgruppen wird die Groß-/Kleinschreibung nicht berücksichtigt. Beispielsweise werden
produndProdals dieselbe Parallelitätsgruppe betrachtet. - Die Sortierung ist für Aufträge oder Workflowausführungen mit Parallelitätsgruppen nicht garantiert. Aufträge oder Workflowausführungen werden in derselben Parallelitätsgruppe in einer beliebigen Reihenfolge behandelt.
Beispiel: Verwenden der Parallelität und des Standardverhaltens
Das Standardverhalten von GitHub Actions erlaubt die gleichzeitige Ausführung mehrerer Aufträge bzw. Workflow-Läufe. Mit dem Schlüsselwort concurrency können Sie die Nebenläufigkeit von Workflow-Läufen steuern.
Sie können das Schlüsselwort concurrency zum Beispiel unmittelbar nach der Definition von Auslösebedingungen verwenden, um die Nebenläufigkeit ganzer Workflow-Läufe für eine bestimmte Verzweigung zu begrenzen:
on:
push:
branches:
- main
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true
Sie können auch die Parallelität von Aufträgen innerhalb eines Workflows begrenzen, indem Sie das Schlüsselwort concurrency auf Auftragsebene verwenden:
on:
push:
branches:
- main
jobs:
job-1:
runs-on: ubuntu-latest
concurrency:
group: example-group
cancel-in-progress: true
Beispiel: Parallelitätsgruppen
Parallelitätsgruppen bieten eine Möglichkeit zum Verwalten und Einschränken der Ausführung von Workflowausführungen oder Aufträgen, die denselben Parallelitätsschlüssel aufweisen.
Der concurrency-Schlüssel wird verwendet, um Workflows oder Aufträge in einer Parallelitätsgruppe zu gruppieren. Wenn Sie einen concurrency-Schlüssel definieren, stellt GitHub Actions sicher, dass immer nur ein Workflow oder Auftrag mit diesem Schlüssel ausgeführt wird. Wenn ein neuer Workflow oder Job mit demselben concurrency-Schlüssel gestartet wird, bricht GitHub Actions jeden bereits laufenden Workflow oder Job mit diesem Schlüssel ab. Der concurrency-Schlüssel kann eine hartcodierte Zeichenfolge oder ein dynamischer Ausdruck sein, der Kontextvariablen enthält.
Es ist möglich, Parallelitätsbedingungen in Ihrem Workflow zu definieren, sodass der Workflow oder Auftrag zum Teil einer Parallelitätsgruppe wird.
Dies bedeutet, dass GitHub, wenn ein Workflow ausgeführt oder Auftrag gestartet wird, alle Workflowausführungen oder Aufträge abbricht, die bereits in derselben Parallelitätsgruppe ausgeführt werden. Dies ist in Szenarien hilfreich, in denen Sie parallele Ausführungen für einen bestimmten Satz von Workflows oder Aufträgen verhindern möchten, z. B. die für Bereitstellungen in einer Stagingumgebung verwendeten, um Aktionen zu verhindern, die Konflikte verursachen oder mehr Ressourcen verbrauchen könnten, als nötig.
In diesem Beispiel ist job-1 Teil einer Parallelitätsgruppe mit dem Namen staging_environment. Dies bedeutet, dass, wenn eine neue Ausführung job-1 ausgelöst wird, alle Läufe desselben Auftrags in der bereits ausgeführten staging_environment-Parallelitätsgruppe abgebrochen werden.
jobs:
job-1:
runs-on: ubuntu-latest
concurrency:
group: staging_environment
cancel-in-progress: true
Alternativ bedeutet die Verwendung eines dynamischen Ausdrucks wie concurrency: ci-${{ github.ref }} in Ihrem Workflow, dass der Workflow oder Auftrag Teil einer Parallelitätsgruppe mit dem Namen ci- gefolgt von der Referenz der Verzweigung bzw. des Tags, der den Workflow ausgelöst hat, ist. Wenn in diesem Beispiel ein neuer Commit an die Standard-Verzweigung übertragen wird, während eine vorherige Ausführung noch ausgeführt wird, wird die vorherige Ausführung abgebrochen, und die neue gestartet:
on:
push:
branches:
- main
concurrency:
group: ci-${{ github.ref }}
cancel-in-progress: true
Beispiel: Verwenden von Parallelität zum Abbrechen eines In-Progress-Auftrags oder Ausführens
Um Parallelität zum Abbrechen eines laufenden Auftrags zu verwenden oder in GitHub Actions auszuführen, können Sie den concurrency-Schlüssel mit der cancel-in-progress-Option auf true verwenden:
concurrency:
group: ${{ github.ref }}
cancel-in-progress: true
Beachten Sie, dass in diesem Beispiel, ohne eine bestimmte Parallelitätsgruppe zu definieren, GitHub Actions jegliche laufende Ausführung eines Auftrags oder Workflows abbricht.
Beispiel: Verwenden eines Fallbackwerts
Wenn du den Gruppennamen mit einer Eigenschaft erstellst, die nur für bestimmte Ereignisse definiert ist, kannst du einen Fallbackwert verwenden. So wird beispielsweise github.head_ref nur für pull_request Ereignisse definiert. Wenn dein Workflow zusätzlich pull_request zu Ereignissen auf andere Ereignisse reagiert, musst du einen Fallback bereitstellen, um einen Syntaxfehler zu vermeiden. Die folgende Parallelitätsgruppe bricht laufende Aufträge oder Ausführungen nur bei pull_request Ereignissen ab. Wenn github.head_ref nicht definiert ist, greift die Parallelitätsgruppe auf die Ausführungs-ID zurück, die garantiert eindeutig und für die Ausführung definiert ist.
concurrency:
group: ${{ github.head_ref || github.run_id }}
cancel-in-progress: true
Beispiel: Nur laufende Aufträge oder Ausführungen für den aktuellen Workflow abbrechen
Wenn du mehrere Workflows im selben Repository hast, müssen die Namen der Parallelitätsgruppen für alle Workflows eindeutig sein, um zu vermeiden, dass laufende Aufträge oder Ausführungen von anderen Workflows abgebrochen werden. Andernfalls werden alle zuvor ausgeführten oder ausstehenden Aufgaben abgebrochen, unabhängig vom Workflow.
Um nur die Ausführung desselben Workflows abzubrechen, kannst du die github.workflow Eigenschaft verwenden, um die Parallelitätsgruppe zu erstellen:
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true
Beispiel: Nur laufende Aufträge auf bestimmten Branches abbrechen
Wenn Sie laufende Aufträge für bestimmte Branches abbrechen möchten, aber nicht für andere, können Sie bedingte Ausdrücke mit cancel-in-progress verwenden. Sie können z. B. auf diese Weise laufende Aufträge in Entwicklungsbranches abbrechen, aber nicht in Releasebranches.
Wenn Sie die laufenden Ausführungen desselben Workflows nur abbrechen möchten, wenn sie nicht in einem Releasebranch ausgeführt werden, können Sie cancel-in-progress auf einen Ausdruck ähnlich dem folgenden festlegen:
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: ${{ !contains(github.ref, 'release/')}}
In diesem Beispiel würden mehrere Pushvorgänge zu einem release/1.2.3-Branch die laufenden Ausführungen nicht abbrechen. Pushvorgänge zu einem anderen Branch, z. B. main, würde laufende Ausführungen abbrechen.
Überwachen deiner aktuellen Aufträge in deiner Organisation oder deinem Unternehmen
Um etwaige Einschränkungen bei Parallelität oder Queuing zu ermitteln, kannst du überprüfen, wie viele Aufträge derzeit auf den von GitHub gehosteten Runnern in deiner Organisation oder deinem Unternehmen verarbeitet werden. Weitere Informationen finden Sie unter Überwachen deiner aktuellen Aufträge.