Примечание. В GitHub Enterprise Server в настоящее время не поддерживаются средства выполнения тестов, размещенные в GitHub. Дополнительные сведения о планируемой поддержке в будущем см. в GitHub public roadmap.
Проверка состояния локального средства выполнения тестов
Локальное средство выполнения может находиться в репозитории, организации или корпоративных параметров на ваш экземпляр GitHub Enterprise Server. Для управления локальным средством выполнения необходимо иметь следующие разрешения в зависимости от того, куда было добавлено это локальное средство выполнения:
-
Пользовательский репозиторий: необходимо быть владельцем репозитория.
-
Организация: необходимо быть владельцем организации.
-
Репозиторий организации: необходимо быть владельцем организации или иметь доступ к репозиторию с правами администратора.
-
Предприятие: необходимо быть администратором сайта GitHub Enterprise.
-
В организации или репозитории перейдите на главную страницу и щелкните Параметры.
-
На левой боковой панели щелкните Actions, а затем нажмите кнопку " Runners".
-
В разделе "Средства выполнения" можно просмотреть список зарегистрированных средств выполнения, включая их имена, метки и состояние.
Состояние может принимать следующие значения.
- Бездействие: средство выполнения тестов подключено к GitHub Enterprise Server и готово к выполнению заданий.
- Активно: средство выполнения тестов в настоящее время выполняет задание.
- Автономный режим: средство выполнения тестов не подключено к GitHub Enterprise Server. Это может быть связано с тем, что компьютер находится в автономном режиме, приложение локального средства выполнения тестов не запущено на компьютере или приложение локального средства выполнения тестов не может обмениваться данными с GitHub Enterprise Server.
Устранение неполадок сетевого подключения
Проверка сетевого подключения локального средства выполнения тестов
Скрипт локального приложения run
runner можно использовать с параметром, --check
чтобы проверка, что локальный модуль выполнения может получить доступ ко всем необходимым сетевым службам на ваш экземпляр GitHub Enterprise Server.
В дополнение к --check
в скрипте необходимо указать два аргумента:
--url
с URL-адресом репозитория, организации или предприятия GitHub. Например,--url https://github.com/octo-org/octo-repo
.--pat
значением personal access token, которые должны иметьworkflow
область. Например,--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 Server. Если GitHub Enterprise Server имеет самозаверяющий или выпущенный для внутреннего использования сертификат, может потребоваться отключить проверку сертификата 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.sh
Предупреждение. Не рекомендуется отключать проверку TLS, так как TLS обеспечивает конфиденциальность и целостность данных между приложением локального средства выполнения тестов и GitHub Enterprise Server. Рекомендуется установить в хранилище сертификатов операционной системы сертификат GitHub Enterprise Server для локального средства выполнения тестов. Для получения инструкций по установке сертификата GitHub Enterprise Server обратитесь к своему поставщику операционной системы.
Просмотр файлов журнала приложений локального средства выполнения тестов
Вы можете отслеживать состояние приложения локального средства выполнения тестов и его действия. Файлы журнала хранятся в каталоге _diag
, в котором установлено приложение средства выполнения тестов, и при каждом запуске приложения создается новый журнал. Имя файла начинается с Runner_
метки времени UTC при запуске приложения.
Подробные журналы выполнения заданий рабочего процесса см. в следующем разделе, Worker_
в котором описываются файлы.
Просмотр файла журнала задания
Приложение локального средства выполнения тестов создает подробный файл журнала для каждого обрабатываемого задания. Эти файлы хранятся в каталоге _diag
, где установлено приложение runner, и имя файла начинается с Worker_
.
Проверка службы приложения локального средства выполнения тестов с помощью journalctl
Для локальных средств выполнения тестов на основе Linux, запускающих приложение с помощью службы, можно использовать 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
для мониторинга действий локального средства выполнения тестов в реальном времени:
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
.
Если требуется настроить службу приложения локального средства выполнения тестов, не изменяйте этот файл напрямую. Следуйте инструкциям, описанным в разделеНастройка приложения локального средства выполнения как службы.
Проверка службы приложения локального средства выполнения тестов с помощью launchd
Для локальных средств выполнения тестов на основе macOS, запускающих приложение как службу, можно использовать launchctl
для отслеживания их действий в реальном времени. В службе на основе launchd по умолчанию используется следующее соглашение об именовании: actions.runner.<org>-<repo>.<runnerName>
. Это имя усекается, если превышает 80 символов, поэтому предпочтительный способ поиска имени службы — проверка файла .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
Итоговые выходные данные содержат идентификатор процесса и имя службы приложения launchd
.
Чтобы просмотреть конфигурациюlaunchd
, можно найти файл службы здесь: /Users/exampleUsername/Library/LaunchAgents/actions.runner.<repoName>.<runnerName>.service
.
Если требуется настроить службу приложения локального средства выполнения тестов, не изменяйте этот файл напрямую. Следуйте инструкциям, описанным в разделеНастройка приложения локального средства выполнения как службы.
Проверка службы приложения локального средства выполнения тестов с помощью PowerShell.
Для локальных средств выполнения тестов на основе Windows, запускающих приложение как службу, можно использовать PowerShell для отслеживания их действий в реальном времени. Служба использует соглашение об именовании GitHub Actions Runner (<org>-<repo>.<runnerName>)
. Чтобы найти имя службы, можно также проверить файл .service в каталоге средства выполнения тестов:
PS C:\actions-runner> Get-Content .service
actions.runner.octo-org-octo-repo.runner01.service
Состояние средства выполнения тестов можно посмотреть в приложении Windows Services (services.msc
). 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 можно использовать для проверки недавних действий локального средства выполнения тестов. В этом примере выходных данных можно посмотреть запуск приложения, получить задание с именем 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_
журнала. Например:
[Feb 12 12:37:07 INFO SelfUpdater] An update is available.
Кроме того, дополнительные сведения представлены в файлах журнала SelfUpdate, расположенных в каталоге _diag
, где установлено приложение средства выполнения тестов.
Устранение неполадок контейнеров в локальных средствах выполнения тестов
Проверка установки платформы Docker
Если для выполнения заданий требуются контейнеры, то необходимо использовать локальное средство выполнения тестов на основе Linux и установить Docker. Убедитесь, что в локальном средстве выполнения тестов установлена платформа Docker и что служба запущена.
Для проверки состояния службы можно использовать systemctl
:
$ sudo systemctl is-active docker.service
active
Если платформа Docker не установлена, зависимые действия будут завершаться сбоем со следующими ошибками:
[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
Убедитесь, что учетной записи службы локального средства выполнения тестов предоставлено разрешение на использование службы Docker. Чтобы определить эту учетную запись, проверьте конфигурацию локального средства выполнения тестов в systemd
. Например:
$ sudo systemctl show -p User actions.runner.octo-org-octo-repo.runner01.service
User=runner-user
Разрешение модулей выполнения, которые находятся в автономном режиме после обновления ваш экземпляр GitHub Enterprise Server
Если вы используете временные средства выполнения и отключили автоматические обновления, перед обновлением ваш экземпляр GitHub Enterprise Server, сначала следует обновить локальные модули выполнения до версии приложения runner, которое будет выполняться в обновленном экземпляре. Обновление ваш экземпляр GitHub Enterprise Server перед обновлением временных бегунов может привести к отключению бегунов. Дополнительные сведения см. в разделе Обновление GitHub Enterprise Server.
Если средства выполнения находятся в автономном режиме по этой причине, обновите их вручную. Дополнительные сведения см. в инструкциях по установке последнего выпуска в репозитории actions/runner.
Проверка того, какой модуль Docker установлен на средстве выполнения
Если сборка завершается сбоем со следующей ошибкой:
Error: Input required and not supplied: java-version
Проверьте, какой модуль Docker установлен в локальном средстве выполнения. Чтобы передать входные данные действия в контейнер Docker, средство выполнения использует переменные среды, которые могут содержать дефисы в составе их имен. Действие может не получить входные данные, если подсистема Docker не является двоичным исполняемым файлом, но вместо этого является оболочкой оболочки или ссылкой (например, подсистема Docker, установленная в Linux с помощью snap
). Чтобы устранить эту ошибку, настройте локально размещенного модуля runner для использования другого обработчика Docker.
Чтобы проверка, если модуль Docker был установлен с помощьюsnap
, используйте which
команду. В следующем примере модуль Docker был установлен с помощью snap
:
$ which docker
/snap/bin/docker