Эта версия GitHub Enterprise Server была прекращена 2024-07-09. Исправления выпускаться не будут даже при критических проблемах безопасности. Для повышения производительности, повышения безопасности и новых функций выполните обновление до последней версии GitHub Enterprise Server. Чтобы получить справку по обновлению, обратитесь в службу поддержки GitHub Enterprise.

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

Устранение распространенных проблем, возникающих при использовании GitHub Actions в GitHub 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/configuration/configuring-your-enterprise/accessing-the-administrative-shell-ssh)".

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

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

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

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

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

Настройка 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 Enterprise Server:

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

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

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

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

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

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

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

В каталоге приложения локального средства выполнения измените файлы .runner и .credentials, заменив все упоминания старого имени узла новым именем узла, а затем перезапустите приложение локального средства выполнения.
Удалите средство выполнения из GitHub Enterprise Server с помощью пользовательского интерфейса и добавьте его повторно. Дополнительные сведения см. в разделе "[AUTOTITLE" и "Удаление локальных средств выполнения](/actions/hosting-your-own-runners/managing-self-hosted-runners/adding-self-hosted-runners)".

Зависание заданий, ограничения на использование памяти и загрузку ЦП в GitHub Actions

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

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

1. Проверка общего использования ЦП и памяти в консоли управления

Откройте консоль управления и используйте панель мониторинга для проверки графиков общего потребления ресурсов ЦП и памяти в разделе "Работоспособность системы". Дополнительные сведения см. в разделе Доступ к панели мониторинга.

Если общее использование ЦП "Работоспособность системы" близко к 100%, или нет свободного объема памяти, то ваш экземпляр GitHub Enterprise Server выполняется в емкости и необходимо увеличить масштаб. Дополнительные сведения см. в разделе Увеличение ресурсов ЦП или памяти.

2. Проверка использования ЦП и памяти заданиями Nomad в консоли управления

Если общий уровень использования ЦП и памяти в разделе "Работоспособность системы" в порядке, прокрутите страницу панели мониторинга вниз до раздела "Задания Nomad" и просмотрите графики "Процент загрузки ЦП" и "Использование памяти".

Каждый график соответствует одной службе. Для служб GitHub Actions обратите внимание на следующее:

mps_frontend
mps_backend
token_frontend
token_backend
actions_frontend
actions_backend

Если какие-либо из служб имеют уровень загрузки ЦП 100 % или близко к этому либо если память почти исчерпана (объем по умолчанию 2 ГБ), то, возможно, необходимо выделить дополнительные ресурсы для этих служб. Запишите службы, для которых достигнут или почти достигнут предел ресурсов.

3. Увеличение объема ресурсов, выделенных для служб с исчерпанными ресурсами

Войдите в административную оболочку с помощью SSH. Дополнительные сведения см. в разделе Доступ к административной оболочке (SSH).
Выполните следующую команду, чтобы узнать, какие ресурсы доступны для выделения:
```
nomad node status -self
```
В выходных данных найдите раздел "Выделенные ресурсы". Похоже на следующий пример:
```
Allocated Resources
CPU              Memory          Disk
7740/49600 MHZ   23 GiB/32 GiB   4.4 GiB/7.9 GiB
```
Для ЦП и памяти здесь показано, сколько ресурсов выделено для общего числа всех служб (левое значение) и сколько ресурсов доступно (правое значение). В приведенном выше примере выделено 23 ГиБ памяти из 32 ГиБ. Это значит, что для выделения доступно 9 ГиБ памяти.

Внимание! Будьте осторожны: не выделите больше ресурсов, чем доступно всего, иначе службы не запустятся.
Перейдите в каталог /etc/consul-templates/etc/nomad-jobs/actions.
```
cd /etc/consul-templates/etc/nomad-jobs/actions
```
В этом каталоге есть три файла, которые соответствуют службам GitHub Actions, перечисленным выше:
- mps.hcl.ctmpl
- token.hcl.ctmpl
- actions.hcl.ctmpl
Для служб, которые требуют корректировки, откройте соответствующий файл и найдите группу resources, которая выглядит следующим образом:
```
resources {
  cpu = 512
  memory = 2048
  network {
    port "http" { }
  }
}
```
Для ресурсов ЦП значения указаны в МГц, а для ресурсов памяти — в МБ.

Например, чтобы увеличить максимальный объем ресурсов в приведенном выше примере до 1 ГГц для ЦП и до 4 ГБ для памяти, измените значения следующим образом:
```
resources {
  cpu = 1024
  memory = 4096
  network {
    port "http" { }
  }
}
```
Сохраните и закройте файл.
Выполните ghe-config-apply, чтобы применить изменения.

Если при выполнении команды ghe-config-apply вы получаете такой результат, как Failed to run nomad job '/etc/nomad-jobs/<name>.hcl', скорее всего, было выделено больше ресурсов ЦП или памяти, чем доступно. В этом случае снова измените файлы конфигурации, уменьшив выделяемый объем ресурсов ЦП или памяти, а затем повторно выполните команду ghe-config-apply.
После применения конфигурации выполните команду ghe-actions-check , чтобы убедиться в том, что службы GitHub Actions работают.

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

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

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

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

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

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

Войдите в административную оболочку с помощью SSH. Дополнительные сведения см. в разделе Доступ к административной оболочке (SSH).
Чтобы удалить ограничения рабочих процессов, активированных Dependabot для ваш экземпляр GitHub Enterprise Server, используйте следующую команду.
```
ghe-config app.actions.disable-dependabot-enforcement true
```
Примените конфигурацию.
```
ghe-config-apply
```
Вернитесь на 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, выполните описанную ниже процедуру.

Определите организацию, которая будет хранить официальные пакетные действия и начальные рабочие процессы. Можно создать новую организацию или использовать существующую.
- Сведения о создании новой организации см. в разделе "Создание новой организации с нуля".
- Дополнительные сведения о выборе имени для этой организации см. в разделе "Начало работы с GitHub Actions для сервера GitHub Enterprise".
Войдите в административную оболочку с помощью SSH. Дополнительные сведения см. в разделе Доступ к административной оболочке (SSH).
Чтобы назначить организацию в качестве расположения для хранения пакетных действий, используйте команду ghe-config, заменив ORGANIZATION на имя своей организации.
```
ghe-config app.actions.actions-org ORGANIZATION
```
and:
```
ghe-config app.actions.github-org ORGANIZATION
```
Чтобы добавить пакетные действия в организацию, отмените SHA.
```
ghe-config --unset 'app.actions.actions-repos-sha1sum'
```
Примените конфигурацию.
```
ghe-config-apply
```

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