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

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

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

Organization 所有者は、リポジトリ レベルのセルフホステッド ランナーの作成を許可するリポジトリを選択できます。

詳細については、「 組織のGitHub Actionsの無効化または制限」を参照してください。

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

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

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

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 証明書を検証します。 ネットワークの問題が発生した場合は、テスト目的で 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

ランナーにどの 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