Hinweis: GitHub-gehostete Runner werden auf GitHub Enterprise Server derzeit nicht unterstützt. Weitere Informationen zur geplanten zukünftigen Unterstützung findest Du in der GitHub public roadmap.
Übersicht
Hinweis: Wenn Parallelität auf Auftragsebene angegeben wird, wird die Reihenfolge für Aufträge oder Ausführungen, die der Warteschlange innerhalb eines Zeitraums von bis zu fünf Minuten hinzugefügt werden, nicht garantiert.
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 Ausdrücke.
concurrency kann auch auf Workflowebene angegeben werden. Weitere Informationen findest du unter concurrency.
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. Alle zuvor anhängigen Aufträge oder Workflows in der Parallelitätsgruppe werden abgebrochen. Du kannst auch mit cancel-in-progress: true alle derzeit ausgeführten Aufträge oder Workflows in derselben Parallelitätsgruppe abbrechen.
Hinweis: Bei den Namen von Parallelitätsgruppen wird die Groß-/Kleinschreibung nicht beachtet. Beispielsweise werden prod und Prod als dieselbe Parallelitätsgruppe betrachtet.
Beispiele: Verwenden der Parallelität und des Standardverhaltens
concurrency: staging_environment
concurrency: ci-${{ github.ref }}
Beispiel: Verwenden von Parallelität zum Abbrechen eines In-Progress-Auftrags oder Ausführens
concurrency:
group: ${{ github.ref }}
cancel-in-progress: true
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