Устранение неполадок рабочих процессов

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

Существует несколько способов устранения неполадок при выполнении неудачного рабочего процесса.

С использованием GitHub Copilot

Чтобы начать чат с GitHub Copilot неудачным запуском рабочего процесса, вы можете сделать так:

• Рядом с отметкой «неудачный» в поле слияния нажмите , затем выберите ошибку «Объяснить».
• В поле слияния щелкните сбой. В верхней части страницы сводки запуска рабочих процессов нажмите «Объяснить ошибку».

Это открывает окно чата с GitHub Copilot, где будет представлен инструкции по решению проблемы.

Использование журналов выполнения рабочих процессов

Каждый запуск рабочего процесса создает журналы действий, которые можно просматривать, скачивать, а также выполнять по ним поиск. Дополнительные сведения см. в разделе Использование журналов выполнения рабочих процессов.

Включение ведения журналов отладки

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

Если рабочий процесс использует определенные инструменты или действия, включение их параметров отладки или подробного ведения журнала может помочь создать более подробные выходные данные для устранения неполадок. Например, можно использовать npm install --verbose для npm или GIT_TRACE=1 GIT_CURL_VERBOSE=1 git ... для git.

Просмотр ошибок выставления счетов

Использование действий включает минуты выполнения и хранилище для артефактов рабочего процесса. Дополнительные сведения см. в разделе Биллинг GitHub Actions.

Настройка бюджета

Настройка бюджета действий может помочь немедленно разблокировать рабочие процессы из-за ошибок выставления счетов или хранилища. Это позволит взимать счета за дополнительные минуты и использование хранилища до указанной суммы бюджета. Дополнительные сведения см. в разделе Настройка бюджетов для контроля расходов на лимитные продукты.

Обзор GitHub Actions активности с помощью метрик

Чтобы проанализировать эффективность и надежность рабочих процессов с помощью метрик, см. раздел Просмотр метрик GitHub Actions.

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

Вы можете просмотреть поле рабочего процесса on: , чтобы понять, что ожидается активировать рабочий процесс. Дополнительные сведения см. в разделе Активация рабочего процесса.

Полный список доступных событий см. в разделе События, инициирующие рабочие процессы.

Активация условий событий

Некоторые триггерные события выполняются только из ветвь по умолчанию (т. е. issues, schedule). Версии файлов рабочего процесса, существующие за пределами ветвь по умолчанию, не будут запускаться для этих событий.

Рабочие процессы не будут выполняться в pull_request действии, если запрос на вытягивание имеет конфликт слияния.

Рабочие процессы, которые в противном случае будут активированы push или pull_request действия будут пропущены, если сообщение фиксации содержит заметку о пропуске. Дополнительные сведения см. в разделе Пропуск запусков рабочих процессов.

Запланированные рабочие процессы выполняются в непредвиденное время

Запланированные события могут задерживаться в периоды высокой нагрузки GitHub Actions на рабочие процессы.

К периодам высокой загрузки относится начало каждого часа. Если загрузка достаточно высока, некоторые задания в очереди могут быть удалены. Чтобы уменьшить вероятность задержки, запланируйте выполнение рабочего процесса в другое время часа. Дополнительные сведения см. в разделе События, инициирующие рабочие процессы.

Ограничения фильтрации и диффа

Определенные события позволяют фильтровать по ветвям, тегам и/или путям, которые можно настроить. Создание запуска рабочего процесса будет пропущено, если условия фильтра применяются для фильтрации рабочего процесса.

Специальные символы можно использовать с фильтрами. Дополнительные сведения см. в разделе Синтаксис рабочего процесса для GitHub Actions.

Для фильтрации путей оценка диффов ограничена первыми 300 файлами. Если в первых 300 файлах, возвращаемых фильтром, изменены файлы, которые не совпадают, рабочий процесс не будет выполняться. Дополнительные сведения см. в разделе Синтаксис рабочего процесса для GitHub Actions.

Устранение неполадок при выполнении рабочего процесса

Выполнение рабочего процесса включает все проблемы, возникающие после запуска рабочего процесса, и запуск рабочего процесса был создан.

Условия отладки работы

Если задание было неожиданно пропущено или выполнено в тот момент, когда вы ожидали, вы можете посмотреть выражение оценки, чтобы понять почему:

1. Кликните на задание в запуске рабочего процесса.
2. Скачайте архив журналов из меню вакансии.
3. Откройте файл JOB-NAME/system.txt.
4. Ищите Evaluatingлинии , Expandedи Result .

Строка Expanded показывает фактические значения времени, которые были подставлены в вашем if состоянии, объясняя, почему выражение оценивается в true или false.

Дополнительные сведения см. в разделе Просмотр логов выражения состояния задания.

Отмена рабочих процессов

Если стандартная отмена через пользовательский интерфейс или API не обрабатывается должным образом, может быть задана условная инструкция, настроенная для выполняемых заданий рабочего процесса, что приводит к не отмене.

В таких случаях api можно использовать для принудительного отмены выполнения. Дополнительные сведения см. в разделе Конечные точки REST API для выполнения рабочих процессов.

Распространенной причиной может быть использование always()функции проверки состояния, которая возвращается trueдаже при отмене. Альтернативой является использование обратной cancelled() функции. ${{ !cancelled() }}

Дополнительные сведения см. в разделе [AUTOTITLE и Использование условий для управления выполнением задания](/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/canceling-a-workflow#steps-github-takes-to-cancel-a-workflow-run).

Устранение неполадок с средствами выполнения

Определение меток runner

GitHub-Размещённые бегущие используют предустановленные метки, поддерживаемые в actions/runner-images репозитории.

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

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

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

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

IP-адреса бегунов отмечены сканерами безопасности

GitHub-Размещённые раннеры используют динамически назначаемые IP-адреса из общей инфраструктуры. Эти IP-адреса публикуются через Meta API (например, ключи actions and actions_macos keys). Дополнительные сведения см. в разделе Конечные точки REST API для метаданных.

Сторонние службы разведки угроз, сканеры репутации IP-адресов или производители файрволов могут отмечать эти IP-адреса как «злонамеренные» или «подозрительные». Поскольку базовая инфраструктура общая, активность других пользователей той же инфраструктуры может влиять на репутационные показатели, присваиваемые этим адресам.

GitHub не контролирует списки репутации независимых IP и не может комментировать их точность или частоту обновлений. Чтобы проверить, принадлежит GitHubли IP-адрес -hosted runners, проверьте IP-диапазоны, возвращаемые Meta API.

Если у вас есть опасения по безопасности по поводу IP-адреса, принадлежащего Microsoft, сообщите об этом в Центр Майкрософт по реагированию на угрозы (MSRC).

Рекомендации по устранению неполадок в сети

Наша поддержка ограничена для проблем с сетью, которые включают:

• Сети
• Внешние сети
• Сторонние системы
• Общее подключения к Интернету

Чтобы увидеть GitHubстатус платформы в реальном времени, проверьтеGitHub Статус.

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

Если вы не уверены в проблеме, свяжитесь Служба поддержки GitHubс . Дополнительные сведения о том, как обратиться в службу поддержки, см. в разделе Обращение в службу поддержки GitHub.

DNS

Проблемы могут возникать из конфигурации, разрешения или устранения проблем с системой доменных имен (DNS). Мы рекомендуем ознакомиться с доступными журналами, документацией поставщика или обратиться к администраторам за дополнительной помощью.

Брандмауэры

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

Прокси

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

Сведения о настройке приложения runner для использования прокси-сервера см. в autoTITLE .

подсети;

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

Сертификаты

Проблемы могут возникать из самозаверяемых или пользовательских цепочек сертификатов и хранилищ сертификатов. Вы можете проверить, что используемый сертификат не истек и в настоящее время является доверенным. Сертификаты могут проверяться с помощью curl или аналогичных средств. Вы также можете просмотреть доступные журналы, документацию поставщика или обратиться к администраторам за дополнительной помощью.

Списки IP-адресов

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

Для информации об GitHubIP-адресах , например, используемых GitHub-hosted runners, см. О IP-адресах GitHub.

Статические IP-адреса доступны для использования с GitHub-hosted более крупными раннерами. Дополнительные сведения см. в разделе Управление большими бегунами .

Операционные системы и приложения программного обеспечения

Помимо межсетевых экранов или прокси, кастомизации, выполняемые для GitHub-hosted runners, такие как установка дополнительных программных пакетов, могут привести к перебоям в коммуникации. Сведения о доступных параметрах настройки см. в разделе Настройка раннеров, размещённых на GitHub.

• Дополнительные сведения о необходимых конечных точках в Справочник по локальным запускам см. в самостоятельно размещенных запусках.

• Сведения о настройке WireGuard см. в разделе Создание наложения сети с помощью WireGuard.

• Дополнительные сведения о настройке OpenID Connect (OIDC) см. в разделе Использование шлюза API с OIDC.

Azure частные сети для бегунов, ведущих GitHub

Проблемы могут возникнуть из-за использования раннеров GitHub в настройках Azure виртуальных сетей (VNETs).

Для советов по устранению неполадок смотрите в документации AUTOTITLE или AUTOTITLE.