アクションの制限

スケールアップする際に直面する可能性がある GitHub Actions には制限があり、一部はサポートに問い合わせることで増やすことができます。

この記事で

使用量をスケーリングすると、 GitHub Actions によってレートが制限される場合があります。 一部の制限は、 サイト管理者に連絡することで増やすことができます。

特に明記されていない限り、制限に達したときに予想される動作として、ワークフローやジョブの取り消しが挙げられます。

これらの制限は変更されることがあります。

既存システムの制限

制限のカテゴリ制限Threshold説明サポートをGitHub増やすことは可能ですか?
ワークフロー実行制限ワークフロー実行時間35 日/ワークフロー実行ワークフローの実行がこの制限に達すると、そのワークフローの実行はキャンセルされます。 この期間には、実行時間と、待機と承認に費やされた時間が含まれます。
ワークフロー実行制限ゲート承認時間30 日ワークフローは、環境の承認を最大 30 日間待機できます。
ワークフロー実行制限ジョブ マトリックス256 ジョブ/ワークフロー実行ジョブ マトリックスでは、ワークフロー実行ごとに最大 256 個のジョブを生成できます。 この制限は、 GitHubホストランナーとセルフホステッド ランナーの両方に適用されます。
ワークフロー実行制限再実行50 回の再実行ワークフローの実行は、最大 50 回再実行できます。 この制限には、完全な再実行とジョブのサブセットの再実行の両方が含まれます。
          <svg version="1.1" width="16" height="16" viewBox="0 0 16 16" class="octicon octicon-check" aria-label="Yes" role="img"><path d="M13.78 4.22a.75.75 0 0 1 0 1.06l-7.25 7.25a.75.75 0 0 1-1.06 0L2.22 9.28a.751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018L6 10.94l6.72-6.72a.75.75 0 0 1 1.06 0Z"></path></svg> サポート チケット |

| ワークフロー キュー | ワークフローのトリガー イベント レート制限 | 1,500 イベント/10 秒/リポジトリ | ワークフロー実行をトリガーするイベントの数には、リポジトリごとの制限があります。 | サポート チケット | | ワークフロー キュー | キューに登録されたワークフロー実行 | 500 ワークフロー実行/10 秒 | 制限に達すると、Webhook イベントによってトリガーされるはずのワークフロー実行が禁止され、キューに登録されません。 再利用可能なワークフローは、1 つのエンティティと見なされます。 たとえば、30 の再利用可能なワークフローを含む実行は、このインスタンスでは 1 とカウントされます。 | | | セルフホステッド | ランナー登録数 | 1,500 ランナー/5 分/リポジトリ/組織/エンタープライズ | ランナーは、リポジトリ/組織/エンタープライズごとに登録できます。 | サポート チケット | | セルフホステッド | ランナー グループあたりのランナー数 | 10,000 ランナー | ランナー グループごとに同時登録されるランナー数。 | | | セルフホステッド | ジョブの実行時間 | 5 日 | ワークフローの各ジョブは、最大で 5 日まで実行できます。 ジョブはこの制限に達すると、強制的に終了され、失敗として扱われます。 | | | セルフホステッド | ジョブ キュー時間 | 24 時間 | ジョブはキューに 24 時間登録されてから、自動的に取り消されます。 | | | すべての GitHub ホステッド ランナー | ジョブのコンカレンシー | 場合により異なる | GitHubホストされたランナーのジョブ同時実行制限を参照してください。 | サポート チケット | | すべての GitHubホストランナー | ジョブの実行時間 | 6 時間 | ワークフローの各ジョブは、最大で 6 時間まで実行できます。 ジョブはこの制限に達すると、強制的に終了され、失敗として扱われます。 | | | | | より大きなランナー | ランナーごとの同時実行制限数 | ランナーの種類によって異なります | ランナーのセットアップ時に設定されます。 通常、Linux CPU ランナーの場合は最大 1,000 ですが、種類によって異なります。 GitHub ホステッド ランナーの ジョブ コンカレンシー制限を参照してください。 | サポート チケット | | より大きなランナー | 静的 IP 制限 | 10 個の IP | 企業および組織あたり 10 個の IP。 | サポート チケット | | より大きなランナー | VNet インジェクション向けプライベート IP 拡張 | 30% バッファー | 予想される最大ジョブ同時実行に対応するためのバッファーが必要です。 「大規模ランナーの VNet インジェクション向けプライベート IP 拡張」を参照してください。 | 構成可能なAzure仮想ネットワーク | | 依存関係キャッシュ | 1 分あたりのアップロード数 | 1 分あたり 200 | 各リポジトリは、1 分あたり 200 個のキャッシュ エントリアップロードに制限されています。 この制限を超えた場合、レート制限がリセットされるまで、後続のキャッシュ アップロードの試行は失敗します。 | | | 依存関係キャッシュ | 1 分あたりのダウンロード数 | 1 分あたり 1500 | 各リポジトリは、1 分あたり 1500 キャッシュ エントリのダウンロードに制限されています。 この制限を超えた場合、レート制限がリセットされるまで、後続のキャッシュダウンロードの試行は失敗します。 | | | 依存関係キャッシュ | 1 分あたりの削除数 | 1 分あたり 400 | 各リポジトリは、1 分あたり 400 個のキャッシュ削除操作に制限されます。 この制限を超えた場合、レート制限がリセットされるまで、後続のキャッシュ削除の試行は失敗します。 キーまたは ID によってキャッシュを削除する各要求は、この制限にカウントされます。 | |

GitHub ホステッド ランナーの ジョブ コンカレンシー制限を参照してください

         GitHub サポート** により、**GitHub Actions のジョブのコンカレンシー制限が増加数する可能性があります。 増加を要求するには、サポート チケットを送信します。

| ランナー タイプ | GitHub 計画 | 最大同時ジョブ | 最大同時macOSジョブ | GPU ジョブ同時実行の最大数 | |---|---|---|---|---| | 標準 GitHub ホステッド ランナー | Free | 20 | 5 | 適用なし | | 標準 GitHub ホステッド ランナー | Pro | 40 | 5 | 適用なし | | 標準 GitHub ホステッド ランナー | チーム | 60 | 5 | 適用なし | | 標準 GitHub ホステッド ランナー | Enterprise | 500 | 50 | 適用なし | | より大きなランナー | チーム | 1000 | 5 | 100 | | より大きなランナー | Enterprise | 1000 | 50 | 100 |

メモ

最大同時 macOS ジョブは、標準の GitHubホストランナーと GitHubホスト型の大規模ランナー間で共有されます。

すべての GitHub ホステッド ランナーの記憶域の制限

          GitHubサポート**では、**GitHub Actionsのストレージ制限を増やすことはできません。
Planアーティファクト ストレージ分 (月あたり)キャッシュ ストレージ
{％ data variables.product.prodname_free_user ％}500 MB2,00010 GB
GitHub Pro1 GB3,00010 GB
組織の GitHub Free500 MB2,00010 GB
GitHub Team2 GB3,00010 GB
GitHub Enterprise Cloud50 GB50,00010 GB

より大きなランナーの VNet インジェクションのプライベート IP 拡張

VNet インジェクションでより大きなランナーを使うときは、適切なサブネット IP アドレス範囲を決める必要があります。その場合、予想されるジョブ同時実行最大数にバッファーを追加することをお勧めします。 たとえば、ネットワーク構成のランナーが、300 のジョブ同時実行最大数に設定されている場合は、少なくとも 390 ランナーに対応できるサブネット IP アドレス範囲を使用します。 Azureでは、すべてのサブネット (最初の 4 と最後の 1) に 5 つの IP が予約され、ランナーの要件に応じて最小限の実用的なサブネット サイズが設定されることに注意してください。 非常に小さいサブネット (/29 以下など) では、ニーズに十分な使用可能アドレスが提供されない場合があります。

一般的なヒットに依存するサービスの制限

          GitHubの [REST API レート制限](/rest/using-the-rest-api/rate-limits-for-the-rest-api) は、 GitHub Actions ユーザーに適用されます。一般的にヒットするユーザーは次のとおりです。

  • 認証されていないユーザー-パブリック データのみをフェッチする場合は、認証されていない要求を行うことができます。 認証されていない要求は、要求を行ったユーザーまたは申請ではなく、発信元の IP アドレスに関連付けられます。

    認証されていない要求のプライマリ レート制限は、1 時間あたり 60 要求です。

  • 認証済みユーザー-personal access token を使用して API 要求を行うことができます。 さらに、GitHub App または OAuth app でも、次にユーザーに代わって API 要求を行うことができます。

    これらの要求はすべて、1 時間あたり 5000 件の個人的レート制限に向けてカウントされます。

  • GitHub アプリのインストール-インストール アクセス トークンを使って認証された GitHub Apps は、インストールの最小レート制限である 1 時間あたり 5,000 要求を使います。 GitHub Enterprise Cloud organization 上のインストールの場合、インストールには 1 時間あたり 15,000 要求というレート制限があります。

    GitHub Enterprise Cloud organization 上ではないインストールの場合、インストールのレート制限はユーザーとリポジトリの数に応じてスケーリングされます。 20以上のリポジトリを持つインストールでは、リポジトリごとにⅠ時間あたり50リクエストが追加されます。 ユーザー数が 20 人を超える組織のインストールでは、ユーザーごとに 1 時間あたり別の 50 要求を受け取ります。 レート制限は、1 時間あたり 12,500 要求を超えて増やすことはできません。

    GitHub App ユーザー アクセス トークンのプライマリ レート制限 (インストール アクセス トークンとは対照的) は、認証されたユーザーのプライマリ レート制限によって決まります。 このレート制限は、別の GitHub App または OAuth app がそのユーザーに代わって行う要求と、ユーザーが personal access token で行った要求と組み合わされます。 詳しくは、「REST API のレート制限」をご覧ください。

  • OAuth アプリ

  • GITHUB トークン-GITHUB_TOKEN のレート制限は、リポジトリごとに 1 時間あたり 1,000 要求です。GitHub Enterprise Cloud アカウントに属するリソースへの要求では、制限はリポジトリごとに 1 時間あたり 15,000 要求です。

  • 2 次レート制限- プライマリ レート制限に加えて、 GitHub では、不正使用を防ぎ、すべてのユーザーが API を使用できるようにセカンダリ レート制限を適用します。これらは GHEC では構成できません。 詳しくは、「REST API のレート制限」をご覧ください。

          GitHub Actions のDocker Hubのレート制限

  •           **                            パブリック イメージをプルする  GitHub ホステッド ランナー: ** Docker Hub のレート制限は適用されません。

          GitHub ホストランナーがプライベート イメージをプルする:** Docker Hubからのプライベート イメージのプルにはレート制限が適用されます。
  • パブリックイメージまたはプライベートイメージをプルするセルフホステッド ランナー: Docker Hubからのイメージのプルには常にレート制限が適用されます。