ghe-actions-check コマンド ライン ユーティリティを使って、お使いの Enterprise Server インスタンスの Actions の正常性を確認できます。 詳細については、「コマンド ライン ユーティリティ」および「管理シェル (SSH) にアクセスする」を参照してください。
信頼された認証局によって署名された証明書で Enterprise Server上のTLSを設定することを強くおすすめします。 自己署名証明書でも動作はしますが、セルフホストランナーに追加の設定が必要になり、プロダクションの環境では推奨されません。詳しくは、「TLSの設定」をご覧ください。
セルフホストランナーが自己署名証明書を使用して Enterprise Server に接続するには、接続がセキュリティで強化されるように、証明書をランナーマシンにインストールする必要があります。
証明書をインストールするステップについては、ランナーのオペレーティングシステムのドキュメントを参照してください。
ほとんどのアクションは JavaScript で記述されており、オペレーティングシステムの証明書ストアを使用しない Node.js を使用して実行されます。 セルフホスト ランナー アプリケーションで証明書を使用するには、ランナーのコンピューターで NODE_EXTRA_CA_CERTS 環境変数を設定する必要があります。
この環境変数は、システム環境変数として設定することも、自己ホスト型ランナー アプリケーション ディレクトリ（つまり、ランナー ソフトウェアをダウンロードして解凍したディレクトリ）にある .env というファイルで宣言することもできます。
次に例を示します。
NODE_EXTRA_CA_CERTS=/usr/share/ca-certificates/extra/mycertfile.crt
環境変数は、セルフホストランナーアプリケーションの起動時に読み込まれるため、セルフホストランナーアプリケーションを設定または起動する前に、環境変数を設定する必要があります。 証明書の設定が変更された場合は、セルフホストランナーアプリケーションを再起動する必要があります。
ワークフローで Docker コンテナアクションまたはサービスコンテナを使用する場合は、上記の環境変数の設定に加えて、Docker イメージに証明書をインストールする必要がある場合もあります。
に HTTP プロキシ サーバーが構成されている場合
- HTTP プロキシ除外リストに
.localhost、127.0.0.1、::1を追加 (この順序で) する必要があります。 - ご利用の外部ストレージの場所がルーティング不可能である場合は、該当する外部ストレージ URL も、除外リストに追加する必要があります。
プロキシ設定の変更の詳細については、「アウトバウンドの Web プロキシ サーバーの設定」を参照してください。
これらの設定が正しく構成されていない場合は、 Actions 構成の設定や変更時に Resource unexpectedly moved to https://IP-ADDRESS のようなエラーが発生する可能性があります。
警告
初期セットアップ後に Enterprise Server のホスト名を変更しないでください。 ホスト名を変更すると、インスタンスの停止やユーザーのセキュリティ キーの無効化など、予期しない動作が生じます。 インスタンスのホスト名を変更して問題が発生した場合は、 Enterprise サポート または Premium Support に問い合わせてください。
新しいホスト名を使用して環境内に Enterprise Server を展開し、古いホスト名がインスタンスに解決されなくなった場合、セルフホスト ランナーは古いホスト名に接続できず、ジョブは実行されません。
お使いの Enterprise Server インスタンスに新しいホスト名を使うには、セルフホステッド ランナーの構成を更新する必要があります。 各セルフホストランナーには、次のいずれかの手順を行う必要があります。
- セルフホスト ランナー アプリケーション ディレクトリで、
.runnerと.credentialsのファイルを編集して、古いホスト名のすべてのメンションを新しいホスト名に置き換えてから、セルフホスト ランナー アプリケーションを再起動します。 - UIを使用して Enterprise Server からランナーを削除し、再度追加します。 詳細については、「セルフホストランナーの削除」および「自己ホストランナーの追加」を参照してください。
お使いの Enterprise Server インスタンスに対して Dependabot の更新プログラムを設定した後、Dependabot イベントによって既存のワークフローがトリガーされるとエラーが発生することがあります。
既定では、push、pull_request、pull_request_review、または pull_request_review_comment のイベントから Dependabot によってトリガーされる Actions ワークフローの実行は、リポジトリ フォークから開かれたかのように扱われます。 他のアクターによってトリガーされるワークフローとは異なり、これは読み取り専用の _TOKEN を受け取り、通常使用できるシークレットにはアクセスできないことを意味します。 これにより、Dependabot によってトリガーされたときに、リポジトリへの書き込みを試みるワークフローが失敗します。
この問題を解決するには、次の 3 つの方法があります。
if: .actor != 'dependabot[bot]'のような式を使用して、Dependabot によってトリガーされないようにワークフローを更新できます。 詳しくは、「ワークフローとアクションで式を評価する」をご覧ください。- ワークフローを変更して、このような制限がない
pull_request_targetを含む 2 段階のプロセスを使用できます。 詳しくは、「 Actions での Dependabot のトラブルシューティング」をご覧ください。 - Dependabot のアクセスによってトリガーされるワークフローをシークレットに提供し、
permissionsという用語で_TOKENの既定のスコープを広げることができます。詳しくは、以下の「シークレットへの Dependabot のアクセスとアクセス許可の増加によってトリガーされるワークフローの提供」をご覧ください。
SSH を使用して管理シェルにログインします。 詳しくは、「管理シェル (SSH) にアクセスする」をご覧ください。
お使いの Enterprise Server インスタンスの Dependabot によってトリガーされるワークフローの制限を削除するには、次のコマンドを使います。
ghe-config app.actions.disable-dependabot-enforcement true構成を適用します。
ghe-config-applyEnterprise Serverに戻ります。
Enterprise Server に Actions をインストールするときに次のエラーが発生した場合は、公式のバンドルされたアクションとワークフロー テンプレートをインストールすることで問題を解決できます。
A part of the Actions setup had problems and needs an administrator to resolve.
Enterprise Server 内の指定された Organization 内に公式のバンドルされたアクションとワークフロー テンプレートをインストールするには、次の手順に従います。
公式のバンドルされたアクションとワークフロー テンプレートを格納する Organization を特定します。 新しい Organization を作成することも、既存のものを再利用することもできます。
- 新しい organization の作成については、「新しい Organization をゼロから作成」をご覧ください。
- この organization の名前の選択に関するサポートについては、「 Enterprise Server の Actions を使い始める」をご覧ください。
SSH を使用して管理シェルにログインします。 詳しくは、「管理シェル (SSH) にアクセスする」をご覧ください。
バンドルされたアクションを格納する場所として Organization を指定するには、
ghe-configコマンドを使用して、ORGANIZATIONを Organization の名前に置き換えます。ghe-config app.actions.actions-org ORGANIZATIONおよび
ghe-config app.actions.-org ORGANIZATIONバンドルされたアクションを Organization に追加するには、SHA を設定解除します。
ghe-config --unset 'app.actions.actions-repos-sha1sum'構成を適用します。
ghe-config-apply
これらの手順を終えたら、「 Enterprise Server の Actions を使い始める」で Actions の構成を再開できます。