このバージョンの GitHub Enterprise サーバーはこの日付をもって終了となります: 2024-06-29. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの向上、新機能の向上を図るために、最新バージョンの GitHub Enterprise サーバーにアップグレードしてください。 アップグレードに関するヘルプについては、GitHub Enterprise サポートにお問い合わせください。

Enterprise 向け GitHub Actions のトラブルシューティング

GitHub Enterprise Server で GitHub Actions を使用するときに発生する一般的な問題のトラブルシューティング。

この機能を使用できるユーザーについて

Site administrators can troubleshoot GitHub Actions issues and modify GitHub Enterprise Server configurations.

この記事の内容

GitHub Actions の正常性の確認

ghe-actions-check コマンド ライン ユーティリティを使って、お使いの GitHub Enterprise Server インスタンスの GitHub Actions の正常性を確認できます。 詳細については、「コマンド ライン ユーティリティ」および「管理シェル (SSH) にアクセスする」を参照してください。

GitHub Enterprise Server に自己署名証明書を使用する場合のセルフホストランナーの設定

信頼された認証局によって署名された証明書でGitHub Enterprise Server上のTLSを設定することを強くおすすめします。 自己署名証明書でも動作はしますが、セルフホストランナーに追加の設定が必要になり、プロダクションの環境では推奨されません。 詳細については、「TLSの設定」を参照してください。

ランナーマシンに証明書をインストールする

セルフホストランナーが自己署名証明書を使用して GitHub Enterprise Server に接続するには、接続がセキュリティで強化されるように、証明書をランナーマシンにインストールする必要があります。

証明書をインストールするステップについては、ランナーのオペレーティングシステムのドキュメントを参照してください。

証明書を使用するように Node.JS を設定する

ほとんどのアクションは JavaScript で記述されており、オペレーティングシステムの証明書ストアを使用しない Node.js を使用して実行されます。 セルフホスト ランナー アプリケーションで証明書を使用するには、ランナーのコンピューターで NODE_EXTRA_CA_CERTS 環境変数を設定する必要があります。

この環境変数は、システム環境変数として設定することも、自己ホスト型ランナー アプリケーション ディレクトリ（つまり、ランナー ソフトウェアをダウンロードして解凍したディレクトリ）にある .env というファイルで宣言することもできます。

次に例を示します。

NODE_EXTRA_CA_CERTS=/usr/share/ca-certificates/extra/mycertfile.crt

環境変数は、セルフホストランナーアプリケーションの起動時に読み込まれるため、セルフホストランナーアプリケーションを設定または起動する前に、環境変数を設定する必要があります。 証明書の設定が変更された場合は、セルフホストランナーアプリケーションを再起動する必要があります。

証明書を使用するように Docker コンテナを設定する

ワークフローで Docker コンテナアクションまたはサービスコンテナを使用する場合は、上記の環境変数の設定に加えて、Docker イメージに証明書をインストールする必要がある場合もあります。

GitHub Actions の HTTP プロキシ設定

お使いの GitHub Enterprise Server インスタンス に HTTP プロキシ サーバーが構成されている場合:

  • HTTP プロキシ除外リストに.localhost、127.0.0.1、::1 を追加 (この順序で) する必要があります。
  • ご利用の外部ストレージの場所がルーティング不可能である場合は、該当する外部ストレージ URL も、除外リストに追加する必要があります。

プロキシ設定の変更については、「アウトバウンドの Web プロキシ サーバーの設定」を参照してください。

これらの設定が正しく構成されていない場合は、GitHub Actions 構成の設定や変更時に Resource unexpectedly moved to https://IP-ADDRESS のようなエラーが発生する可能性があります。

ランナーが新しいホスト名を使用して GitHub Enterprise Server に接続しない

警告: 初期セットアップ後に GitHub Enterprise Server のホスト名を変更しないでください。 ホスト名を変更すると、インスタンスの停止やユーザーのセキュリティ キーの無効化など、予期しない動作が生じます。 インスタンスのホスト名を変更して問題が発生した場合は、GitHub Enterprise サポート または GitHub Premium Support に問い合わせてください。

新しいホスト名を使用して環境内に GitHub Enterprise Server を展開し、古いホスト名がインスタンスに解決されなくなった場合、セルフホスト ランナーは古いホスト名に接続できず、ジョブは実行されません。

お使いの GitHub Enterprise Server インスタンスに新しいホスト名を使うには、セルフホステッド ランナーの構成を更新する必要があります。 各セルフホストランナーには、次のいずれかの手順を行う必要があります。

  • セルフホスト ランナー アプリケーション ディレクトリで、.runner と .credentials のファイルを編集して、古いホスト名のすべてのメンションを新しいホスト名に置き換えてから、セルフホスト ランナー アプリケーションを再起動します。
  • UIを使用して GitHub Enterprise Server からランナーを削除し、再度追加します。 詳細については、「セルフホストランナーの削除」および「自己ホストランナーの追加」を参照してください。

スタックジョブと GitHub Actions メモリと CPU の制限

GitHub Actions は、お使いの GitHub Enterprise Server インスタンスで実行されている複数のサービスで構成されます。 デフォルトでは、これらのサービスは、ほとんどのインスタンスで機能するデフォルトの CPU およびメモリ制限で設定されています。 ただし、GitHub Actions のヘビーユーザは、これらの設定を調整する必要がある場合があります。

ジョブが開始されていないことに気付いた場合（アイドル状態のランナーが存在する場合でも）、または UI でジョブの進行状況が更新または変更されていない場合は、CPU またはメモリの上限に達している可能性があります。

1. 管理コンソールで全体的な CPU とメモリの使用率を確認する

Management Console にアクセスし、モニターダッシュボードを使用して、[System Health] の下の全体的な CPU とメモリのグラフを調べます。 詳しくは、「モニターダッシュボードへのアクセス」を参照してください。

[システム正常性] 全体の CPU 使用率が 100% に近い場合、または空きメモリが残っていない場合は、お使いの GitHub Enterprise Server インスタンスが容量いっぱいで実行されているため、スケールアップする必要があります。 詳しくは、「CPUあるいはメモリリソースの増加」を参照してください。

2. 管理コンソールで Nomad Jobs の CPU とメモリの使用率を確認する

全体的な [System Health] の CPU とメモリの使用率に問題がない場合は、モニターダッシュボードページを下にスクロールして [Nomad Jobs] セクションに移動し、[CPU Percent Value] と [Memory Usage] のグラフを確認します。

これらのグラフの各プロットは、1 つのサービスに対応しています。 GitHub Actions サービスについては、以下を探してください。

  • mps_frontend
  • mps_backend
  • token_frontend
  • token_backend
  • actions_frontend
  • actions_backend

これらのサービスのいずれかが 100％ またはそれに近い CPU 使用率であるか、メモリが上限（デフォルトでは 2 GB）に近い場合、これらのサービスのリソース割り当てを増やす必要がある場合があります。 上記のサービスのどれが上限に達しているか、上限に近いかを注視してください。

3. 上限に達したサービスへのリソース割り当てを増やす

  1. SSH を使用して管理シェルにログインします。 詳しくは、「管理シェル (SSH) にアクセスする」を参照してください。

  2. 次のコマンドを実行して、割り当てに利用可能なリソースを確認します。

    nomad node status -self

    出力で [Allocated Resources] セクションを見つけます。 これは次の例のようなものです。

    Allocated Resources
CPU              Memory          Disk
7740/49600 MHZ   23 GiB/32 GiB   4.4 GiB/7.9 GiB

    CPU とメモリの場合、すべてのサービスの合計に割り当てられている量 (左側の値) と使用可能な量 (右側の値) が表示されます。 上記の例では、合計 32GiB のうち 23GiB のメモリが割り当てられています。 これは、9GiB のメモリを割り当てることができるということを示しています。

    警告: 利用可能なリソースの合計を超える容量を割り当てると、サービスが開始されませんので注意してください。

  3. ディレクトリを /etc/consul-templates/etc/nomad-jobs/actions に変更します。

    cd /etc/consul-templates/etc/nomad-jobs/actions

    このディレクトリには、上記の GitHub Actions サービスに対応する 3 つのファイルがあります。

    • mps.hcl.ctmpl
    • token.hcl.ctmpl
    • actions.hcl.ctmpl

  4. 調整が必要なサービスを特定した場合は、対応するファイルを開き、次のような resources グループを見つけます。

    resources {
  cpu = 512
  memory = 2048
  network {
    port "http" { }
  }
}

    値は、CPU リソースの場合は MHz、メモリリソースの場合は MB です。

    たとえば、上記の例のリソース制限を CPU と 4 GBのメモリの 1GHz に増やすには、次のように変更します。

    resources {
  cpu = 1024
  memory = 4096
  network {
    port "http" { }
  }
}

  5. ファイルを保存して終了します。

  6. ghe-config-apply を実行して、変更を適用します。

    ghe-config-apply の実行中に Failed to run nomad job '/etc/nomad-jobs/<name>.hcl' のような出力が表示される場合は、変更によって CPU またはメモリのリソースが過剰に割り当てられている可能性があります。 この場合は、構成ファイルをもう一度編集し、割り当てられた CPU またはメモリを減らしてから、ghe-config-apply を再実行します。

  7. 構成が適用されたら、ghe-actions-check を実行して、GitHub Actions サービスが動作していることを確認します。

Dependabot が既存のワークフローをトリガーするときのエラーのトラブルシューティング

お使いの GitHub Enterprise Server インスタンスに対して Dependabot の更新プログラムを設定した後、Dependabot イベントによって既存のワークフローがトリガーされるとエラーが発生することがあります。

既定では、push、pull_request、pull_request_review、または pull_request_review_comment のイベントから Dependabot によってトリガーされる GitHub Actions ワークフローの実行は、リポジトリ フォークから開かれたかのように扱われます。 他のアクターによってトリガーされるワークフローとは異なり、これは読み取り専用の GITHUB_TOKEN を受け取り、通常使用できるシークレットにはアクセスできないことを意味します。 これにより、Dependabot によってトリガーされたときに、リポジトリへの書き込みを試みるワークフローが失敗します。

この問題を解決するには、次の 3 つの方法があります。

  1. if: github.actor != 'dependabot[bot]' のような式を使用して、Dependabot によってトリガーされないようにワークフローを更新できます。 詳しくは、「式」を参照してください。
  2. ワークフローを変更して、このような制限がない pull_request_target を含む 2 段階のプロセスを使用できます。 詳しくは、「GitHub ActionsでのDependabotの自動化」を参照してください。
  3. Dependabot のアクセスによってトリガーされるワークフローをシークレットに提供し、permissions という用語で GITHUB_TOKEN の既定のスコープを広げることができます。 詳細については、以下の「シークレットへの Dependabot のアクセスとアクセス許可の増加によってトリガーされるワークフローの提供」を参照してください。

シークレットへの Dependabot のアクセスとアクセス許可の増加によってトリガーされるワークフローの提供

  1. SSH を使用して管理シェルにログインします。 詳しくは、「管理シェル (SSH) にアクセスする」を参照してください。

  2. お使いの GitHub Enterprise Server インスタンスの Dependabot によってトリガーされるワークフローの制限を削除するには、次のコマンドを使います。

    ghe-config app.actions.disable-dependabot-enforcement true

  3. 構成を適用します。

    ghe-config-apply

  4. GitHub Enterprise Serverに戻ります。

GitHub Actions のバンドルされたアクションのトラブルシューティング

GitHub Enterprise Server に GitHub Actions をインストールするときに次のエラーが発生した場合は、公式のバンドルされたアクションとスターター ワークフローをインストールすることで問題を解決できます。

A part of the Actions setup had problems and needs an administrator to resolve.

GitHub Enterprise Server 内の指定された Organization 内に公式のバンドルされたアクションとスターター ワークフローをインストールするには、次の手順に従います。

  1. 公式のバンドルされたアクションとスターター ワークフローを格納する Organization を特定します。 新しい Organization を作成することも、既存のものを再利用することもできます。

  2. SSH を使用して管理シェルにログインします。 詳しくは、「管理シェル (SSH) にアクセスする」を参照してください。

  3. バンドルされたアクションを格納する場所として Organization を指定するには、ghe-config コマンドを使用して、ORGANIZATION を Organization の名前に置き換えます。

    ghe-config app.actions.actions-org ORGANIZATION

    および

    ghe-config app.actions.github-org ORGANIZATION

  4. バンドルされたアクションを Organization に追加するには、SHA を設定解除します。

    ghe-config --unset 'app.actions.actions-repos-sha1sum'

  5. 構成を適用します。

    ghe-config-apply

これらの手順を完了したら、「GitHub Enterprise Server の GitHub Actions を使い始める」で GitHub Actions の構成を再開できます。