使用仓库级别的自托管运行器
您可能无法为组织拥有的仓库创建自托管运行器。
组织所有者可以选择允许哪些仓库创建仓库级别的自托管运行器。
更多信息，请参阅“为您的组织禁用或限制 GitHub Actions”。
检查自托管运行器的状态
自托管运行器可以位于 GitHub 上的仓库、组织或企业帐户设置中。要管理自托管运行器，您必须具有以下权限，具体取决于自托管运行器的添加位置
- 用户仓库：您必须是仓库所有者。
- 组织：您必须是组织所有者。
- 组织仓库：您必须是组织所有者，或拥有该仓库的管理员权限。
-
在您的组织或仓库中，导航到主页并点击 设置.
-
在左侧边栏中，点击 Actions，然后点击Runners。
-
在“Runners”下，您可以查看已注册 runner 的列表，包括 runner 的名称、标签和状态。
状态可以是以下之一：
- 空闲：runner 已连接到 GitHub 并已准备好执行作业。
- 活动：runner 当前正在执行作业。
- 离线：runner 未连接到 GitHub。这可能是因为机器离线、自托管 runner 应用程序未在机器上运行，或者自托管 runner 应用程序无法与 GitHub 通信。
网络连接故障排除
检查自托管 runner 网络连接
您可以使用自托管 runner 应用程序的config脚本和--check参数来检查自托管 runner 是否可以访问 GitHub 上所有必需的网络服务。
除了--check之外，您还必须为脚本提供两个参数：
--url，用于指定 GitHub 仓库、组织或企业的 URL。例如，--url https://github.com/octo-org/octo-repo。--pat，用于指定个人访问令牌（经典版）的值，该令牌必须具有workflow作用域，或具有工作流读取和写入访问权限的细粒度个人访问令牌。例如，--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。如果任何检查失败，您可以在检查的日志文件中查看有关问题的更多详细信息。日志文件位于您安装 runner 应用程序的_diag目录中，每个检查的日志文件路径都显示在脚本的控制台输出中。
如果任何检查失败，您还应该验证您的自托管 runner 机器是否满足所有通信要求。更多信息，请参见“关于自托管 runner”。
禁用 TLS 证书验证
默认情况下，自托管 runner 应用程序会验证 GitHub 的 TLS 证书。如果您遇到网络问题，您可能希望出于测试目的禁用 TLS 证书验证。
要在自托管 runner 应用程序中禁用 TLS 证书验证，请在配置和运行自托管 runner 应用程序之前，将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
警告
不建议禁用 TLS 验证，因为 TLS 可确保自托管 runner 应用程序和 GitHub 之间的隐私和数据完整性。我们建议您在自托管 runner 的操作系统证书存储中安装 GitHub 证书。有关如何安装 GitHub 证书的指导，请咨询您的操作系统供应商。
查看自托管 runner 应用程序日志文件
您可以监控自托管 runner 应用程序的状态及其活动。日志文件保存在您安装 runner 应用程序的_diag目录中，每次应用程序启动时都会生成一个新的日志。文件名以Runner_开头，后跟应用程序启动时间的 UTC 时间戳。
警告
临时 runner 的 runner 应用程序日志文件必须被转发和外部保存，以用于故障排除和诊断。有关临时 runner 和自托管 runner 自动缩放的更多信息，请参见“自托管 runner 的自动缩放”。
有关工作流作业执行的详细日志，请参阅下一节中描述的Worker_文件。
查看作业的日志文件
自托管 runner 应用程序会为其处理的每个作业创建一个详细的日志文件。这些文件存储在您安装 runner 应用程序的_diag目录中，文件名以Worker_开头。
使用 journalctl 检查自托管 runner 应用程序服务
对于使用服务运行应用程序的基于 Linux 的自托管 runner，您可以使用journalctl监控其实时活动。默认的基于 systemd 的服务使用以下命名约定：actions.runner.<org>-<repo>.<runnerName>.service。如果此名称超过 80 个字符，则会被截断，因此查找服务名称的首选方法是检查.service文件。例如：
$ cat ~/actions-runner/.service
actions.runner.octo-org-octo-repo.runner01.service
如果由于服务安装在其他位置而导致此操作失败，则可以在正在运行的服务列表中找到服务名称。例如，在大多数 Linux 系统上，您可以使用systemctl命令：
$ 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)
您可以使用journalctl监控自托管 runner 的实时活动：
sudo journalctl -u actions.runner.octo-org-octo-repo.runner01.service -f
在此示例输出中，您可以看到runner01启动、接收名为testAction的作业，然后显示结果状态。
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
要查看systemd配置，您可以在此处找到服务文件：/etc/systemd/system/actions.runner.<org>-<repo>.<runnerName>.service。如果您想自定义自托管 runner 应用程序服务，请不要直接修改此文件。请按照“将自托管 runner 应用程序配置为服务”中描述的说明进行操作。
使用launchd检查自托管 runner 应用程序服务
对于将应用程序作为服务运行的基于 macOS 的自托管 runner，您可以使用launchctl监控其实时活动。默认的基于 launchd 的服务使用以下命名约定：actions.runner.<org>-<repo>.<runnerName>。如果此名称超过 80 个字符，则会被截断，因此查找服务名称的首选方法是检查 runner 目录中的.service文件。
% cat ~/actions-runner/.service
/Users/exampleUsername/Library/LaunchAgents/actions.runner.octo-org-octo-repo.runner01.plist
svc.sh脚本使用launchctl检查应用程序是否正在运行。例如：
$ ./svc.sh status
status actions.runner.example.runner01:
/Users/exampleUsername/Library/LaunchAgents/actions.runner.example.runner01.plist
Started:
379 0 actions.runner.example.runner01
生成的输出包括进程 ID 和应用程序的launchd服务的名称。
要查看launchd配置，您可以在此处找到服务文件：/Users/exampleUsername/Library/LaunchAgents/actions.runner.<repoName>.<runnerName>.service。如果您想自定义自托管 runner 应用程序服务，请不要直接修改此文件。请按照“将自托管 runner 应用程序配置为服务”中描述的说明进行操作。
使用 PowerShell 检查自托管 runner 应用程序服务
对于将应用程序作为服务运行的基于 Windows 的自托管 runner，您可以使用 PowerShell 监控其实时活动。服务使用命名约定GitHub Actions Runner (<org>-<repo>.<runnerName>)。您也可以通过检查 runner 目录中的.service文件来查找服务的名称。
PS C:\actions-runner> Get-Content .service
actions.runner.octo-org-octo-repo.runner01.service
您可以在 Windows 的“服务”应用程序 (services.msc) 中查看 runner 的状态。您也可以使用 PowerShell 检查服务是否正在运行：
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
您可以使用 PowerShell 检查自托管 runner 的近期活动。在此示例输出中，您可以看到应用程序启动、接收名为testAction的作业，然后显示结果状态。
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 的版本低于某个阈值，它将无法处理作业。自托管 runner 应用程序会自动更新自身，但请注意，此过程不包括对操作系统或其他软件的任何更新；您需要单独管理这些更新。
您可以在Runner_日志文件中查看更新活动。例如：
[Feb 12 12:37:07 INFO SelfUpdater] An update is available.
此外，您还可以在您安装 runner 应用程序的_diag目录中找到的SelfUpdate日志文件中找到更多信息。
自托管 runner 中的容器故障排除
检查是否安装了 Docker
如果您的作业需要容器，则自托管 runner 必须是基于 Linux 的，并且需要安装 Docker。检查您的自托管 runner 是否已安装 Docker 以及服务是否正在运行。
您可以使用systemctl检查服务状态：
$ sudo systemctl is-active docker.service
active
如果未安装 Docker，则相关的 Actions 将失败并出现以下错误：
[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'
检查 Docker 权限
如果您的作业失败并出现以下错误：
dial unix /var/run/docker.sock: connect: permission denied
检查自托管 runner 的服务帐户是否具有使用 Docker 服务的权限。您可以通过检查systemd中自托管 runner 的配置来识别此帐户。例如：
$ sudo systemctl show -p User actions.runner.octo-org-octo-repo.runner01.service
User=runner-user
检查 runner 上安装了哪个 Docker 引擎
如果您的构建失败并出现以下错误：
Error: Input required and not supplied: java-version
检查您的自托管 runner 上安装了哪个 Docker 引擎。为了将 Action 的输入传递到 Docker 容器中，runner 使用的环境变量可能包含短横线作为其名称的一部分。如果 Docker 引擎不是二进制可执行文件，而是 shell 包装器或链接（例如，使用snap在 Linux 上安装的 Docker 引擎），则 Action 可能无法获取输入。要解决此错误，请配置您的自托管 runner 以使用不同的 Docker 引擎。
要检查您的 Docker 引擎是否使用snap安装，请使用which命令。在以下示例中，Docker 引擎是使用snap安装的：
$ which docker
/snap/bin/docker