Skip to main content

このバージョンの GitHub Enterprise サーバーはこの日付をもって終了となります: 2024-06-29. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの向上、新機能の向上を図るために、最新バージョンの GitHub Enterprise サーバーにアップグレードしてください。 アップグレードに関するヘルプについては、GitHub Enterprise サポートにお問い合わせください

Troubleshooting GitHub Actions for your enterprise

Troubleshooting common issues that occur when using GitHub Actions on GitHub Enterprise Server.

この機能を使用できるユーザーについて

Site administrators can troubleshoot GitHub Actions issues and modify GitHub Enterprise Server configurations.

Checking the health of GitHub Actions

You can check the health of GitHub Actions on お使いの GitHub Enterprise Server インスタンス with the ghe-actions-check command-line utility. For more information, see "コマンド ライン ユーティリティ" and "管理シェル (SSH) にアクセスする."

Configuring self-hosted runners when using a self-signed certificate for GitHub Enterprise Server

信頼された認証局によって署名された証明書でGitHub Enterprise Server上のTLSを設定することを強くおすすめします。 自己署名証明書でも動作はしますが、セルフホストランナーに追加の設定が必要になり、プロダクションの環境では推奨されません。 For more information, see "Configuring TLS."

Installing the certificate on the runner machine

For a self-hosted runner to connect to a GitHub Enterprise Server using a self-signed certificate, you must install the certificate on the runner machine so that the connection is security hardened.

For the steps required to install a certificate, refer to the documentation for your runner's operating system.

Configuring Node.JS to use the certificate

Most actions are written in JavaScript and run using Node.js, which does not use the operating system certificate store. For the self-hosted runner application to use the certificate, you must set the NODE_EXTRA_CA_CERTS environment variable on the runner machine.

You can set the environment variable as a system environment variable, or declare it in a file called .env in the self-hosted runner application directory (that is, the directory into which you downloaded and unpacked the runner software).

For example:

NODE_EXTRA_CA_CERTS=/usr/share/ca-certificates/extra/mycertfile.crt

Environment variables are read when the self-hosted runner application starts, so you must set the environment variable before configuring or starting the self-hosted runner application. If your certificate configuration changes, you must restart the self-hosted runner application.

Configuring Docker containers to use the certificate

If you use Docker container actions or service containers in your workflows, you might also need to install the certificate in your Docker image in addition to setting the above environment variable.

Configuring HTTP proxy settings for GitHub Actions

お使いの GitHub Enterprise Server インスタンス に HTTP プロキシ サーバーが構成されている場合:

  • HTTP プロキシ除外リストに.localhost127.0.0.1::1 を追加 (この順序で) する必要があります。
  • ご利用の外部ストレージの場所がルーティング不可能である場合は、該当する外部ストレージ URL も、除外リストに追加する必要があります。

プロキシ設定の変更については、「Configuring an outbound web proxy server」を参照してください。

If these settings aren't correctly configured, you might receive errors like Resource unexpectedly moved to https://IP-ADDRESS when setting or changing your GitHub Actions configuration.

Runners not connecting to GitHub Enterprise Server with a new hostname

警告: 初期セットアップ後に GitHub Enterprise Server のホスト名を変更しないでください。 ホスト名を変更すると、インスタンスの停止やユーザーのセキュリティ キーの無効化など、予期しない動作が生じます。 インスタンスのホスト名を変更して問題が発生した場合は、GitHub Enterprise サポート または GitHub Premium Support に問い合わせてください。

If you deploy GitHub Enterprise Server in your environment with a new hostname and the old hostname no longer resolves to your instance, self-hosted runners will be unable to connect to the old hostname, and will not execute any jobs.

You will need to update the configuration of your self-hosted runners to use the new hostname for お使いの GitHub Enterprise Server インスタンス. Each self-hosted runner will require one of the following procedures:

  • In the self-hosted runner application directory, edit the .runner and .credentials files to replace all mentions of the old hostname with the new hostname, then restart the self-hosted runner application.
  • Remove the runner from GitHub Enterprise Server using the UI, and re-add it. For more information, see "セルフホストランナーの削除" and "自己ホストランナーの追加."

Stuck jobs and GitHub Actions memory and CPU limits

GitHub Actions is composed of multiple services running on お使いの GitHub Enterprise Server インスタンス. By default, these services are set up with default CPU and memory limits that should work for most instances. However, heavy users of GitHub Actions might need to adjust these settings.

You may be hitting the CPU or memory limits if you notice that jobs are not starting (even though there are idle runners), or if the job's progress is not updating or changing in the UI.

1. Check the overall CPU and memory usage in the management console

Access the management console and use the monitor dashboard to inspect the overall CPU and memory graphs under "System Health". For more information, see "モニターダッシュボードへのアクセス."

If the overall "System Health" CPU usage is close to 100%, or there is no free memory left, then お使いの GitHub Enterprise Server インスタンス is running at capacity and needs to be scaled up. For more information, see "CPUあるいはメモリリソースの増加."

2. Check the Nomad Jobs CPU and memory usage in the management console

If the overall "System Health" CPU and memory usage is OK, scroll down the monitor dashboard page to the "Nomad Jobs" section, and look at the "CPU Percent Value" and "Memory Usage" graphs.

Each plot in these graphs corresponds to one service. For GitHub Actions services, look for:

  • mps_frontend
  • mps_backend
  • token_frontend
  • token_backend
  • actions_frontend
  • actions_backend

If any of these services are at or near 100% CPU utilization, or the memory is near their limit (2 GB by default), then the resource allocation for these services might need increasing. Take note of which of the above services are at or near their limit.

3. Increase the resource allocation for services at their limit

  1. Log in to the administrative shell using SSH. For more information, see "管理シェル (SSH) にアクセスする."

  2. Run the following command to see what resources are available for allocation:

    nomad node status -self
    

    In the output, find the "Allocated Resources" section. It looks similar to the following example:

    Allocated Resources
    CPU              Memory          Disk
    7740/49600 MHZ   23 GiB/32 GiB   4.4 GiB/7.9 GiB
    

    For CPU and memory, this shows how much is allocated to the total of all services (the left value) and how much is available (the right value). In the example above, there is 23 GiB of memory allocated out of 32 GiB total. This means there is 9 GiB of memory available for allocation.

    Warning: Be careful not to allocate more than the total available resources, or services will fail to start.

  3. Change directory to /etc/consul-templates/etc/nomad-jobs/actions:

    cd /etc/consul-templates/etc/nomad-jobs/actions
    

    In this directory there are three files that correspond to the GitHub Actions services from above:

    • mps.hcl.ctmpl
    • token.hcl.ctmpl
    • actions.hcl.ctmpl
  4. For the services that you identified that need adjustment, open the corresponding file and locate the resources group that looks like the following:

    resources {
      cpu = 512
      memory = 2048
      network {
        port "http" { }
      }
    }
    

    The values are in MHz for CPU resources, and MB for memory resources.

    For example, to increase the resource limits in the above example to 1 GHz for the CPU and 4 GB of memory, change it to:

    resources {
      cpu = 1024
      memory = 4096
      network {
        port "http" { }
      }
    }
    
  5. Save and exit the file.

  6. Run ghe-config-apply to apply the changes.

    When running ghe-config-apply, if you see output like Failed to run nomad job '/etc/nomad-jobs/<name>.hcl', then the change has likely over-allocated CPU or memory resources. If this happens, edit the configuration files again and lower the allocated CPU or memory, then re-run ghe-config-apply.

  7. After the configuration is applied, run ghe-actions-check to verify that the GitHub Actions services are operational.

Troubleshooting failures when Dependabot triggers existing workflows

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

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

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

  1. if: github.actor != 'dependabot[bot]' のような式を使用して、Dependabot によってトリガーされないようにワークフローを更新できます。 詳しくは、「」を参照してください。
  2. ワークフローを変更して、このような制限がない pull_request_target を含む 2 段階のプロセスを使用できます。 詳しくは、「GitHub ActionsでのDependabotの自動化」を参照してください。
  3. Dependabot のアクセスによってトリガーされるワークフローをシークレットに提供し、permissions という用語で GITHUB_TOKEN の既定のスコープを広げることができます。 For more information, see "Providing workflows triggered by Dependabot access to secrets and increased permissions" below.

Providing workflows triggered by Dependabot access to secrets and increased permissions

  1. Log in to the administrative shell using SSH. For more information, see "管理シェル (SSH) にアクセスする."

  2. To remove the limitations on workflows triggered by Dependabot on お使いの GitHub Enterprise Server インスタンス, use the following command.

    ghe-config app.actions.disable-dependabot-enforcement true
    
  3. Apply the configuration.

    ghe-config-apply
    
  4. Return to GitHub Enterprise Server.

Troubleshooting bundled actions in GitHub Actions

If you receive the following error when installing GitHub Actions in GitHub Enterprise Server, you can resolve the problem by installing the official bundled actions and starter workflows.

A part of the Actions setup had problems and needs an administrator to resolve.

To install the official bundled actions and starter workflows within a designated organization in GitHub Enterprise Server, follow this procedure.

  1. Identify an organization that will store the official bundled actions and starter workflows. You can create a new organization or reuse an existing one.

  2. Log in to the administrative shell using SSH. For more information, see "管理シェル (SSH) にアクセスする."

  3. To designate your organization as the location to store the bundled actions, use the ghe-config command, replacing ORGANIZATION with the name of your organization.

    ghe-config app.actions.actions-org ORGANIZATION
    

    and:

    ghe-config app.actions.github-org ORGANIZATION
    
  4. To add the bundled actions to your organization, unset the SHA.

    ghe-config --unset 'app.actions.actions-repos-sha1sum'
    
  5. Apply the configuration.

    ghe-config-apply
    

After you've completed these steps, you can resume configuring GitHub Actions at "Getting started with GitHub Actions for GitHub Enterprise Server."