Эта версия GitHub Enterprise Server будет прекращена 2026-08-25. Снятые релизы не поддерживаются. Исправления выпускаться не будут даже при критических проблемах безопасности. Для лучшей производительности, повышения безопасности и новых функций GitHub Enterprise Server см. Обзор процесса обновления. Для помощи с обновлением обращайтесь в GitHub Enterprise Support.

Устранение неполадок GitHub Actions для вашего предприятия

Устранение распространенных проблем, возникающих при использовании GitHub ActionsGitHub Enterprise Server.

Кто может использовать эту функцию?

Site administrators can troubleshoot GitHub Actions issues and modify GitHub Enterprise Server configurations.

В этой статье

Проверка работоспособности GitHub Actions

Вы можете проверить работоспособность GitHub Actionsваш экземпляр GitHub Enterprise Server программы ghe-actions-check командной строки. Дополнительные сведения см. в разделе [AUTOTITLE и Служебные программы командной строки](/admin/administering-your-instance/administering-your-instance-from-the-command-line/accessing-the-administrative-shell-ssh).

Настройка локальных модулей выполнения при использовании самозаверяющего сертификата для GitHub Enterprise Server

Настоятельно рекомендуется настроить TLS в GitHub Enterprise Server с сертификатом, подписанным доверенным центром авторизации. Хотя самозаверяющий сертификат можно использовать, необходимо дополнительно настроить локальные средства выполнения тестов, и не рекомендуется использовать сертификат для рабочих сред. Для получения дополнительной информации см. Настройка TLS.

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

Для подключения GitHub Enterprise Server к локальному средству выполнения с помощью самозаверяющего сертификата необходимо установить сертификат на компьютере runner, чтобы подключение было защищенно.

Инструкции по установке сертификата см. в документации по операционной системе средства выполнения.

Настройка Node.JS для использования сертификата

Большинство действий пишутся на JavaScript и выполняются с помощью Node.js, так что хранилище сертификатов операционной системы не используется. Чтобы локальное приложение средства выполнения использовало сертификат, необходимо задать переменную среды NODE_EXTRA_CA_CERTS на компьютере средства выполнения.

Переменную среды можно задать как системную переменную среды или объявить ее в файле, вызываемом .env в каталоге приложений для локального запуска (то есть каталог, в который вы скачали и распаковали программное обеспечение runner).

Например:

NODE_EXTRA_CA_CERTS=/usr/share/ca-certificates/extra/mycertfile.crt

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

Настройка контейнеров Docker для использования сертификата

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

Настройка параметров прокси-сервера HTTP для GitHub Actions

Если у вас есть http-прокси-сервер **, настроенный **на GitHub:

  • Необходимо добавить .localhostи 127.0.0.1``::1 в список исключений **** прокси-сервера HTTP (в этом порядке).
  • Если расположение внешнего хранилища не является маршрутизируемым, необходимо также добавить URL-адрес внешнего хранилища в список исключений.

Дополнительные сведения об изменении параметров прокси-сервера см. в разделе Настройка сервера веб-прокси исходящего трафика.

Если эти параметры не настроены правильно, могут возникать ошибки, такие как Resource unexpectedly moved to https://IP-ADDRESS при настройке или изменении GitHub Actions конфигурации.

Запуски не подключаются к GitHub Enterprise Server новому имени узла

Предупреждение

Не изменяйте имя узла для GitHub Enterprise Server после начальной настройки. Изменение имени узла приведет к непредвиденному поведению, вплоть до сбоя экземпляров и недопустимости ключей безопасности пользователей. Если вы изменили имя узла для экземпляра и столкнулись с проблемами, обратитесь к Поддержка GitHub Enterprise или Сведения о поддержке уровня "Премиум" GitHub.

Если вы развертываете GitHub Enterprise Server в среде с новым именем узла и старым именем узла больше не разрешается в экземпляре, локальные runners не смогут подключиться к старому имени узла и не будут выполнять никаких заданий.

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

  • В каталоге приложения локального средства выполнения измените файлы .runner и .credentials, заменив все упоминания старого имени узла новым именем узла, а затем перезапустите приложение локального средства выполнения.
  • Удалите средство выполнения из GitHub Enterprise Server пользовательского интерфейса и повторно добавьте его. Дополнительные сведения см. в разделе [AUTOTITLE и Удаление локальных средств выполнения](/actions/how-tos/manage-runners/self-hosted-runners/add-runners).

Устранение неисправностей при Dependabot активации существующих рабочих процессов

После настройки Dependabot обновлений ваш экземпляр GitHub Enterprise Serverмогут возникнуть сбои, когда существующие рабочие процессы активируются событиями Dependabot .

По умолчанию рабочие процессы запускаются GitHub Actions из push, pull_request``pull_request_reviewили pull_request_review_comment события обрабатываются так, Dependabot как если бы они были открыты из вилки репозитория. Это означает, что в отличие от рабочих процессов, активированных другими субъектами, они получают GITHUB_TOKEN только для чтения и не имеют доступа к секретам, которые обычно доступны. Это приведет к сбою всех рабочих процессов, которые пытаются записать в репозиторий при их активации Dependabot.

Существует три способа решения этой проблемы.

  1. Вы можете обновить рабочие процессы таким образом, чтобы они больше не активировались Dependabot с помощью выражения, например: if: github.actor != 'dependabot[bot]' Дополнительные сведения см. в разделе Оценка выражений в рабочих процессах и действиях.
  2. Вы можете изменить рабочие процессы так, чтобы использовался двухэтапный процесс с событием pull_request_target, которое не имеет таких ограничений. Дополнительные сведения см. в разделе Устранение неполадок зависимостей от действий GitHub.
  3. Вы можете предоставить рабочие процессы, Dependabot активированные доступом к секретам, и разрешить permissions термину увеличить область GITHUB_TOKENпо умолчанию. Дополнительные сведения см. в статье "Предоставление рабочих процессов, активированных доступом Dependabot к секретам и повышенным разрешениям ниже".

Предоставление рабочих процессов, активированных доступом к секретам Dependabot и повышенным разрешениям

  1. Войдите в административную оболочку с помощью SSH. Дополнительные сведения см. в разделе Доступ к административной оболочке (SSH).

  2. Чтобы удалить ограничения рабочих процессов, активированных в Dependabot противном ваш экземпляр GitHub Enterprise Serverслучае, используйте следующую команду.

    ghe-config app.actions.disable-dependabot-enforcement true

  3. Примените конфигурацию.

    ghe-config-apply

  4. Вернитесь в GitHub Enterprise Server.

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

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

A part of the Actions setup had problems and needs an administrator to resolve.

Чтобы установить официальные пакетные действия и шаблоны рабочих процессов в указанной организации GitHub Enterprise Server, выполните следующую процедуру.

  1. Определите организацию, которая будет хранить официальные объединенные действия и шаблоны рабочих процессов. Можно создать новую организацию или использовать существующую.

  2. Войдите в административную оболочку с помощью SSH. Дополнительные сведения см. в разделе Доступ к административной оболочке (SSH).

  3. Чтобы назначить организацию в качестве расположения для хранения пакетных действий, используйте команду ghe-config, заменив ORGANIZATION на имя своей организации.

    ghe-config app.actions.actions-org ORGANIZATION

    and:

    ghe-config app.actions.github-org ORGANIZATION

  4. Чтобы добавить пакетные действия в организацию, отмените SHA.

    ghe-config --unset 'app.actions.actions-repos-sha1sum'

  5. Примените конфигурацию.

    ghe-config-apply

Выполнив эти действия, вы можете возобновить настройку GitHub Actions в Начало работы с GitHub Actions for GitHub Enterprise Server.