自己ホストランナーのモニタリングとトラブルシューティング

アクセス レベルのチェック

Organization 所有のリポジトリに対してセルフホステッド ランナーを作成できない場合があります。

エンタープライズ所有者と組織 所有者は、リポジトリ レベルのセルフホステッド ランナーの作成を許可するリポジトリを選択できます。 [組織のランナーおよびランナー グループの管理] 権限を持つユーザーは、組織内のどのリポジトリにリポジトリ レベルのセルフホステッド ランナーの作成を許可するかのみを選択できます。

カスタム組織の役割の詳細については、「 カスタム組織ロールの権限」を参照してください。

詳細については、「 企業でGitHub Actionsのポリシーを適用する と 組織のGitHub Actionsの無効化または制限」を参照してください。

自己ホストランナーのステータスを確認する

セルフホステッド ランナーは、リポジトリまたは Organization のいずれかに配置するか、GitHub Enterprise Server の Enterprise 設定に配置することができます。 セルフホストランナーを管理するには、セルフホストランナーが追加された場所に応じて以下の権限が必要になります。

• ユーザーのリポジトリ: リポジトリ オーナーである必要があります。

• Organization: Organization オーナーである必要があります。

• Organization のリポジトリ: Organization オーナーまたは、そのリポジトリへの管理者アクセスを持っている必要があります。

• Enterprise: GitHub Enterprise サイト管理者である必要があります。

1. Organization またはリポジトリでメイン ページに移動して、 [Settings] をクリックします。

2. 左側のサイドバーで、 [Actions] をクリックしてから [Runners] をクリックします。

3. Runners の下で、ランナーの名前、ラベル、状態など、登録済みランナーの一覧を確認できます。

   状態は、次のいずれかになります。

   • アイドル： ランナーは GitHub に接続されており、ジョブを実行する準備ができています。
   • アクティブ: ランナーでは現在、タスクが稼働中です。
   • オフライン： ランナーが GitHubに接続されていません。 これは、コンピューターがオフラインであるか、セルフホステッド ランナー アプリケーションがコンピューター上で実行されていないか、セルフホステッド ランナー アプリケーションが GitHubと通信できないことが原因である可能性があります。

ネットワーク接続のトラブルシューティング

セルフホステッド ランナー ネットワーク接続の確認

セルフホステッド ランナー アプリケーションの config スクリプトを --check パラメーターと共に使用して、セルフホステッド ランナーが GitHub上のすべての必要なネットワーク サービスにアクセスできることを確認できます。

--check に加え、スクリプトには次の 2 つの引数を指定する必要があります。

• --url GitHub リポジトリ、組織、またはエンタープライズへの URL を指定します。 たとえば、--url https://github.com/octo-org/octo-repo のようにします。
• --pat は、personal access token (classic) スコープを持つ workflow の値、またはワークフローへの読み取りおよび書き込みアクセス権を持つ fine-grained personal access token の値です。 たとえば、--pat ghp_abcd1234 のようにします。 詳しくは、「個人用アクセス トークンを管理する」をご覧ください。

次に例を示します。

./config.sh --check --url URL --pat ghp_abcd1234

./config.sh --check --url URL --pat ghp_abcd1234

config.cmd --check --url https://github.com/YOUR-ORG/YOUR-REPO --pat GHP_ABCD1234

このスクリプトでは各サービスをテストし、それぞれの PASS または FAIL を出力します。 いずれかのチェックに失敗した場合は、そのチェックのログ ファイルで問題の詳細を確認できます。 ログ ファイルはランナー アプリケーションをインストールした _diag ディレクトリに配置され、各チェックのログ ファイルのパスがスクリプトのコンソール出力に表示されます。

いずれかのチェックに失敗した場合は、自己ホスト ランナー マシンがすべての通信要件を満たしていることを確認する必要もあります。 詳しくは、「セルフホステッド ランナー リファレンス」をご覧ください。

TLS 証明書の検証の無効化

既定では、セルフホステッド ランナー アプリケーションは、 GitHubの TLS 証明書を検証します。 お使いの GitHub Enterprise Server インスタンスに自己署名証明書または内部発行証明書がある場合は、テスト目的で TLS 証明書の検証を無効にすることができます。

自己ホスト ランナー アプリケーションで TLS 認定の検証を無効にするには、自己ホスト ランナー アプリケーションを構成して実行する前に、GITHUB_ACTIONS_RUNNER_TLS_NO_VERIFY 環境変数を 1 に設定します。

export GITHUB_ACTIONS_RUNNER_TLS_NO_VERIFY=1
./config.sh --url https://github.com/YOUR-ORG/YOUR-REPO --token
./run.sh

export GITHUB_ACTIONS_RUNNER_TLS_NO_VERIFY=1
./config.sh --url https://github.com/YOUR-ORG/YOUR-REPO --token
./run.sh

[Environment]::SetEnvironmentVariable('GITHUB_ACTIONS_RUNNER_TLS_NO_VERIFY', '1')
./config.cmd --url https://github.com/YOUR-ORG/YOUR-REPO --token
./run.cmd

自己ホストランナーアプリケーションのログファイルのレビュー

自己ホストランナーアプリケーションのステータスと、そのアクティビティをモニタリングできます。 ログ ファイルはランナー アプリケーションをインストールした _diag ディレクトリに保持され、アプリケーションが起動されるたびに新しいログが生成されます。 ファイル名は Runner_ で始まり、その後にアプリケーションが起動された時刻の UTC タイムスタンプが続きます。

ワークフロー ジョブの実行に関する詳細なログについては、Worker_ ファイルについて説明する次のセクションを参照してください。

ジョブのログファイルをレビューする

自己ホストランナーアプリケーションは、処理するジョブごとに詳細なログファイルを生成します。 これらのファイルは、ランナー アプリケーションをインストールした _diag ディレクトリに格納され、ファイル名は Worker_ で始まります。

$ cat ~/actions-runner/.service
actions.runner.octo-org-octo-repo.runner01.service

$ systemctl --type=service | grep actions.runner
actions.runner.octo-org-octo-repo.hostname.service loaded active running GitHub Actions Runner (octo-org-octo-repo.hostname)

sudo journalctl -u actions.runner.octo-org-octo-repo.runner01.service -f

Feb 11 14:57:07 runner01 runsvc.sh[962]: Starting Runner listener with startup type: service
Feb 11 14:57:07 runner01 runsvc.sh[962]: Started listener process
Feb 11 14:57:07 runner01 runsvc.sh[962]: Started running service
Feb 11 14:57:16 runner01 runsvc.sh[962]: √ Connected to GitHub
Feb 11 14:57:17 runner01 runsvc.sh[962]: 2020-02-11 14:57:17Z: Listening for Jobs
Feb 11 16:06:54 runner01 runsvc.sh[962]: 2020-02-11 16:06:54Z: Running job: testAction
Feb 11 16:07:10 runner01 runsvc.sh[962]: 2020-02-11 16:07:10Z: Job testAction completed with result: Succeeded

% cat ~/actions-runner/.service
/Users/exampleUsername/Library/LaunchAgents/actions.runner.octo-org-octo-repo.runner01.plist

$ ./svc.sh status
status actions.runner.example.runner01:
/Users/exampleUsername/Library/LaunchAgents/actions.runner.example.runner01.plist
Started:
379 0 actions.runner.example.runner01

PS C:\actions-runner> Get-Content .service
actions.runner.octo-org-octo-repo.runner01.service

PS C:\actions-runner> Get-Service "actions.runner.octo-org-octo-repo.runner01.service" | Select-Object Name, Status
Name                                                  Status
----                                                  ------
actions.runner.octo-org-octo-repo.runner01.service    Running

PS C:\actions-runner> Get-EventLog -LogName Application -Source ActionsRunnerService

   Index Time          EntryType   Source                 InstanceID Message
   ----- ----          ---------   ------                 ---------- -------
     136 Mar 17 13:45  Information ActionsRunnerService          100 2020-03-17 13:45:48Z: Job Greeting completed with result: Succeeded
     135 Mar 17 13:45  Information ActionsRunnerService          100 2020-03-17 13:45:34Z: Running job: testAction
     134 Mar 17 13:41  Information ActionsRunnerService          100 2020-03-17 13:41:54Z: Listening for Jobs
     133 Mar 17 13:41  Information ActionsRunnerService          100 û Connected to GitHub
     132 Mar 17 13:41  Information ActionsRunnerService            0 Service started successfully.
     131 Mar 17 13:41  Information ActionsRunnerService          100 Starting Actions Runner listener
     130 Mar 17 13:41  Information ActionsRunnerService          100 Starting Actions Runner Service
     129 Mar 17 13:41  Information ActionsRunnerService          100 create event log trace source for actions-runner service

自動アップデートプロセスのモニタリング

セルフホストランナーは、特定のバージョンのしきい値を下回るとジョブを処理できなくなるため、定期的に自動更新プロセスを確認することをお勧めします。 自己ホストランナーアプリケーションは自動的に更新されますが、このプロセスにはオペレーティングシステムやその他のソフトウェアの更新は含まれません。これらの更新を個別に管理する必要があります。

更新アクティビティは Runner_ ログ ファイルで表示できます。 次に例を示します。

[Feb 12 12:37:07 INFO SelfUpdater] An update is available.

さらに、ランナー アプリケーションをインストールした __ ディレクトリにある _diag ログ ファイルで詳細情報を見つけることができます。

$ sudo systemctl is-active docker.service
active

[2020-02-13 16:56:10Z INFO DockerCommandManager] Which: 'docker'
[2020-02-13 16:56:10Z INFO DockerCommandManager] Not found.
[2020-02-13 16:56:10Z ERR  StepsRunner] Caught exception from step: System.IO.FileNotFoundException: File not found: 'docker'

dial unix /var/run/docker.sock: connect: permission denied

$ sudo systemctl show -p User actions.runner.octo-org-octo-repo.runner01.service
User=runner-user

アップグレード後にオフラインになっているランナーの解決 GitHub Enterprise Server

エフェメラル ランナーを使用しており、自動更新を無効にしている場合は、GitHub Enterprise Server をアップグレードする前に、まず、アップグレードしたインスタンスが実行されるランナー アプリケーションのバージョンにセルフホスト ランナーをアップグレードしておく必要があります。 エフェメラル ランナーをアップグレードする前に GitHub Enterprise Server をアップグレードした場合、ランナーがオフラインになる可能性があります。 詳しくは、「アップグレード プロセスの概要」をご覧ください。

次の理由でランナーがオフラインの場合は、ランナーを手動で更新します。 詳細については、アクション/ランナー リポジトリの最新リリースにあるインストール手順を参照してください。

ランナーにどの Docker エンジンがインストールされているかを確認する

次のエラーが発生してビルドが失敗する場合は、次のようにします。

Error: Input required and not supplied: java-version

自己ホスト ランナーにどの Docker エンジンがインストールされているかを確認します。 アクションの入力を Docker コンテナーに渡すには、ダッシュが含まれている可能性がある環境変数をランナーの名前の一部として使います。 Docker エンジンがバイナリ実行可能ファイルではなく、シェル ラッパーまたはリンク (snap を使って Linux にインストールされている Docker エンジンなど) である場合は、このアクションでは入力を取得できない可能性があります。 このエラーに対処するには、別の Docker エンジンを使うように自己ホスト ランナーを構成します。

snap を使って Docker エンジンがインストールされているかどうかを確認するには、which コマンドを使います。 次の例では、snap を使って Docker エンジンがインストールされています。

$ which docker
/snap/bin/docker