{"meta":{"title":"Устранение неполадок рабочих процессов","intro":"Вы можете использовать инструменты для GitHub Actions отладки рабочих процессов.","product":"GitHub Actions","breadcrumbs":[{"href":"/ru/enterprise-server@3.22/actions","title":"GitHub Actions"},{"href":"/ru/enterprise-server@3.22/actions/how-tos","title":"Инструкции"},{"href":"/ru/enterprise-server@3.22/actions/how-tos/troubleshoot-workflows","title":"Устранение неполадок с рабочими процессами"}],"documentType":"article"},"body":"# Устранение неполадок рабочих процессов\n\nВы можете использовать инструменты для GitHub Actions отладки рабочих процессов.\n\n> \\[!NOTE]\n> GitHub Enterprise Serverразмещенные в данный момент средства выполнения не поддерживаются в GitHub.\n\n## Первоначальные предложения по устранению неполадок\n\nСуществует несколько способов устранения неполадок при выполнении неудачного рабочего процесса.\n\n### Использование журналов выполнения рабочих процессов\n\nКаждый запуск рабочего процесса создает журналы действий, которые можно просматривать, скачивать, а также выполнять по ним поиск. Дополнительные сведения см. в разделе [Использование журналов выполнения рабочих процессов](/ru/enterprise-server@3.22/actions/how-tos/monitor-workflows/use-workflow-run-logs).\n\n### Включение ведения журналов отладки\n\nЕсли журналы рабочих процессов не предоставляют достаточно сведений для диагностики причин несоответствующего выполнения рабочего процесса, задания или шага, можно дополнительно включить ведение журнала отладки. Дополнительные сведения см. в разделе [Включение ведения журналов отладки](/ru/enterprise-server@3.22/actions/how-tos/monitor-workflows/enable-debug-logging).\n\nЕсли рабочий процесс использует определенные инструменты или действия, включение их параметров отладки или подробного ведения журнала может помочь создать более подробные выходные данные для устранения неполадок.\nНапример, можно использовать `npm install --verbose` для npm или `GIT_TRACE=1 GIT_CURL_VERBOSE=1 git ...` для git.\n\n## Устранение неполадок триггеров рабочего процесса\n\nВо-первых, убедитесь, что ваш рабочий процесс не был отключён вручную, см. [Отключение и включение рабочего процесса](/ru/enterprise-server@3.22/actions/how-tos/manage-workflow-runs/disable-and-enable-workflows). Отключённый рабочий процесс не реагирует на свои триггеры.\n\nВы можете просмотреть поле рабочего процесса `on:` , чтобы понять, что ожидается активировать рабочий процесс. Дополнительные сведения см. в разделе [Активация рабочего процесса](/ru/enterprise-server@3.22/actions/how-tos/write-workflows/choose-when-workflows-run/trigger-a-workflow).\n\nПолный список доступных событий см. в разделе [События, инициирующие рабочие процессы](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows).\n\n### Активация условий событий\n\nНекоторые триггерные события выполняются только из ветвь по умолчанию (т. е. `issues`, `schedule`). Версии файлов рабочего процесса, существующие за пределами ветвь по умолчанию, не будут запускаться для этих событий.\n\nРабочие процессы не будут выполняться в `pull_request` действии, если запрос на вытягивание имеет конфликт слияния.\n\nРабочие процессы, которые в противном случае будут активированы `push` или `pull_request` действия будут пропущены, если сообщение фиксации содержит заметку о пропуске. Дополнительные сведения см. в разделе [Пропуск запусков рабочих процессов](/ru/enterprise-server@3.22/actions/how-tos/manage-workflow-runs/skip-workflow-runs).\n\n### Запланированные рабочие процессы выполняются в непредвиденное время\n\nЗапланированные события могут задерживаться в периоды высокой нагрузки GitHub Actions на рабочие процессы.\n\nК периодам высокой загрузки относится начало каждого часа. Если загрузка достаточно высока, некоторые задания в очереди могут быть удалены. Чтобы уменьшить вероятность задержки, запланируйте выполнение рабочего процесса в другое время часа. Дополнительные сведения см. в разделе [События, инициирующие рабочие процессы](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows#schedule).\n\n### Ограничения фильтрации и диффа\n\nОпределенные события позволяют фильтровать по ветвям, тегам и/или путям, которые можно настроить. Создание запуска рабочего процесса будет пропущено, если условия фильтра применяются для фильтрации рабочего процесса.\n\nСпециальные символы можно использовать с фильтрами. Дополнительные сведения см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#filter-pattern-cheat-sheet).\n\nДля фильтрации путей оценка диффов ограничена первыми 300 файлами. Если в первых 300 файлах, возвращаемых фильтром, изменены файлы, которые не совпадают, рабочий процесс не будет выполняться. Дополнительные сведения см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#git-diff-comparisons).\n\n## Устранение неполадок при выполнении рабочего процесса\n\nВыполнение рабочего процесса включает все проблемы, возникающие после запуска рабочего процесса, и запуск рабочего процесса был создан.\n\n### Отмена рабочих процессов\n\nЕсли стандартная отмена через [пользовательский интерфейс](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-cancellation) или [API](/ru/enterprise-server@3.22/rest/actions/workflow-runs?apiVersion=2022-11-28#cancel-a-workflow-run) не обрабатывается должным образом, может быть задана условная инструкция, настроенная для выполняемых заданий рабочего процесса, что приводит к не отмене.\n\nВ таких случаях api можно использовать для принудительного отмены выполнения. Дополнительные сведения см. в разделе [Конечные точки REST API для выполнения рабочих процессов](/ru/enterprise-server@3.22/rest/actions/workflow-runs?apiVersion=2022-11-28#force-cancel-a-workflow-run).\n\nРаспространенной причиной может быть использование `always()`[функции](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/expressions#status-check-functions) проверки состояния, которая возвращается `true`даже при отмене. Альтернативой является использование обратной `cancelled()` функции. `${{ !cancelled() }}`\n\nДополнительные сведения см. в разделе \\[AUTOTITLE и [Использование условий для управления выполнением задания](/ru/enterprise-server@3.22/actions/how-tos/write-workflows/choose-when-workflows-run/control-jobs-with-conditions)]\\(/actions/how-tos/manage-workflow-runs/cancel-a-workflow-run).\n\n## Устранение неполадок с средствами выполнения\n\n### Определение меток runner\n\nGitHub-Размещённые бегущие используют [предустановленные метки,](/ru/enterprise-server@3.22/actions/reference/runners/github-hosted-runners) поддерживаемые в [`actions/runner-images`](https://github.com/actions/runner-images?tab=readme-ov-file#available-images) репозитории.\n\nРекомендуется использовать уникальные имена меток для более крупных и локальных runners. Если метка совпадает с любой из существующих предустановленных меток, могут возникать проблемы с назначением runner, в которых отсутствует гарантия, в которой установлен соответствующий параметр runner, на котором будет выполняться задание.\n\n### Локальные средства выполнения тестов\n\nПри использовании локальных средств выполнения вы можете просматривать их действия и диагностировать распространенные проблемы.\n\nДополнительные сведения см. в разделе [Мониторинг и устранение неполадок в самостоятельно размещенных средствах выполнения](/ru/enterprise-server@3.22/actions/how-tos/manage-runners/self-hosted-runners/monitor-and-troubleshoot).\n\n## Рекомендации по устранению неполадок в сети\n\nНаша поддержка ограничена для проблем с сетью, которые включают:\n\n* Сети\n* Внешние сети\n* Сторонние системы\n* Общее подключения к Интернету\n\nЧтобы увидеть GitHubстатус платформы в реальном времени, [проверьтеGitHub Статус](https://githubstatus.com/).\n\nДля других проблем, связанных с сетью, просмотрите параметры сети вашей организации и проверьте состояние всех сторонних служб, к которым вы обращаетесь. Если проблемы сохраняются, обратитесь к администраторам сети, чтобы получить дополнительную помощь.\n\nЕсли вы не уверены в проблеме, свяжитесь Служба поддержки GitHubс . Дополнительные сведения о том, как обратиться в службу поддержки, см. в разделе [Обращение в службу поддержки GitHub](/ru/enterprise-server@3.22/support/contacting-github-support).\n\n### DNS\n\nПроблемы могут возникать из конфигурации, разрешения или устранения проблем с системой доменных имен (DNS). Мы рекомендуем ознакомиться с доступными журналами, документацией поставщика или обратиться к администраторам за дополнительной помощью.\n\n### Брандмауэры\n\nДействия могут блокироваться брандмауэрами. В этом случае может потребоваться просмотреть доступные журналы, документацию поставщика или обратиться к администраторам за дополнительной помощью.\n\n### Прокси\n\nДействия могут завершиться ошибкой при использовании прокси-сервера для обмена данными. Рекомендуется ознакомиться с доступными журналами, документацией поставщика или обратиться к администраторам за дополнительной помощью.\n\nСведения о настройке приложения runner для использования прокси-сервера см. в [autoTITLE](/ru/enterprise-server@3.22/actions/how-tos/manage-runners/use-proxy-servers) .\n\n### подсети;\n\nМожно столкнуться с проблемами с подсетями, используемыми или перекрывающимися существующей сетью, например в сетях виртуального облака или Docker. В таких случаях рекомендуется просмотреть топологию сети и подсети, используемые.\n\n### Сертификаты\n\nПроблемы могут возникать из самозаверяемых или пользовательских цепочек сертификатов и хранилищ сертификатов. Вы можете проверить, что используемый сертификат не истек и в настоящее время является доверенным. Сертификаты могут проверяться с помощью `curl` или аналогичных средств. Вы также можете просмотреть доступные журналы, документацию поставщика или обратиться к администраторам за дополнительной помощью.\n\n### Списки IP-адресов\n\nСписки разрешенных или запрещенных IP-адресов могут нарушить ожидаемые связи. Если возникла проблема, ознакомьтесь с доступными журналами, документацией поставщика или обратитесь к администраторам за дополнительной помощью.\n\n### Операционные системы и приложения программного обеспечения\n\nПомимо межсетевых экранов или прокси, кастомизации, выполняемые для GitHub-hosted runners, такие как установка дополнительных программных пакетов, могут привести к перебоям в коммуникации. Сведения о доступных параметрах настройки см. в разделе [Настройка раннеров, размещённых на GitHub](/ru/enterprise-server@3.22/actions/how-tos/manage-runners/github-hosted-runners/customize-runners).\n\n* Дополнительные сведения о необходимых конечных точках в [Справочник по локальным запускам](/ru/enterprise-server@3.22/actions/reference/runners/self-hosted-runners) см. в самостоятельно размещенных запусках.\n\n* Сведения о настройке WireGuard см. в разделе [Создание наложения сети с помощью WireGuard](/ru/enterprise-server@3.22/actions/how-tos/manage-runners/github-hosted-runners/connect-to-a-private-network/connect-with-wireguard).\n\n* Дополнительные сведения о настройке OpenID Connect (OIDC) см. в разделе [Использование шлюза API с OIDC](/ru/enterprise-server@3.22/actions/how-tos/manage-runners/github-hosted-runners/connect-to-a-private-network/connect-with-oidc)."}