Steuern der Gleichzeitigkeit von Workflows und Aufträgen

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.

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.

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:

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, 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.

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.

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: maxbis 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:

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:

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.

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:

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ürden laufende Ausführungen abbrechen.

Überwachung Ihrer aktuellen Jobs in Ihrer Organisation oder Ihrem 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 Anzeigen deiner aktuellen Aufträge.