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 に 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. 上限に達したサービスへのリソース割り当てを増やす
-
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 が既存のワークフローをトリガーするときのエラーのトラブルシューティング
お使いの GitHub Enterprise Server インスタンスに対して 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) にアクセスする」を参照してください。
-
お使いの GitHub Enterprise Server インスタンスの Dependabot によってトリガーされるワークフローの制限を削除するには、次のコマンドを使います。
ghe-config app.actions.disable-dependabot-enforcement true
-
構成を適用します。
ghe-config-apply
-
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 内に公式のバンドルされたアクションとワークフロー テンプレートをインストールするには、次の手順に従います。
-
公式のバンドルされたアクションとワークフロー テンプレートを格納する Organization を特定します。 新しい Organization を作成することも、既存のものを再利用することもできます。
- 新しい組織を作成するには、「新しい Organization をゼロから作成」を参照してください。
- この組織の名前を選択するためのサポートについては、「GitHub Enterprise Server の GitHub Actions を使い始める」を参照してください。
-
SSH を使用して管理シェルにログインします。 詳しくは、「管理シェル (SSH) にアクセスする」を参照してください。
-
バンドルされたアクションを格納する場所として Organization を指定するには、
ghe-config
コマンドを使用して、ORGANIZATION
を Organization の名前に置き換えます。ghe-config app.actions.actions-org ORGANIZATION
および
ghe-config app.actions.github-org ORGANIZATION
-
バンドルされたアクションを Organization に追加するには、SHA を設定解除します。
ghe-config --unset 'app.actions.actions-repos-sha1sum'
-
構成を適用します。
ghe-config-apply
これらの手順を完了したら、「GitHub Enterprise Server の GitHub Actions を使い始める」で GitHub Actions の構成を再開できます。