Organization について GitHub Actions を無効化または制限する

注: GitHub ホステッドランナーは、現在 GitHub Enterprise Server でサポートされていません。 GitHub public roadmap で、今後の計画的なサポートの詳細を確認できます。

Organization の GitHub Actions 権限について

既定では、after GitHub Actions がお使いの GitHub Enterprise Server インスタンス上で有効になると、はすべてのリポジトリと組織で有効になります。 GitHub Actions を無効にするか、または Enterprise のアクションに制限することができます。 GitHub Actions について詳しくは、「GitHub Actions について」を参照してください。

Organization のすべてのリポジトリについて GitHub Actions を有効化することができます。 GitHub Actions を有効にすると、ワークフローはリポジトリ内および他のパブリックまたは内部のリポジトリに配置されているアクションを実行できます。組織のすべてのリポジトリについて、GitHub Actions を無効化できます。 GitHub Actionsを無効化すると、リポジトリでワークフローが実行されなくなります。

または、Organization 内のすべてのリポジトリに対して GitHub Actions を有効にできますが、ワークフローが実行できるアクションにアクションを制限できます。

Organization の GitHub Actions 権限の管理

組織内のすべてのリポジトリに対して GitHub Actions を無効にするか、特定のリポジトリのみを許可するかを選択できます。また、パブリックアクションの使用を制限して、Enterprise 内に存在するローカルアクションのみを使用できるようにすることもできます。

注: 組織が、優先ポリシーのあるエンタープライズによって管理されている場合、これらの設定を管理できない場合があります。詳しくは、「エンタープライズで GitHub Actions のポリシーを適用する」を参照してください。

GitHub の右上隅で、プロフィール写真を選択し、 あなたの組織をクリックします。
組織の隣の [設定] をクリックします。
左のサイドバーで [アクション] をクリックして、 [全般] をクリックします。

[Policies] で、オプションを選択します。

**[Allow select actions]\(選択したアクションを許可する\)**  を選択した場合、エンタープライズ内のアクションが許可され、追加のオプションで、その他の特定のアクションも許可されます。 詳細については、「[選択したアクションの実行の許可](#allowing-select-actions-to-run)」を参照してください。

[保存] をクリックします。

選択したアクションの実行の許可

[ [Allow select actions](選択したアクションを許可する) ] を選ぶと、ローカルアクションが許可され、他の特定のアクションを許可するための追加のオプションがあります。

注: 組織に優先ポリシーがある場合、または優先ポリシーのあるエンタープライズによって管理されている場合は、これらの設定を管理できない場合があります。詳細については、「Organization について GitHub Actions を無効化または制限する」または「エンタープライズで GitHub Actions のポリシーを適用する」を参照してください。

[GitHub によって作成されたアクションを許可する]: GitHub によって作成されたすべてのアクションを、ワークフローで使用できるようにします。 GitHub によって作成されたアクションは、actions および github 組織にあります。詳しくは、actions および github の Organization をご覧ください。
[検証済みの作成者による Marketplace アクションを許可する]: このオプションは、GitHub Connect が有効になっていて、GitHub Actions で構成されている場合に使用できます。詳細については「GitHub Connect を使用して GitHub.com アクションへの自動アクセスを可能にする」を参照してください。検証済みの作成者が作成したすべての GitHub Marketplace アクションをワークフローで使用できるようにできます。 GitHubがアクションの作者をパートナーOrganizationとして検証すると、GitHub Marketplaceでアクションの隣にバッジが表示されるようになります。
[指定したアクションを許可する]: ワークフローで使用できるアクションを、特定の組織とリポジトリのものに制限します。指定されたアクションを 1000 を超えるアクションに設定することはできません。

アクションの特定のタグまたはコミット SHA へのアクセスを制限するには、ワークフローで使われているのと同じ構文を使って、アクションを選びます。
- アクションの場合の構文は、OWNER/REPOSITORY@TAG-OR-SHA です。たとえば、タグを選択するには actions/javascript-action@v1.0.1 を使用し、SHA を選択するには actions/javascript-action@a824008085750b8e136effc585c3cd6082bd575f を使用します。詳しくは、「アクションの検索とカスタマイズ」を参照してください。
パターンのマッチには、ワイルドカード文字 * を使用できます。たとえば、space-org で始まる Organization のすべてのアクションを許可するには、space-org*/* と指定できます。 octocat で始まるリポジトリのすべてのアクションを許可するには、*/octocat**@* を使用できます。 * ワイルドカードの使用の詳細については、「ギットハブ　アクション　のワークフロー構文」を参照してください。

この手順では、特定のアクションを許可リストに追加する方法を示します。

GitHub の右上隅で、プロフィール写真を選択し、 あなたの組織をクリックします。
組織の隣の [設定] をクリックします。
左のサイドバーで [アクション] をクリックして、 [全般] をクリックします。
[ポリシー] で [ [Allow select actions](選択したアクションを許可する) ] を選び、必要なアクションを一覧に追加します。
[保存] をクリックします。

セルフホステッドランナーの使用を制限する

GitHub Enterprise Server のセルフホステッドランナーが一時的でクリーンな仮想マシンでホストされる保証はありません。その結果、ワークフロー内の信頼できないコードによって侵害される可能性があります。

同様に、リポジトリをフォークしてプルリクエストを開くことができるユーザー (通常は、リポジトリへの読み取りアクセス権を持つユーザー) は、セルフホステッドランナー環境を侵害する可能性があります。それには、シークレットへのアクセスや、リポジトリへの書き込みアクセス権を設定に応じて付与できる GITHUB_TOKEN の取得が含まれます。ワークフローは、環境と必要なレビューを使用して環境シークレットへのアクセスを制御できますが、これらのワークフローは分離された環境では実行されず、セルフホストランナーで実行した場合でも同じリスクの影響を受けやすくなります。

このような理由やその他の理由から、ユーザーがリポジトリレベルでセルフホステッドランナーを作成できないようにすることができます。

注: Organization がエンタープライズに属している場合、リポジトリレベルでのセルフホステッドランナーの作成は、エンタープライズ全体の設定として無効になっている可能性があります。これが行われている場合、Organization 設定でリポジトリレベルのセルフホステッドランナーを有効にすることはできません。詳しくは、「エンタープライズで GitHub Actions のポリシーを適用する」を参照してください。

リポジトリの使用を無効にしたとき、既にセルフホステッドランナーがあった場合、これらは "無効" の状態で一覧表示され、新しいワークフロージョブを割り当てることができません。

"ランナー"の一覧の状態が "無効" のセルフホステッドランナーを示すスクリーンショット。

Note

リポジトリレベルのセルフホステッドランナーが作成できなくなっている場合でも、ワークフローは Enterprise レベルまたは Organization レベルのセルフホステッドランナーにアクセスできます。

GitHub の右上隅で、プロフィール写真を選択し、 あなたの組織をクリックします。
組織の隣の [設定] をクリックします。
左のサイドバーで [アクション] をクリックして、 [全般] をクリックします。
[ランナー] で、ドロップダウンメニューを使って好みの設定を選びます。
- すべてのリポジトリ - セルフホステッドランナーは、Organization 内の任意のリポジトリで使えます。
- 選択したリポジトリ - セルフホステッドランナーは、選んだリポジトリでのみ使えます。
- 無効 - セルフホステッドランナーはリポジトリレベルで作ることはできません。
[選択したリポジトリ] を選んだ場合は、次のようにします。
1. をクリックします。
2. セルフホステッドランナーを許可するリポジトリのチェックボックスをオンにします。
3. [リポジトリの選択] をクリックします。

Organization に必要なワークフローを追加する

注: GitHub は、GitHub Actions に必要なワークフローをサポートしなくなりました。マージ前にパスするようにワークフローに要求するには、お使いの GitHub Enterprise Server インスタンスを最新バージョンにアップグレードし、代わりにリポジトリルールセットを使用します。

お使いの GitHub Enterprise Server インスタンスのアップグレードの詳細については、「AUTOTITLE」を参照してください。

ルールセットの詳細は、「ルールセットで使用できるルール」をご覧ください。

ご自分が所有者である Organization 内のすべてのリポジトリ、または選んだリポジトリで実行するように、必要なワークフローを構成できます。必須のワークフローは pull_request および pull_request_target 既定イベントによってトリガーされます。pull request をマージするには必須のワークフローを通過する必要があります。詳しくは、「必要なワークフロー」を参照してください。

前提条件

必要なワークフローを構成する前に、次の前提条件にご注意ください。

必要なワークフローが実行されるように、Organization の設定で、リポジトリに対して GitHub Actions を有効にする必要があります。 Organization レベルで有効にすると、リポジトリの設定で GitHub Actions が無効になっている場合にも、必要なワークフローが実行されます。組織のリポジトリでの GitHub Actions の管理の詳細については、「Organization について GitHub Actions を無効化または制限する」を参照してください。
必要なワークフローは、必須ステータスチェックが Organization の計画でサポートされているリポジトリ内でのみ、Organization で使うことができます。必須ステータスチェックがサポートされていない場合、ワークフローは引き続き実行されますが、必須のチェックにはならず、マージはブロックされません。必要なステータスチェックのサポートの詳細については、「保護されたブランチについて」を参照してください。
必要なワークフローが必須ステータスチェックとして実行されるように、リポジトリの既定のブランチは、Organization の既定のブランチの設定と一致している必要があります。既定のブランチ名が一致していない場合、ワークフローは引き続き実行されますが、必須チェックにはなりません。既定のブランチ名の管理の詳細については、「Organization のリポジトリのデフォルブランチ名を管理する」と「デフォルトブランチを変更する」を参照してください。
必要なワークフローを実行するには、pull request のソースリポジトリがターゲットリポジトリと同じ Organization に存在している必要があります。 GitHub Enterprise Server は、ワークフローを含むリポジトリの指定されたブランチ、タグ、またはコミット SHA から必要なワークフローをソースにします。
必要なワークフローで使うシークレットは、Organization レベルかターゲットリポジトリ内で作成する必要があります。
ソースリポジトリ内のシークレットは、ワークフローがターゲットリポジトリ内で実行される場合にはフェッチされません。
あるワークフローが必須のワークフローとして実行されるとき、on: セクションのすべてのフィルターが無視されます。たとえば、branches、branches-ignore、paths、types などです。必須のワークフローは、既定のイベントである pull_request と pull_request_target に対してのみ実行されます。既定のアクティビティの種類について詳しくは、「ワークフローをトリガーするイベント」をご覧ください。
必須のワークフローは、求められるチェックとして自動的に表示される場合であっても、既存の pull request で自動的にトリガーされることはありません。既存の pull request に対して必須のワークフローをトリガーするには、その pull request に新しい変更をプッシュします。

ソースリポジトリの制限と動作

ソースリポジトリとワークフローに関する次の制限と動作にご注意ください。

必要なワークフローは、任意のリポジトリフォルダーに格納可能で、通常のワークフローのように .github/workflows フォルダーに限定されることはありません。必要なワークフローが再利用可能なワークフローを呼び出す場合は、その再利用可能なワークフローを .github/workflows フォルダーに格納する必要があります。再利用可能なワークフローを呼び出すときは、再利用可能なワークフローへの完全なパスと参照を、必要なワークフローで使う必要があります。たとえば、{owner}/{repo}/.github/workflows/{filename}@{ref} のようにします。
必要なワークフローがプライベートリポジトリか内部リポジトリに含まれている場合は、リポジトリ内のワークフローが Organization 内の他のリポジトリからアクセスできるようにする必要があります。詳細については、「リポジトリの GitHub Actions の設定を管理する」を参照してください。
パブリックリポジトリに格納されているワークフローは、Organization 内の任意のリポジトリの必要なワークフローとして構成できます。プライベートリポジトリに格納されているワークフローは、Organization 内の他のプライベートリポジトリの必要なワークフローとして構成できます。内部リポジトリに格納されているワークフローは、Organization 内の内部リポジトリとプライベートリポジトリの必要なワークフローとして構成できます。
CodeQL でリポジトリレベルでの構成が必要なため、CodeQL は必要なワークフローでサポートされていません。コードスキャンの構成については、「コードスキャンの高度なセットアップの構成」を参照してください。
必要なワークフローは、ワークフローファイルを含むリポジトリから任意のブランチ、タグ、またはコミット SHA を使用して参照できます。

ターゲットリポジトリの制限と動作

ターゲットリポジトリの次の制限と動作にご注意ください。

必要なワークフローをすべてのリポジトリで、または選択したリポジトリで実行されるように構成する場合、この必要なワークフローを含むリポジトリの可視性は、ワークフローを実行している Organization 内のリポジトリに影響します。パブリックリポジトリに格納されている必要なワークフローは、すべてのリポジトリで実行されます。プライベートリポジトリに格納されている必要なワークフローは、他のプライベートリポジトリで実行されます。内部リポジトリに格納されている必要なワークフローは、内部リポジトリとプライベートリポジトリで実行されます。
必要なワークフローを、このワークフローが作成されたリポジトリで実行されるように構成することはできません。必要なワークフローを格納するには、別のリポジトリの作成を検討する必要があります。
必要なワークフローをすべてのリポジトリで、または選択したリポジトリで実行されるように構成する場合、必要なワークフローは、Organization の設定でアクションが無効になっているリポジトリでは実行されません。

Organization に必要なワークフローの構成

GitHub の右上隅で、プロフィール写真を選択し、 あなたの組織をクリックします。
組織の隣の [設定] をクリックします。
左のサイドバーで [アクション] をクリックして、 [全般] をクリックします。
[必須のワークフロー] の右側にある [ワークフローの追加] を選択します。
[必須のワークフロー] で、ドロップダウンメニューを使用して、ワークフローを含むリポジトリを選択します。次に、テキストフィールドにワークフローへのパスを入力します。 {path}@{ref} 構文を使用して、ワークフローファイルを含むリポジトリから任意のブランチ、タグ、またはコミット SHA を参照できます。
[リポジトリに適用...] で、ドロップダウンメニューを使用して、必須のワークフローが適用されるリポジトリを選択します。 [すべてのリポジトリ] を選んで、組織内のすべてのリポジトリに必須のワークフローを適用するか、または [選択済みのリポジトリ] で適用するリポジトリを選びます。
必要に応じて、[選択済みのリポジトリ] を選んだ場合は、を選択してリポジトリの選択モーダルを開き、チェックボックスを使用してリポジトリを選んでから、 [選択の適用] を選択します。フィルターを使用すると検索を絞り込むことができます。
必要なワークフローを追加するには、 [ワークフローの追加] をクリックします。

プライベートリポジトリのフォークのワークフローを有効にする

プライベートリポジトリのフォークの利用に依存している場合、pull_request イベントの際にユーザーがどのようにワークフローを実行できるかを制御するポリシーを構成できます。プライベートリポジトリと内部リポジトリでのみ使用でき、Enterprise、Organization、またはリポジトリに対してこれらのポリシー設定を構成できます。

Enterpriseでポリシーが無効化されていると、それをOrganizationで有効化することはできません。Organizationでポリシーが無効化されていると、それをリポジトリで有効化することはできません。 Organizationがポリシーを有効化していると、そのポリシーを個々のリポジトリで無効化することはできません。

フォーク pull request からワークフローを実行する - 読み取り専用権限を持ち、シークレットへのアクセス権を持たない GITHUB_TOKEN を使用して、フォーク pull request からワークフローを実行できます。
pull request からワークフローに書き込みトークンを送信する - フォークからの pull request で書き込み権限を持つ GITHUB_TOKEN を使用できます。
pull request からワークフローにシークレットを送信する - すべてのシークレットを pull request で利用できるようにします。
フォークの pull request ワークフローに対して承認を要求する - 書き込みアクセス許可のないコラボレーターからの pull request に対するワークフロー実行には、実行する前に書き込みアクセス許可を持つ誰かからの承認が必要になります。

Organization のプライベートフォークポリシーを設定する

GitHub の右上隅で、プロフィール写真を選択し、 あなたの組織をクリックします。
組織の隣の [設定] をクリックします。
左のサイドバーで [アクション] をクリックして、 [全般] をクリックします。
[Fork pull request workflows](pull request ワークフローのフォーク) で、オプションを選択します。
[保存] をクリックして設定を適用します。

組織の `GITHUB_TOKEN` のアクセス許可の設定

GITHUB_TOKEN に付与される既定のアクセス許可を設定できます。 GITHUB_TOKEN について詳しくは、「自動トークン認証」をご覧ください。デフォルトとして制限付きアクセス許可セットを選択するか、より幅広く許可をする設定を適用できます。

組織またはリポジトリの設定で、GITHUB_TOKEN の既定のアクセス許可を設定できます。 Organization の設定でデフォルトとして制限付きのオプションを選択した場合、そのオプションは Organization 内のリポジトリの設定でも選択され、制限の緩いオプションは無効化されます。 Organization が GitHub Enterprise に属しており、Enterprise 設定でさらに制約の強いデフォルトが選択されている場合、Organization の設定でより制限の緩いデフォルトは選択できません。

リポジトリへの書き込みアクセス権を持っている人は誰でも、ワークフローファイルの permissions キーを編集して、GITHUB_TOKEN に付与されたアクセス許可を変更でき、必要に応じて追加または削除できます。詳細については、permissions をご覧ください。

既定の `GITHUB_TOKEN` のアクセス許可の構成

既定では、新しい Organization を作成すると、設定は Enterprise 設定で構成されているものから継承されます。

GitHub の右上隅で、プロフィール写真をクリックし、[あなたのプロフィール] をクリックします。
GitHub の右上隅で、プロフィール写真を選択し、 あなたの組織をクリックします。
組織の隣の [設定] をクリックします。
左のサイドバーで [アクション] をクリックして、 [全般] をクリックします。
[ワークフローのアクセス許可] で、GITHUB_TOKEN に対してすべてのスコープでの読み取りと書き込みアクセスを許可するか (制限の緩い設定)、contents スコープと packages スコープでの読み取りアクセスのみを許可するか (制限された設定) を選びます。
[保存] をクリックして設定を適用します。

GitHub Actions による pull request の作成または承認を禁止する

GitHub Actions ワークフローが pull request を作成または承認することを許可または禁止するかを選択できます。

既定では、新しい Organization を作成するとき、ワークフローで pull request を作成または承認することは許可されていません。

GitHub の右上隅で、プロフィール写真をクリックし、[あなたのプロフィール] をクリックします。
GitHub の右上隅で、プロフィール写真を選択し、 あなたの組織をクリックします。
組織の隣の [設定] をクリックします。
左のサイドバーで [アクション] をクリックして、 [全般] をクリックします。
[ワークフローのアクセス許可] で、 [GitHub Actions が pull request を作成または承認するのを許可する] 設定を使って、GITHUB_TOKEN が pull request を作成または承認できるかどうかを構成します。
[保存] をクリックして設定を適用します。

Organization の GitHub Actions キャッシュストレージの管理

Organization の管理者はを表示して GitHub Actions Organization 内のすべてのリポジトリのキャッシュストレージを管理できます。

リポジトリごとの GitHub Actions キャッシュストレージの表示

Organization 内の各リポジトリについて、リポジトリが使用しているキャッシュストレージの量、アクティブなキャッシュの数、リポジトリがキャッシュサイズの合計の上限に近いかどうかを確認できます。キャッシュの使用と削除のプロセスについて詳しくは、「依存関係をキャッシュしてワークフローのスピードを上げる」を参照してください。

GitHub の右上隅で、プロフィール写真をクリックし、[あなたのプロフィール] をクリックします。
GitHub の右上隅で、プロフィール写真を選択し、 あなたの組織をクリックします。
組織の隣の [設定] をクリックします。
左のサイドバーで [アクション] をクリックし、 [キャッシュ] をクリックします。
GitHub Actions キャッシュの情報については、リポジトリのリストをご確認ください。リポジトリ名をクリックすると、リポジトリのキャッシュの詳しい情報を表示できます。

Organization の GitHub Actions キャッシュストレージの構成

既定では、GitHub Actions がお使いの GitHub Enterprise Server インスタンス用の外部ストレージで使用するキャッシュストレージの合計は、リポジトリあたり最大 10 GB に制限され、リポジトリに設定できる最大サイズは 25 GB です。

Organization 内の各リポジトリに適用される GitHub Actions キャッシュのサイズ制限を構成できます。 Organization のキャッシュサイズ制限は、Enterprise ポリシーで設定されているキャッシュサイズ制限を超えることはできません。リポジトリ管理者は、それより小さな制限をリポジトリに設定できます。

GitHub の右上隅で、プロフィール写真をクリックし、[あなたのプロフィール] をクリックします。
GitHub の右上隅で、プロフィール写真を選択し、 あなたの組織をクリックします。
組織の隣の [設定] をクリックします。
左のサイドバーで [アクション] をクリックして、 [全般] をクリックします。
[キャッシュサイズの制限] で、新しい値を入力します。
[保存] をクリックして変更を適用します。