Мониторинг и устранение неполадок в самостоятельно размещенных средствах выполнения

Проверка состояния локального средства выполнения тестов

Локальное средство выполнения тестов может находиться в репозитории, организации или корпоративных параметрах учетной записи GitHub. Для управления локальным средством выполнения необходимо иметь следующие разрешения в зависимости от того, куда было добавлено это локальное средство выполнения:

• Пользовательский репозиторий: необходимо быть владельцем репозитория.

• Организация: необходимо быть владельцем организации.

• Репозиторий организации: необходимо быть владельцем организации или иметь доступ к репозиторию с правами администратора.

• Учетная запись предприятия: необходимо быть владельцем предприятия.

1. В организации или репозитории перейдите на главную страницу и щелкните Параметры. 1. На левой боковой панели щелкните Actions (Средства выполнения).

2. В разделе "Средства выполнения" можно просмотреть список зарегистрированных средств выполнения, включая их имена, метки и состояние.

   Состояние может принимать следующие значения.

   • Бездействие: средство выполнения тестов подключено к GitHub Enterprise Cloud и готово к выполнению заданий.
   • Активно: средство выполнения тестов в настоящее время выполняет задание.
   • Автономный режим: средство выполнения тестов не подключено к GitHub Enterprise Cloud. Это может быть связано с тем, что компьютер находится в автономном режиме, приложение локального средства выполнения тестов не запущено на компьютере или приложение локального средства выполнения тестов не может обмениваться данными с GitHub Enterprise Cloud.

Устранение неполадок сетевого подключения

Проверка сетевого подключения локального средства выполнения тестов

Вы можете использовать скрипт приложения run локального средства выполнения с параметром --check , чтобы убедиться, что локальное средство выполнения тестов может получить доступ ко всем необходимым сетевым службам в GitHub.com.

В дополнение к --check в скрипте необходимо указать два аргумента:

• --url с URL-адресом репозитория, организации или предприятия GitHub. Например, --url https://github.com/octo-org/octo-repo.
• --pat со значением personal access token (classic), который должен иметь workflow область , или fine-grained personal access token с доступом для чтения и записи рабочих процессов . Например, --pat ghp_abcd1234. Дополнительные сведения см. в разделе Создание личного маркера доступа.

Пример:

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

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

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

Скрипт тестирует каждую службу и выводит либо PASS, либо FAIL для каждой из них. Если не удалось пройти какие-либо проверки, вы можете просмотреть дополнительные сведения о проблеме в файле журнала для проверки. Файлы журнала находятся в каталоге _diag, в котором установлено приложение средства выполнения тестов, а путь к файлу журнала для каждой проверки отображается в выходных данных консоли скрипта.

Если не удалось пройти какие-либо проверки, необходимо также убедиться в том, что компьютер локального средства выполнения тестов соответствует всем требованиям для обмена данными. Дополнительные сведения см. в разделе О самостоятельно размещенных средствах выполнения.

Отключение проверки сертификата TLS

По умолчанию приложение локального средства выполнения тестов проверяет сертификат TLS для GitHub Enterprise Cloud. При возникновении проблем с сетью может потребоваться отключить проверку сертификата 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

Просмотр файлов журнала приложений локального средства выполнения тестов

Вы можете отслеживать состояние приложения локального средства выполнения тестов и его действия. Файлы журнала хранятся в каталоге _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.

Кроме того, дополнительные сведения представлены в файлах журнала SelfUpdate, расположенных в каталоге _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 не является двоичным исполняемым файлом, а является оболочкой оболочки или ссылкой (например, подсистемой Docker, установленной в Linux с помощью snap). Чтобы устранить эту ошибку, настройте локальное средство выполнения тестов на использование другого обработчика Docker.

Чтобы проверить, установлен ли модуль Docker с помощью snap, используйте which команду . В следующем примере подсистема Docker была установлена с помощью snap:

$ which docker
/snap/bin/docker