Skip to main content

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

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

Who can use this feature

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

GitHub Actions の正常性の確認

ghe-actions-check コマンド ライン ユーティリティを使用して、your GitHub Enterprise Server instanceの 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 プロキシ設定

your GitHub Enterprise Server instance に HTTP プロキシ サーバー が構成されている場合:

  • localhost127.0.0.1HTTP プロキシ除外 リストに追加する必要があります。

  • BYOS バケットがルーティングできない場合は、バケットの URL も除外リストに追加する必要があります。

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

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

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

警告: 初期セットアップ後に GitHub Enterprise Server のホスト名を変更しないでください。 ホスト名を変更すると、インスタンスの停止に及ぶ予想外の動作が生じます。

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

your GitHub Enterprise Server instance に新しいホスト名を使用するには、セルフホストランナーの設定を更新する必要があります。 各セルフホストランナーには、次のいずれかの手順を行う必要があります。

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

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

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

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

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

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

[System Health] 全体の CPU 使用率が 100% に近い場合、または空きメモリが残っていない場合は、your GitHub Enterprise Server instance が容量で実行されているため、スケールアップする必要があります。 詳細については、「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 が既存のワークフローをトリガーするときのエラーのトラブルシューティング

Note: Dependabot security and version updates are currently in public beta and subject to change.

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

既定では、pushpull_requestpull_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. your GitHub Enterprise Server instanceの 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 Actions のアクセス許可の管理」で GitHub Actions の構成を再開できます。