# Steuern der Gleichzeitigkeit von Workflows und Aufträgen Verwalte, welche Workflows und Aufträge gleichzeitig ausgeführt werden können. ## Verwenden der Parallelität in verschiedenen Szenarien Du kannst `jobs..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`](/de/actions/reference/workflows-and-actions/contexts#github-context), [`inputs`](/de/actions/reference/workflows-and-actions/contexts#inputs-context), [`vars`](/de/actions/reference/workflows-and-actions/contexts#vars-context), [`needs`](/de/actions/reference/workflows-and-actions/contexts#needs-context), [`strategy`](/de/actions/reference/workflows-and-actions/contexts#strategy-context) und [`matrix`](/de/actions/reference/workflows-and-actions/contexts#matrix-context). Weitere Informationen zu Ausdrücken findest du unter [Auswerten von Ausdrücken in Workflows und Aktionen](/de/actions/reference/workflows-and-actions/expressions). `concurrency` kann auch auf Workflowebene angegeben werden. Weitere Informationen findest du unter [`concurrency`](/de/actions/reference/workflows-and-actions/workflow-syntax#concurrency). Dies bedeutet, dass es in einer Parallelitätsgruppe jederzeit höchstens einen ausgeführten Auftrag oder Workflow geben kann. Wenn ein gleichzeitiger Auftrag oder ein Workflow in die Warteschlange gestellt wird und ein anderer Auftrag oder Workflow, der dieselbe Konkurrenzgruppe im Repository verwendet, in Bearbeitung ist, wird der wartende Auftrag oder Workflow `pending`. Standardmäßig werden alle vorhandenen `pending` Jobs oder Workflows in derselben Parallelitätsgruppe abgebrochen, und der neue in die Warteschlange gestellte Auftrag oder Workflow übernimmt deren Platz. 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. Verwenden Sie die optionale `queue` Eigenschaft, damit mehr als eine `pending` Auftrags- oder Workflowausführung in derselben Parallelitätsgruppe warten kann. Die `queue` Eigenschaft akzeptiert die folgenden Werte: * `single` (Standard): Höchstens ein Auftrag oder eine Workflow-Ausführung kann in der Parallelitätsgruppe `pending` ausgeführt werden. Wenn ein neuer Auftrag oder ein neuer Workflow in die Warteschlange gestellt wird, wird jeder vorhandene `pending` Auftrag oder Workflow, der in derselben Gruppe ausgeführt wird, abgebrochen und ersetzt. * `max`: Bis zu 100 Aufträge oder Workflowausführungen können `pending` sich in der Parallelitätsgruppe befinden. Wenn die Warteschlange voll ist, werden alle zusätzlichen Aufträge oder Workflowausführungen abgebrochen. Die Kombination von `queue: max` und `cancel-in-progress: true` ist nicht zulässig und führt zu einem Workflowüberprüfungsfehler. > \[!NOTE] > > * Beim Namen von Konkurrenzgruppen wird die Groß-/Kleinschreibung nicht berücksichtigt. Beispielsweise werden `prod` und `Prod` als dieselbe Parallelitätsgruppe betrachtet. > * Aufträge oder Workflows in derselben Nebenläufigkeitsgruppe werden in der FIFO-Reihenfolge (First-in-First-Out) verarbeitet, je nach dem Zeitpunkt, an dem jeder Prozess angefangen hat, auf die Ausführung in der Nebenläufigkeitsgruppe zu warten, nicht die Zeit, zu der jeder Workflow gesendet wurde. Da die tatsächliche Startzeit eines Auftrags oder einer Ausführung variieren kann, ist die Reihenfolge nicht garantiert. ### Beispiel: Verwenden der Parallelität und des Standardverhaltens Das Standardverhalten besteht darin GitHub Actions , dass mehrere Aufträge oder Workflows gleichzeitig ausgeführt werden können. 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: ```yaml 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: ```yaml 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, wird sichergestellt, GitHub Actions dass immer nur ein Workflow oder Auftrag mit diesem Schlüssel ausgeführt wird. Wenn eine neue Workflowausführung oder ein neuer Auftrag mit demselben `concurrency` Schlüssel beginnt, wird GitHub Actions jeden Workflow oder Auftrag, der bereits mit diesem Schlüssel ausgeführt wird, abbrechen. 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 bestimmte Workflows oder Aufträge verhindern möchten, z. B. diejenigen, die für Bereitstellungen in einer Staging-Umgebung verwendet werden, um Konflikte zu vermeiden oder einen unnötig hohen Ressourcenverbrauch zu verhindern. In diesem Beispiel ist `job-1` Teil einer Parallelitätsgruppe mit dem Namen `staging_environment`. Dies bedeutet, dass, wenn eine neue Ausführung von `job-1` ausgelöst wird, alle Läufe desselben Auftrags in der `staging_environment`-Parallelitätsgruppe, die bereits im Gange sind, abgebrochen werden. ```yaml 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 Konkurrenzgruppe mit dem Namen `ci-` ist, gefolgt von der Referenz der Verzweigung oder des Tags, das den Workflow ausgelöst hat. Wenn in diesem Beispiel ein neuer Commit an den Hauptzweig übertragen wird, während eine vorherige Ausführung noch ausgeführt wird, wird die vorherige Ausführung abgebrochen und die neue gestartet. ```yaml on: push: branches: - main concurrency: group: ci-${{ github.ref }} cancel-in-progress: true ``` ### Beispiel: Warteschlange für mehrere ausstehende Ausführungen Standardmäßig kann sich jeweils nur ein Auftrag oder eine Workflowausführung in einer Konkurrenzgruppe befinden. Um zuzulassen, dass mehrere Durchläufe in die Warteschlange gestellt werden, anstatt abgebrochen zu werden, konfigurieren Sie `queue: max`. Mit `queue: max`bis zu 100 Aufträgen oder Workflowausführungen kann in der Parallelitätsgruppe gewartet werden. Sobald die Warteschlange voll ist, werden alle zusätzlichen Läufe abgebrochen. Beispielsweise werden die folgenden Workflowbereitstellungen in die Umgebung in die `production` Warteschlange gestellt, wobei sie jeweils einzeln verarbeitet werden, je nachdem, wann jede Ausführung gestartet wurde, die auf die Parallelitätsgruppe wartet: ```yaml on: push: branches: - main concurrency: group: production-deploy queue: max ``` Beachten Sie, dass `queue: max` nicht mit `cancel-in-progress: true` kombiniert werden kann, da die beiden Optionen widersprüchliche Verhaltensweisen für die Behandlung von laufenden Ausführungen beschreiben. ### Beispiel: Verwenden von Parallelität zum Abbrechen eines In-Progress-Auftrags oder Ausführens Um Parallelität zum Abbrechen eines laufenden Auftrags oder einer Ausführung in GitHub Actions zu verwenden, können Sie den `concurrency`-Schlüssel mit der `cancel-in-progress`-Option auf `true` festlegen: ```yaml concurrency: group: ${{ github.ref }} cancel-in-progress: true ``` Beachten Sie, dass in diesem Beispiel, ohne eine bestimmte Parallelitätsgruppe zu definieren, GitHub Actions\_jede\_ laufende Ausführung des 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 zu `pull_request`-Ereignissen auf andere Ereignisse reagiert, musst du einen Fallback implementieren, 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. ```yaml concurrency: group: ${{ github.head_ref || github.run_id }} cancel-in-progress: true ``` ### Beispiel: Nur laufende Aufträge oder Vorgänge 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: ```yaml 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: ```yaml 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ürden laufende Ausführungen abbrechen. ## Überwachung Ihrer aktuellen Jobs in Ihrer Organisation oder Ihrem Unternehmen Um Einschränkungen mit Parallelität oder Warteschlangen zu identifizieren, können Sie überprüfen, wie viele Aufträge derzeit in den GitHubgehosteten Läufern in Ihrer Organisation oder Ihrem Unternehmen verarbeitet werden. Weitere Informationen finden Sie unter [Anzeigen deiner aktuellen Aufträge](/de/actions/how-tos/manage-runners/github-hosted-runners/view-current-jobs).