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

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 プロキシサーバー が構成されている� �合:

localhost と 127.0.0.1 を HTTP プロキシ除外 リストに追� する必要があります。
ご利用の外部ストレージの� �所がルーティング不可能である� �合は、該当する外部ストレージ 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 とメモリのグラフを調べます。詳細については、「モニターダッシュボードへのアクセス」を参照してく� さい。

[システ� 正常性] 全体の 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. 上限に達したサービスへのリソース割り当てを増やす

SSH を使用して管理シェルにログインします。詳細については、「管理シェル (SSH) にアクセスする」を参照してく� さい。
次のコマンドを実行して、割り当てに利用可能なリソースを確認します。
```
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 のメモリを割り当てることができるということを示しています。

警告: 利用可能なリソースの合計を超える容量を割り当てると、サービスが開始されませんので注意してく� さい。
ディレクトリを /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
調整が必要なサービスを特定した� �合は、対応するファイルを開き、次のような resources グループを見つけます。
```
resources {
  cpu = 512
  memory = 2048
  network {
    port "http" { }
  }
}
```
値は、CPU リソースの� �合は MHz、メモリリソースの� �合は MB です。

たとえば、上記の例のリソース制限を CPU と 4 GBのメモリの 1GHz に増やすには、次のように変更します。
```
resources {
  cpu = 1024
  memory = 4096
  network {
    port "http" { }
  }
}
```
ファイルを保存して終了します。
ghe-config-apply を実行して、変更を適用します。

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

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

**注:** Dependabot セキュリティとバージョンの更新プログラ� は現在プライベートベータ版であり、変更される可能性があります。 Dependabot アップデートを有効にする手� �については、[アカウント管理チー� にお問い合せく� さい](https://enterprise.github.com/contact)。

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

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

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

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

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

SSH を使用して管理シェルにログインします。詳細については、「管理シェル (SSH) にアクセスする」を参照してく� さい。
your GitHub Enterprise Server instanceの Dependabot によってトリガーされるワークフローの制限を削除するには、次のコマンドを使います。
```
$ ghe-config app.actions.disable-dependabot-enforcement true
```
構成を適用します。
```
$ ghe-config-apply
```
GitHub Enterprise Serverに戻ります。