コンカレンシーの使用

概要

既定では、GitHub Actions では、同じワークフロー内の複数のジョブ、同じリポジトリ内での複数のワークフローの実行、およびリポジトリ所有者のアカウント全体で複数のワークフロー実行を同時開催で実行できます。つまり、複数のワークフローの実行、ジョブ、またはステップを同時に実行できます。

GitHub Actions を使用すると、ワークフロー実行のコンカレンシーを制御することもできます。これにより、特定のコンテキストで一度に 1 つの実行、1 つのジョブ、または 1 つのステップのみを実行できます。これは、複数のワークフロー、ジョブ、またはステップを同時に実行すると競合が発生したり、操作の分とStorageが予想以上に多く実行する可能性がある状況で、アカウントまたは組織のリソースを制御する場合に役立ちます。

たとえば、ワークフローを同時に実行する機能は、複数のコミットがリポジトリに連続してプッシュされると、各プッシュで個別のワークフロー実行がトリガーされ、これらの実行が同時開催で実行されることを意味します。

さまざまなシナリオでのコンカレンシーの使用

同じコンカレンシーグループを使うジョブまたはワークフローを一度に 1 つだけ実行するには、jobs.<job_id>.concurrency を使います。並行処理グループには、任意の文字列または式を使用できます。使用できる式コンテキスト: github、inputs、vars、needs、strategy、matrix。式の詳細については、「式」を参照してください。

ワークフローレベルで concurrency を指定することもできます。詳細については、「concurrency」を参照してください。

並行ジョブかワークフローがキューに入っている場合、リポジトリ内の同じ並行グループを使う他のジョブかワークフローが進行中だと、キューイングされたジョブかワークフローは pending になります。この並行グループ内の以前の保留中のジョブもしくはワークフローは、キャンセルされます。同じコンカレンシーグループ内の現在実行中のジョブかワークフローもキャンセルするには、cancel-in-progress: true を指定します。

注:

コンカレンシーグループ名では大文字と小文字が区別されません。たとえば、prod と Prod は同じコンカレンシーグループとして扱われます。
ジョブまたはコンカレンシーグループを使用して実行する場合、順序付けは保証されず、処理される順序で処理されます。

例：コンカレンシーとデフォルトビヘイビアーの使用

GitHub Actions のデフォルトビヘイビアーでは、複数のジョブまたはワークフロー実行を同時開催で実行できます。 concurrency キーワードを使用すると、ワークフロー実行のコンカレンシーを制御できます。

たとえば、トリガー条件が定義された直後にconcurrencyキーワードを使用して、特定のブランチに対するワークフロー実行全体のコンカレンシーを制限できます：

on:
  push:
    branches:
      - main

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

ジョブレベルでconcurrencyキーワードを使用して、ワークフロー内のジョブのコンカレンシーを制限することもできます：

on:
  push:
    branches:
      - main

jobs:
  job-1:
    runs-on: ubuntu-latest
    concurrency:
      group: example-group
      cancel-in-progress: true

例: コンカレンシーグループ

コンカレンシーグループは、同じコンカレンシー鍵を共有するワークフロー実行またはジョブの実行を管理および制限する方法を提供します。

concurrency 鍵は、ワークフローまたはジョブをまとめてコンカレンシーグループにグループ化するために使用されます。 concurrency鍵を定義すると、GitHub Actions によって、その鍵を持つワークフローまたはジョブが常に 1 つだけ実行されるようになります。新しいワークフローの実行またはジョブが同じ concurrency 鍵で開始された場合、GitHub Actions はその鍵で既に実行されているワークフローまたはジョブをキャンセルします。 concurrency鍵は、ハードコーディングされた文字列にすることも、コンテキスト変数を含む動的な式にすることもできます。

ワークフローまたはジョブがコンカレンシーグループの一部になるように、ワークフローでコンカレンシー条件を定義できます。

つまり、ワークフローの実行またはジョブが開始されると、GitHub は、同じコンカレンシーグループで既に進行状況にあるワークフローの実行またはジョブをキャンセルします。これは、競合を引き起こしたり、必要以上に多くのリソースを消費したりする可能性のある処置を防ぐために、ステージング環境への展開に使用されるワークフローやジョブの特定のセットに対する並列実行を防ぐ場合に便利です。

この例では、 job-1は、staging_environmentと名付けられたコンカレンシーグループの一部です。つまり、新しいjob-1 の実行がトリガーされると、既に進行状況の staging_environmentコンカレンシーグループ内の同じジョブの実行はすべてキャンセルされます。

jobs:
  job-1:
    runs-on: ubuntu-latest
    concurrency:
      group: staging_environment
      cancel-in-progress: true

または、ワークフロー内などの concurrency: ci-${{ github.ref }}のような動的な式を使用すると、ワークフローまたはジョブは、ワークフローをトリガーしたブランチまたはタグのリファレンスに続く ci-と名付けられたコンカレンシーグループの一部になります。この例では、前の実行の進行中に新しいコミットがメインブランチにプッシュされた場合、前の実行はキャンセルされ、新しいコミットが開始されます：

on:
  push:
    branches:
      - main

concurrency: ci-${{ github.ref }}

並行性を使って進行中のジョブもしくは実行をキャンセルする例

コンカレンシーを使用して進行状況のジョブをキャンセルするか、GitHub Actions で実行するには、concurrency鍵を使用でき、次のcancel-in-progressオプションをtrueに設定します：

concurrency:
  group: ${{ github.ref }}
  cancel-in-progress: true

この例では、特定のコンカレンシーグループを定義せずに、GitHub Actions はジョブまたはワークフローの_どんな_進行状況の実行もキャンセルします。

例: フォールバック値の使用

特定のイベントにのみ定義されるプロパティでグループ名を作成する場合、フォールバック値を使用できます。たとえば、github.head_ref は pull_request イベントにのみ定義されます。ワークフローが pull_request イベントに加えて他のイベントにも応答する場合、構文エラーを回避するためにフォールバックを指定する必要があります。次のコンカレンシーグループは、pull_request イベントで進行中のジョブか実行のみを取り消します。github.head_ref が未定義の場合、コンカレンシーグループは実行 ID にフォールバックします。これは、一意であり、実行に対して定義されていることが保証されています。

concurrency:
  group: ${{ github.head_ref || github.run_id }}
  cancel-in-progress: true

例: 現在のワークフローで進行中のジョブまたは実行のみを取り消します

同じリポジトリに複数のワークフローがある場合、他のワークフローの進行中のジョブまたは実行が取り消されないように、コンカレンシーグループ名はワークフロー間で一意である必要があります。そうでない場合、ワークフローに関係なく、以前に進行中または保留中のジョブが取り消されます。

同じワークフローの進行中の実行だけを取り消すには、github.workflow プロパティを使ってコンカレンシーグループを構築します。

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

組織または企業の現在のジョブの監視

コンカレンシーまたはキューに関する制約を特定するには、組織や企業で GitHub ホステッドランナーで現在処理されているジョブの数を確認できます。詳しくは、「現在のジョブの監視」を参照してください。

コンカレンシーの使用

この記事の内容