Enterprise Server 3.7 release notes

On an instance with GitHub Actions enabled, nested calls to reusable workflows within a reusable workflow job with a matrix correctly evaluate contexts within expressions, like strategy: ${{ inputs.strategies }}.

On an instance in a high availability configuration, a git push operation could fail if GitHub Enterprise Server was simultaneously creating the repository on a replica node.

In the Management Console's monitor dashboard, the Cached Requests and Served Requests graphs, which are retrieved by the git fetch catching command, did not display metrics for the instance.

After a site administrator exempted the @github-actions[bot] user from rate limiting by using the ghe-config app.github.rate-limiting-exempt-users "github-actions[bot]" command, running ghe-config-check caused a Validation is-valid-characterset failed warning to appear.

GitHub Actions (actions) and Microsoft SQL (mssql) did not appear in the list of processes within the instances monitor dashboard.

In some cases, graphs on the Management Console's monitor dashboard failed to render.

On an instance in a high availability configuration, if an administrator tore down replication from a replica node using ghe-repl-teardown immediately after running ghe-repl-setup, but before ghe-repl-start, an error indicated that the script cannot launch /usr/local/bin/ghe-single-config-apply - run is locked. ghe-repl-teardown now displays an informational alert and continues the teardown.

After an administrator used the /setup/api/start REST API endpoint to upload a license, the configuration run failed with a Connection refused error during the migrations phase.

On an instance in a cluster configuration, when a site administrator set maintenance mode using ghe-maintenance -s, a Permission denied error appeared when the utility tried to access /data/user/common/cluster.conf.

During configuration of high availability, if a site administrator interrupted the ghe-repl-start utility, the utility erroneously reported that replication was configured, and the instance would not perform expected clean-up operations.

On instances configured to use the private beta of SCIM for GitHub Enterprise Server, users' authentication with SSH keys and personal access tokens failed due to an erroneous requirement for authorization.

After a user imported a repository with push protection enabled, the repository was not immediately visible in the security overview's "Security Coverage" view.

Responses from the /repositories REST API endpoint erroneously included deleted repositories.

When a site administrator used ghe-migrator to migrate data to GitHub Enterprise Server, in some cases, nested team relationships would not persist after teams were imported.

If a repository contained a CODEOWNERS file with check annotations, pull requests "Files changed" tab returned a 500 error and displayed "Oops, something went wrong" in the "Unchanged files with check annotations" section.

On an instance with GitHub Actions enabled, if a user manually triggered a workflow using the REST API but did not specify values for optional booleans, the API failed to validate the request and returned a 422 error.

The CSV reports for all users and all active users, available from the site admin dashboard, did not consider recent access using SSH or personal access tokens.

In some cases on an instance with multiple nodes, GitHub Enterprise Server erroneously stopped writing to replica fileservers, causing repository data to fall out of sync.

GitHub Enterprise Server published distribution metrics that cannot be processed by collectd. The metrics included pre_receive.lfsintegrity.dist.referenced_oids, pre_receive.lfsintegrity.dist.unknown_oids, and git.hooks.runtime.

On an instance with a GitHub Advanced Security license, if code scanning had been used while running GitHub Enterprise Server 3.4 or earlier, a subsequent upgrade from 3.5 to 3.6 or 3.7 could fail when attempting to add a unique index to a database table.

When the dependency submission API received a submission with one or more dependencies without a version, the dependency graph will now correctly report this fact.

To avoid a failure during a configuration run on a cluster, validation of cluster.conf with the ghe-cluster-config-check utility ensures that the consul-datacenter field for each nodes matches the top-level primary-datacenter field.

On an instance in a cluster configuration, when a site administrator sets maintenance mode on a single cluster node using ghe-maintenance -s, the utility warns the administrator to use ghe-cluster-maintenance -s to set maintenance mode on all of the clusters nodes. For more information, see "Включение и планирование режима обслуживания."

When a site administrator configures an outbound web proxy server for GitHub Enterprise Server, the instance now validates top-level domains (TLDs) excluded from the proxy configuration. By default, you can exclude public TLDs that the IANA specifies. Site administrators can specify a list of unregistered TLDs to exclude using ghe-config. The . prefix is required for any public TLDs. For example, .example.com is valid, but example.com is invalid. For more information, see "Настройка сервера веб-прокси исходящего трафика."

To avoid intermittent issues with the success of Git operations on an instance with multiple nodes, GitHub Enterprise Server checks the status of the MySQL container before attempting a SQL query. The timeout duration has also been reduced.

The default path for output from ghe-saml-mapping-csv -d is /data/user/tmp instead of /tmp. For more information, see "Служебные программы командной строки."

"HIGH: в GitHub Enterprise Server обнаружена уязвимость обхода пути, которая позволяла удаленно выполнять код при создании сайта GitHub Pages. Чтобы воспользоваться этой уязвимостью, злоумышленнику потребуется разрешение на создание и создание сайта GitHub Pages на экземпляре GitHub Enterprise Server. Об этой уязвимости сообщили в программе bounty для ошибок GitHub и назначили CVE-2023-23760.

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

В редких случаях, когда первичные сегменты для Elasticsearch были расположены на узле реплики, команда завершается ошибкой ghe-repl-stop с ERROR: Running migrations.

HIGH: обновлено Git, включающее исправления из версии 2.39.2, которые касались CVE-2023-22490 и CVE-2023-23946.

ВЫСОКИЙ УРОВЕНЬ. В GitHub Enterprise Server обнаружена уязвимость обхода пути, которая позволяла произвольно считывать файлы при создании сайта GitHub Pages. Чтобы воспользоваться этой уязвимостью, злоумышленнику потребуется разрешение на создание и создание сайта GitHub Pages в экземпляре . Эта уязвимость была обнаружена в рамках программы bounty для ошибок GitHub и назначена CVE-2023-22380.

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

При использовании URL-адреса конечной точки VPC в качестве URL-адреса AWS S3 для GitHub Packages публикация и установка пакетов завершилась сбоем.

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

Не удалось скачать CSV-файл, содержащий сведения о участниках GitHub Advanced Security, если у экземпляра нет лицензии на GitHub Advanced Security.

Размер собранных журналов может быстро увеличиваться из-за включения kredz.* метрик, которые не могут быть проанализированы с помощью StatsD и приводят к сообщениям об ошибках.

На экземпляре с лицензией GitHub Advanced Security, если при запуске GitHub Enterprise Server 3.4 или более ранней версии использовалось сканирование кода, последующее обновление с версии 3.5 до версии 3.6 или 3.7 может завершиться ошибкой при попытке добавить уникальный индекс в таблицу базы данных.

После того как REST API отправки зависимостей получит отправку с одной или несколькими зависимостями без версии, граф зависимостей будет правильно сообщать об этом факте.

MEDIUM: в GitHub Enterprise Server была обнаружена уязвимость внедрения кода, которая позволяла задавать произвольные переменные среды из одного значения переменной среды в GitHub Actions при использовании средства выполнения на основе Windows из-за неправильной очистки null байтов. Чтобы воспользоваться этой уязвимостью, злоумышленнику потребуется существующее разрешение на управление значением переменных среды для использования с GitHub Actions. Об этой уязвимости сообщили в программе bounty для ошибок GitHub и назначили CVE-2023-22381.

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

После того как администратор сайта настроил дату отсечения для разрешения SSH-соединений с ключами RSA с помощью ghe-config app.gitauth.rsa-sha1, экземпляр по-прежнему будет запрещать подключения с ключами RSA, если попытка подключения была подписана хэш-функцией SHA-1.

На этапе проверки запуска No such object error конфигурации для служб "Записная книжка" и "Экран просмотра" может возникнуть исключение .

После отключения обновлений Dependabot аватар для Dependabot отображался как @ghost пользователь на временной шкале оповещений Dependabot.

В некоторых случаях пользователи могут столкнуться с ошибкой 500 при просмотре страницы параметров анализа & безопасности кода для экземпляра с очень большим количеством активных фиксаций.

Некоторые ссылки на обращение в службу поддержки GitHub или просмотр заметок о выпуске GitHub Enterprise Server были неверными.

Число дополнительных фиксаций для GitHub Advanced Security всегда показывало 0.

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

HIGH: обновлен Git для включения исправлений с версии 2.39.1, которая относится к CVE-2022-41903 и CVE-2022-23521.

Очистка дополнительных секретов в пакетах поддержки и журнале конфигурации.

Зависимости для действия CodeQL обновлены до последних версий безопасности.

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

Некоторые службы неправильно подключались непосредственно к kafka-lite, а не через внутренний прокси-сервер. В кластерной среде, где веб-службы и службы заданий выполняются на отдельных узлах, сообщения, созданные из службы заданий Insights, не были доставлены в kafka-lite.

Метрики Active workers и Queued requests для github служб контейнеров (переименованных из метаданных), gitauthи unicorn служб контейнеров неправильно считывались из собранных и отображались в консоли управления.

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

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

Сортировка и фильтрация списка пользовательских шаблонов для проверки секретов на уровне организации работала неправильно.

После обновления до GitHub Enterprise Server 3.7 просмотр страницы параметров безопасности для организации или репозитория может привести к ошибке 500 из-за того, что задание GitHub Advanced Security обратного заполнения не завершено до начала обновления.

Команде git-janitorне удалось исправить устаревшие multi-pack-index.lock файлы, что привело к сбою обслуживания репозитория.

Удаленные launch.* метрики, которые не могут быть проанализированы statsd, так как результирующие ошибки статистики привели к быстрому росту размера собранных журналов.

При обновлении пользовательских шаблонов для состояния шаблона немедленно устанавливается значение Опубликовано.

Повышена надежность службы обновлений в режиме реального времени (в режиме реального времени), чтобы сделать ее более устойчивой к сетевым проблемам с Redis.

Команды ghe-support-bundle и ghe-cluster-support-bundle были обновлены, чтобы включить -p/--period флаг для создания пакета поддержки с ограниченным временем. Длительность может быть указана в днях и часах, например , -p '2 hours'``-p '1 day', -p '2 days 5 hours'.

При обновлении экземпляра с новым корневым разделом выполнение ghe-upgrade команды с параметром -t/--target гарантирует выполнение предварительной проверки минимального размера дискового хранилища для целевого раздела.

Повышена производительность запусков конфигурации, запущенных с ghe-config-apply помощью .

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

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

Настраиваемые правила брандмауэра удаляются в процессе обновления.

Отслеживаемые файлы Git LFS, отправленные через веб-интерфейс , неправильно добавляются непосредственно в репозиторий.

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

Если в GitHub Connect включен параметр "Пользователи могут искать GitHub.com", проблемы в частных и внутренних репозиториях не включаются в результаты поиска GitHub.com.

Реестр npm GitHub Packages больше не возвращает значение времени в ответах метаданных. Это было сделано для существенного повышения производительности. Мы по-прежнему имеем все данные, необходимые для возврата значения времени в ответе метаданных, и возобновим возврат этого значения в будущем после устранения существующих проблем с производительностью.

Ограничения ресурсов, относящиеся к обработке перехватчиков предварительного получения, могут привести к сбою некоторых перехватчиков предварительного получения.

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

В параметрах репозитория включение параметра разрешить пользователям с доступом на чтение создавать обсуждения не включает эту функцию.

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

На этапе проверки запуска No such object конфигурации может возникнуть ошибка для служб "Записная книжка" и "Экран просмотра". Эту ошибку можно игнорировать, так как службы по-прежнему должны правильно запускаться.

После обновления до GitHub Enterprise Server 3.6 или более поздней версии существующие несоответствия в репозитории, такие как неработающие ссылки или отсутствующие объекты, теперь могут сообщаться как ошибки, такие как invalid sha1 pointer 0000000000000000000000000000000000000000, Zero-length loose reference fileили Zero-length loose object file. Ранее эти индикаторы повреждения репозитория могли игнорироваться без уведомления. GitHub Enterprise Server теперь использует обновленную версию Git с включенной более тщательной отчетностью об ошибках. Дополнительные сведения см. в этой вышестоящей фиксации в проекте Git.

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

Экземпляры, испытывающие большое количество одновременных запросов Git, могут испытывать проблемы с производительностью. Если вы подозреваете, что эта проблема влияет на ваш экземпляр, обратитесь в Поддержка GitHub. Дополнительные сведения см. в разделе Создание запроса в службу поддержки. [Обновлено: 07.12.2022]

На экземплярах в конфигурации git push с высоким уровнем доступности операции могут завершиться ошибкой в следующих ситуациях. [Обновлено: 17.03.2023]

• Во время создания репозитория на узле реплики
• После сбоя при создании репозитория на узле реплики перед автоматическим восстановлением репозитория

На экземплярах в конфигурации с высоким уровнем доступности администраторы сайта должны выполнять ghe-repl-start команды и ghe-repl-stop только в то время, когда экземпляр находится в режиме обслуживания. Дополнительные сведения см. в разделах Включение и планирование режима обслуживания и Сведения о настройке высокого уровня доступности. [Обновлено: 17.03.2023]

ВЫСОКИЙ УРОВЕНЬ. В GitHub Enterprise Server была обнаружена уязвимость обхода пути, которая позволяла удаленно выполнять код при создании сайта GitHub Pages. Чтобы воспользоваться этой уязвимостью, злоумышленнику потребуется разрешение на создание и создание сайта GitHub Pages в экземпляре . Об этой уязвимости сообщили в программе GitHub Побоям за ошибки и назначили CVE-2022-46256.

Состояние гонки заблокировало обновление до GitHub Enterprise Server 3.6 или более поздней версии, пока администратор сайта не повторил обновление.

Когда администратор сайта выполнял ghe-repl-status команду в реплике кэша через административную оболочку (SSH), команда неправильно сообщила общие сведения о состоянии репликации Git и кластера Alambic, как если бы они относятся только к репликации кэша.

Когда администратор сайта выполнял ghe-repl-sync-ca-certificates команду из первичного узла экземпляров через административную оболочку (SSH), эта команда реплицировала сертификаты ЦС только из первичного узла экземпляров в один узел реплики. Команда не реплицировала сертификаты на все доступные узлы реплики.

В конфигурации с высоким уровнем доступности после повышения роли реплики в качестве основного узла администратор сайта не может принудительно остановить репликацию на узле вторичной реплики ghe-repl-stop -f с помощью команды .

При использовании кэширования репозитория с экземпляром в конфигурации с высоким уровнем доступности, если клиент Git использовал SSH вместо HTTPS для удаленного URL-адреса репозитория, Git LFS будет извлечь объекты из первичного узла экземпляров вместо соответствующего узла реплики кэша.

Установка GitHub Enterprise Server на низкоуровневой оболочке VMware ESXi завершилась сбоем из-за создания OVA-файла с недопустимым значением емкости.

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

В некоторых случаях поиск через API возвращал ошибку 500 .

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

В некоторых случаях страница настройки сканирования кода ошибочно сообщает, что GitHub Actions не настроен для экземпляра.

Закрытие оповещения Dependabot, содержащего определенные символы, может привести к ошибке 400 .

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

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

Обновление GitHub Enterprise Server 3.5 до версии 3.7 может завершиться ошибкой, так как экземпляр еще не очистил удаленные репозитории.

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

Исправлена ошибка, из-за которой файл журнала GHES мог заполниться очень быстро, что приводит к тому, что корневой диск не имеет свободного места.

При просмотре результатов сканирования кода для Ruby появилась ошибочная метка бета-версии.

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

Список недавно доступных репозиториев пользователя больше не включает удаленные репозитории.

Для участников частной бета-версии SCIM для GitHub Enterprise Server теперь поддерживаются пользовательские сопоставления атрибутов пользователя SAML. Пользовательские сопоставления позволяют использовать значение, отличное NameID от уникального идентифицирующего утверждения, во время проверки подлинности SAML. Дополнительные сведения см. в разделе Настройка подготовки пользователей с помощью SCIM для вашего предприятия. [Обновлено: 27.02.2023]

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

Настраиваемые правила брандмауэра удаляются в процессе обновления.

Отслеживаемые файлы Git LFS, отправленные через веб-интерфейс , неправильно добавляются непосредственно в репозиторий.

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

Если в GitHub Connect включен параметр "Пользователи могут искать GitHub.com", проблемы в частных и внутренних репозиториях не включаются в результаты поиска GitHub.com.

Реестр npm GitHub Packages больше не возвращает значение времени в ответах метаданных. Это было сделано для существенного повышения производительности. Мы по-прежнему имеем все данные, необходимые для возврата значения времени в ответе метаданных, и возобновим возврат этого значения в будущем после устранения существующих проблем с производительностью.

Ограничения ресурсов, относящиеся к обработке перехватчиков предварительного получения, могут привести к сбою некоторых перехватчиков предварительного получения.

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

В параметрах репозитория включение параметра разрешить пользователям с доступом на чтение создавать обсуждения не включает эту функцию.

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

На этапе проверки запуска No such object конфигурации может возникнуть ошибка для служб "Записная книжка" и "Экран просмотра". Эту ошибку можно игнорировать, так как службы по-прежнему должны правильно запускаться.

После обновления до GitHub Enterprise Server 3.6 или более поздней версии существующие несоответствия в репозитории, такие как неработающие ссылки или отсутствующие объекты, теперь могут сообщаться как ошибки, такие как invalid sha1 pointer 0000000000000000000000000000000000000000, Zero-length loose reference fileили Zero-length loose object file. Ранее эти индикаторы повреждения репозитория могли игнорироваться без уведомления. GitHub Enterprise Server теперь использует обновленную версию Git с включенной более тщательной отчетностью об ошибках. Дополнительные сведения см. в этой вышестоящей фиксации в проекте Git.

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

Экземпляры, испытывающие большое количество одновременных запросов Git, могут испытывать проблемы с производительностью. Если вы подозреваете, что эта проблема влияет на ваш экземпляр, обратитесь в Поддержка GitHub. Дополнительные сведения см. в разделе Создание запроса в службу поддержки. [Обновлено: 07.12.2022]

При проверке параметров домена в экземпляре с включенным протоколом TLS и изоляцией поддомена консоль управления не отображает два новых поддомена GitHub Enterprise Server 3.7 и http(s)://notebooks.HOSTNAME http(s)://viewscreen.HOSTNAMEв списке доменов. [Обновлено: 12.01.2023]

Для участников частной бета-версии SCIM для GitHub Enterprise Server проверка подлинности для запросов к ресурсам, отличных от REST API, с помощью personal access token или ключа SSH может не выполниться. Исправление будет доступно в предстоящем выпуске GitHub Enterprise Server. [Обновлено: 27.02.2023]

На экземплярах в конфигурации git push с высоким уровнем доступности операции могут завершиться ошибкой в следующих ситуациях. [Обновлено: 17.03.2023]

• Во время создания репозитория на узле реплики
• После сбоя при создании репозитория на узле реплики перед автоматическим восстановлением репозитория

На экземплярах в конфигурации с высоким уровнем доступности администраторы сайта должны выполнять ghe-repl-start команды и ghe-repl-stop только в то время, когда экземпляр находится в режиме обслуживания. Дополнительные сведения см. в разделах Включение и планирование режима обслуживания и Сведения о настройке высокого уровня доступности. [Обновлено: 17.03.2023]

ВЫСОКИЙ: в GitHub Enterprise Server обнаружена неправильная нейтрализация разделителей аргументов в уязвимости команды, которая включила удаленное выполнение кода. Чтобы воспользоваться этой уязвимостью, злоумышленнику потребуется разрешение на создание и сборку страниц GitHub с помощью GitHub Actions. Эта ошибка была первоначально зарегистрирована в программе GitHub Bug Bounty и назначена CVE-2022-23740. [Обновлено: 02.12.2022]

HIGH: в Pages была добавлена проверка, чтобы убедиться, что рабочий каталог очищен перед распаковкой нового содержимого, чтобы предотвратить ошибку произвольной перезаписи файла. Эта уязвимость была назначена CVE-2022-46255.

MEDIUM: обновлен CommonMarker для решения сценария, в котором параллельные запросы к REST API Markdown могут привести к неограниченному исчерпанию ресурсов. Эта уязвимость была назначена CVE-2022-39209.

MEDIUM. Маркеры пользователя на сервере с заданной областью из приложений GitHub могут обходить проверки авторизации в запросах API GraphQL при доступе к ресурсам, не относящихся к репозиторию. Эта уязвимость была обнаружена в рамках программы GitHub bug Bounty Program и назначена CVE-2022-23739.

MEDIUM: ссылки предварительного просмотра запросов на вытягивание неправильно очищают URL-адреса, что позволяет злоумышленнику внедрять опасные ссылки в веб-интерфейс экземпляров. Об этой уязвимости сообщили в программе GitHub Bug Bounty.

Если зависимость GitHub Actions использует закрепленную версию SHA, Dependabot больше не будет помечать зависимость как уязвимую.

ghe-spokesctl Выполнение команды вернуло ошибкуfailed to get repo metrics.

Установка режима обслуживания со списком исключений IP-адресов не будет сохраняться при обновлениях.

Для сборок GitHub Pages может быть истекло время ожидания для экземпляров в AWS, настроенных для обеспечения высокого уровня доступности.

Сведения о состоянии репликации объектов Git LFS на узлы реплик кэша репозитория не отображались в ghe-repl-status выходных данных на этих узлах.

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

При доступе к ресурсам JavaScript экземпляров из-за прокси-сервера в браузере отображаются ошибки общего доступа к ресурсам независимо от источника (CORS).

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

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

В некоторых случаях экземпляр может заменить активный репозиторий удаленным репозиторием.

Объекты LFS Git в репозитории с политикой репликации кэша не копируются в реплики кэша, если общее количество объектов в репозитории превышает 5000.

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

Зомби-процессы больше не накапливаются в контейнере gitrpcd .

В экземпляре с настроенными пакетами GitHub отправка и установка пакетов могут завершиться ошибкой для клиентов, использующих URL-адрес конечной точки VPC для хранилища BLOB-объектов AWS S3.

В некоторых случаях после обновления до GitHub Enterprise Server 3.7.0 пользователи могут столкнуться с Internal Server Error ошибками при 500 запуске операций Git по протоколу SSH или HTTPS.

Если администратор сайта еще не настроил GitHub Actions для экземпляра, пользовательский интерфейс для настройки проверки кода предложит пользователю настроить GitHub Actions.

Чтобы избежать неудачной проверки домена из-за ограничения в 63 символа, применяемого поставщиками DNS для записей DNS, созданная TXT GitHub запись для проверки владения доменом теперь ограничена 63 символами.

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

Пользовательские правила брандмауэра удаляются в процессе обновления.

Отслеживаемые файлы GIT LFS , отправленные через веб-интерфейс , неправильно добавляются непосредственно в репозиторий.

Проблемы невозможно закрыть, если они содержат ссылку на большой двоичный объект в том же репозитории, где путь к файлу большого двоичного объекта превышает 255 символов.

Если в GitHub Connect включен параметр "Пользователи могут искать GitHub.com", проблемы в частных и внутренних репозиториях не включаются в результаты поиска GitHub.com.

Реестр npm GitHub Packages больше не возвращает значение времени в ответах метаданных. Это было сделано для существенного улучшения производительности. Мы по-прежнему имеем все данные, необходимые для возврата значения времени в ответе метаданных, и возобновим возврат этого значения в будущем, как только мы устраним существующие проблемы с производительностью.

Ограничения ресурсов, относящиеся к обработке перехватчиков предварительного получения, могут привести к сбою некоторых перехватчиков предварительного получения.

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

В параметрах репозитория включение параметра разрешить пользователям с доступом на чтение создавать обсуждения не включает эту функцию.

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

На этапе проверки запуска No such object конфигурации может возникнуть ошибка для служб "Записная книжка" и "Экран просмотра". Эту ошибку можно игнорировать, так как службы по-прежнему должны правильно запускаться.

После обновления до GitHub Enterprise Server 3.6 или более поздней версии существующие несоответствия в репозитории, такие как неработающие ссылки или отсутствующие объекты, теперь могут сообщаться как ошибки, такие как invalid sha1 pointer 0000000000000000000000000000000000000000, Zero-length loose reference fileили Zero-length loose object file. Ранее эти индикаторы повреждения репозитория могли игнорироваться без уведомления. GitHub Enterprise Server теперь использует обновленную версию Git с включенной более тщательной отчетностью об ошибках. Дополнительные сведения см. в этой вышестоящей фиксации в проекте Git.

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

Экземпляры, испытывающие большое количество одновременных запросов Git, могут испытывать проблемы с производительностью. Если вы подозреваете, что эта проблема влияет на ваш экземпляр, обратитесь в Поддержка GitHub. Дополнительные сведения см. в разделе Создание запроса в службу поддержки. [Обновлено: 07.12.2022]

При проверке параметров домена в экземпляре с включенным протоколом TLS и изоляцией поддомена консоль управления не отображает два новых поддомена GitHub Enterprise Server 3.7 и http(s)://notebooks.HOSTNAME http(s)://viewscreen.HOSTNAMEв списке доменов. [Обновлено: 12.01.2023]

На экземплярах в конфигурации git push с высоким уровнем доступности операции могут завершиться ошибкой в следующих ситуациях. [Обновлено: 17.03.2023]

• Во время создания репозитория на узле реплики
• После сбоя при создании репозитория на узле реплики перед автоматическим восстановлением репозитория

На экземплярах в конфигурации с высоким уровнем доступности администраторы сайта должны выполнять ghe-repl-start команды и ghe-repl-stop только в то время, когда экземпляр находится в режиме обслуживания. Дополнительные сведения см. в разделах Включение и планирование режима обслуживания и Сведения о настройке высокого уровня доступности. [Обновлено: 17.03.2023]

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

Минимальные требования к паролю для консоли управления являются более строгими.

Попытки проверки подлинности в консоли управления и изменения, внесенные администратором сайта в консоли управления, записываются в файл журнала в /var/log/enterprise-manage/audit.log.

Azure Maps заменяет MapBox для отрисовки файлов GeoJSON в виде графических карт. Администраторы могут включить отрисовку карты и предоставить маркер Azure Maps в консоли управления. Дополнительные сведения см. в разделе Администрирование экземпляра из консоли управления.

Пользователи могут проверять фиксации с помощью открытого ключа SSH. Дополнительные сведения см. в разделе Сведения о проверке сигнатуры фиксации.

Администраторы сайта могут автоматически подготавливать пользователей и группы в экземпляре GitHub Enterprise Server с помощью SCIM. SCIM для GitHub Enterprise Server находится в закрытой бета-версии и может быть изменен. Дополнительные сведения см. в разделах Настройка подготовки пользователей с помощью SCIM для вашего предприятия и SCIM документации по REST API.

Пользователи экземпляра с лицензией на GitHub Advanced Security могут просматривать оповещения о сканировании кода и комментировать их в своем репозитории на вкладке Беседа запроса на вытягивание. Если для репозитория включено правило Требовать разрешение диалога перед слиянием защиты ветви, все комментарии к этим оповещениям проверки кода должны быть разрешены, прежде чем пользователь объединит запрос на вытягивание. Дополнительные сведения см. в разделах Сведения о проверке кода, Сведения о проверках запросов на вытягивание и Сведения о защищенных ветвях.

Чтобы упростить развертывание проверки секретов для экземпляров с десятками, сотнями или даже тысячами организаций, владельцы предприятия на экземпляре с лицензией на GitHub Advanced Security могут включить проверку секретов и защиту от отправки для экземпляра с помощью веб-интерфейса. Дополнительные сведения см. в разделе Управление функциями GitHub Advanced Security для предприятия.

Владельцы организации на экземпляре с лицензией на GitHub Advanced Security могут выполнять пробное выполнение пользовательских шаблонов для проверки секретов для всех репозиториев в организации. Дополнительные сведения см. в разделе Определение пользовательских шаблонов для сканирования секретов.

Если администратор сайта включил уведомления по электронной почте для экземпляра с лицензией на GitHub Advanced Security, пользователи, просматривающие оповещения о проверке секретов репозитория, получат уведомление по электронной почте, когда участник обходит секрет, заблокированный защитой push-уведомлений. Ранее уведомления не отправлялись, если секрет был помечен как ложноположительный или использовался в тестах. Дополнительные сведения см. в разделах Защита push-уведомлений с помощью проверки секретов и Настройка электронной почты для уведомлений.

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

Пользователи экземпляра с лицензией на GitHub Advanced Security, которые защищают отправки с помощью проверки секретов, могут указать пользовательскую ссылку, которая будет отображаться в сообщении об ошибке, когда защита от отправки обнаруживает и блокирует потенциальный секрет. Дополнительные сведения см. в разделе Защита push-уведомлений с помощью сканирования секретов.

Пользователи могут публиковать пакеты CodeQL в реестре контейнеров. Дополнительные сведения см. в разделе Создание пакетов CodeQL и работа с ними в документации по CodeQL CLI.

Пользователи экземпляра с лицензией GitHub Advanced Security могут использовать пакеты CodeQL с проверкой кода, включая пакеты, опубликованные в реестре контейнеров GitHub экземпляра. Дополнительные сведения см. в разделах Настройка сканирования кода и Публикация и использование пакетов CodeQL в документации по CodeQL CLI.

Пользователи экземпляра с лицензией GitHub Advanced Security могут исключить ненужные запросы CodeQL для сканирования кода с помощью фильтров запросов. Дополнительные сведения см. в статье Настройка сканирования кода для Управляемого экземпляра Базы данных SQL Azure.

Владельцы предприятия на экземпляре с лицензией GitHub Advanced Security могут получать результаты проверки кода для всего экземпляра с помощью REST API. Новая конечная точка дополняет существующие конечные точки для репозиториев и организаций. Дополнительные сведения см. в разделе "Проверка кода" в документации по REST API.

Владельцы организации на экземпляре с лицензией GitHub Advanced Security могут получить состояние включения или настроить автоматическое включение следующих функций с помощью REST API.

• GitHub Advanced Security
• Сканирование секретов
• Защита от отправки

Дополнительные сведения см. в разделе "Организации" в документации по REST API.

Пользователи экземпляра с лицензией на GitHub Advanced Security могут использовать курсоры для разбивки на страницы результатов оповещений о сканировании секретов, полученных с помощью конечных точек организации и репозитория REST API. Дополнительные сведения см. в разделе "Проверка секретов" в документации по REST API.

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

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

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

Пользователи могут отсортировать оповещения Dependabot по области зависимости, среды выполнения или разработки.

При необходимости пользователи могут добавить комментарий при закрытии оповещения Dependabot. Комментарии к закрытию отображаются на временной шкале dismissComment событий и в поле объекта API RepositoryVulnerabilityAlert GraphQL. Дополнительные сведения об API GraphQL см. в разделе Объекты документации по API GraphQL.

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

Владельцы организации в экземпляре могут получить состояние включения или настроить автоматическое включение следующих функций для управления зависимостями с помощью REST API.

• Граф зависимостей
• Оповещения Dependabot
• Обновления для системы безопасности Dependabot

Дополнительные сведения см. в разделе "Организации" в документации по REST API.

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

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

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

• В базе данных отображаются рекомендации для Elixir, диспетчера hex-пакетов Erlang и многого другого.
• Пользователи могут найти рекомендации по вредоносным программам, выполнив поиск по запросу type:malware.
• В базе данных отображаются рекомендации по GitHub Actions уязвимостям.

Дополнительные сведения см. в разделе Обзор рекомендаций по безопасности в базе данных рекомендаций GitHub.

Пользователи могут заполнить граф зависимостей репозитория, отправив зависимости для репозитория с помощью REST API. Граф зависимостей обеспечивает оповещения Dependabot и обновления безопасности Dependabot. Дополнительные сведения см. в разделе Использование API отправки зависимостей.

GitHub Actions поддерживает Google Cloud Storage в качестве поставщика хранилища для журналов, артефактов и кэшей. Дополнительные сведения см. в разделе Включение GitHub Actions с помощью Google Cloud Storage.

GitHub Actions пользователи, использующие кэширование зависимостей для ускорения рабочих процессов, теперь могут использовать GitHub CLI для управления кэшем GitHub Actions для репозитория. Чтобы управлять кэшами с помощью GitHub CLI, установите gh-actions-cache расширение . Дополнительные сведения см. в документацииgh-actions-cache.

Рабочий процесс повторно запускается в GitHub Actions использует субъект, который изначально активировал рабочий процесс для оценки привилегий. Субъект, который активировал повторный запуск, будет по-прежнему отображаться в пользовательском интерфейсе и может быть доступны в рабочем процессе через triggering_actor поле в контексте github . Дополнительные сведения см. в разделах "Повторное выполнение рабочих процессов и заданий" и "Контексты".

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

При запросе GitHub Actions артефактов REST API возвращает сведения о выполнении и ветви, которые создали артефакт. Дополнительные сведения см. в разделе GitHub Actions Артефакты в документации по REST API.

Для поддержки безопасных облачных развертываний в большом масштабе владельцы организации и администраторы репозитория могут выполнять следующие задачи с помощью REST API OpenID Connect. Дополнительные сведения см. в разделе "GitHub Actions OIDC" в документации по REST API.

• Включите стандартную конфигурацию OpenID Connect в рабочих процессах развертывания облака, настроив subject формат утверждения.
• Обеспечьте дополнительное соответствие требованиям и безопасность для развертываний OpenID Connect, добавив issuer URL-адрес с помощью корпоративного slug.
• Настройте дополнительные политики OpenID Connect с помощью дополнительных утверждений токена OpenID Connect, таких как repository_id и repo_visibility.

Дополнительные сведения см. в статье Сведения об усилении защиты с помощью OpenID Connect.

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

• Вывод списка всех кэшей в репозитории и сортировки по метаданным.
• Удаление поврежденной или устаревшей записи кэша. Дополнительные сведения см. в разделах Кэширование зависимостей для ускорения рабочих процессов и Кэш GitHub Actions в документации по REST API.

Если неэфемерное локальное средство выполнения GitHub Actions не взаимодействует с экземпляром GitHub Enterprise Server более 14 дней, экземпляр автоматически удалит средство выполнения. Если эфемерное локальное средство выполнения тестов не взаимодействует с экземпляром в течение более одного дня, экземпляр автоматически удалит средство выполнения. Ранее GitHub Enterprise Server удалил средства выполнения через 30 дней. Дополнительные сведения см. в статье "Сведения о локально размещенных средствах выполнения."

GitHub Actions могут запускать локальные рабочие процессы macOS в среде выполнения macOS ARM64 с поддержкой средства выполнения для Apple Silicon, например микросхемы M1 или M2. Дополнительные сведения см. в разделе Использование локальных средств выполнения тестов в рабочем процессе.

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

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

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

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

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

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

Когда пользователь переименовывает или перемещает файл в новый каталог, если по крайней мере половина содержимого файла идентична, журнал фиксаций указывает на то, что файл был переименован, аналогично git log --follow. Дополнительные сведения см. в блоге GitHub. [Обновлено: 10.02.2023]

Внесены улучшения в создание вилок и управление ими.

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

Дополнительные сведения см. в разделе Создание вилки репозитория.

Администраторы репозитория могут блокировать создание ветвей, соответствующих заданному шаблону имени, с помощью правила защиты "Ограничить отправки, создающие соответствующие ветви ". Например, если ветвь репозитория по умолчанию изменяется с master на main, администратор репозитория может запретить любое последующее создание или отправку master ветви. Дополнительные сведения см. в разделах Сведения о защищенных ветвях и Управление правилом защиты ветвей.

Пользователи могут создавать файлы со схемами geoJSON, topoJSON и STL, а также отображать схемы в веб-интерфейсе. Дополнительные сведения см. в статье Работа с файлами, не связанными с кодом.

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

Пользователи могут настраивать исключения в средстве поиска файлов, например vendor/ и build/ , используя linguist атрибуты в .gitattributes файле. Дополнительные сведения см. в разделах Поиск файлов на GitHub и Настройка отображения измененных файлов в GitHub.

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

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

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

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

• Примечание. Эта функция недоступна в GitHub Enterprise Server 3.7. Функция будет доступна в будущем выпуске. [Обновлено: 16.11.2022]

Пользователи могут визуализировать карты непосредственно в Markdown, используя блоки кода с ограждением с синтаксисом geojson или topojson , а также внедрять трехмерные отрисовки STL с помощью stl синтаксиса. Дополнительные сведения см. в разделе Создание схем.

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

Для повышения стабильности была заменена служба для отрисовки GeoJSON, Jupyter Notebook, PDF, PSD, SVG, SolidWorks и других двоичных форматов.

Если для экземпляра настроена изоляция TLS и поддомена, а сертификат не является подстановочным сертификатом, необходимо создать новый сертификат, включающий дополнительные поддомены для этих служб, notebooks.HOSTNAME и viewscreen.HOSTNAME. Дополнительные сведения см. в разделе Включение изоляции поддомена. [Обновлено: 02.12.2022]

Сканирование секретов больше не поддерживает пользовательские шаблоны, которые используются .* в качестве разделителя конца в поле "После секрета", так как синтаксис шаблона может вызвать проблемы и несоответствия при сканировании.

При создании нового выпуска пользователи теперь могут отправить форму с помощью клавиш CTRL + ВВОД в macOS или CTRL + ВВОД в Windows или Linux.

Вкладка вики-сайта в репозитории отображается только при наличии вики-сайта. Ранее вкладка всегда отображалась.

Отрисованные вики-сайты отображают математические выражения и схемы Mermaid.

Увеличен размер поля поиска для журналов аудита пользователей, организаций и предприятий.

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

Пользовательские правила брандмауэра удаляются в процессе обновления.

Отслеживаемые файлы GIT LFS , отправленные через веб-интерфейс , неправильно добавляются непосредственно в репозиторий.

Проблемы невозможно закрыть, если они содержат ссылку на большой двоичный объект в том же репозитории, где путь к файлу большого двоичного объекта превышает 255 символов.

Если в GitHub Connect включен параметр "Пользователи могут искать GitHub.com", проблемы в частных и внутренних репозиториях не включаются в результаты поиска GitHub.com.

Реестр npm GitHub Packages больше не возвращает значение времени в ответах метаданных. Это было сделано для существенного улучшения производительности. Мы по-прежнему имеем все данные, необходимые для возврата значения времени в ответе метаданных, и возобновим возврат этого значения в будущем, как только мы устраним существующие проблемы с производительностью.

Ограничения ресурсов, относящиеся к обработке перехватчиков предварительного получения, могут привести к сбою некоторых перехватчиков предварительного получения.

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

В параметрах репозитория включение параметра разрешить пользователям с доступом на чтение создавать обсуждения не включает эту функцию.

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

На этапе проверки запуска No such object конфигурации может возникнуть ошибка для служб "Записная книжка" и "Экран просмотра". Эту ошибку можно игнорировать, так как службы по-прежнему должны правильно запускаться.

В некоторых случаях после обновления до GitHub Enterprise Server 3.7.0 пользователи могут столкнуться с Internal Server Error ошибками при 500 инициации git операций по протоколу SSH или HTTPS. Пример

git push origin master
Total 0 (delta 0), reused 0 (delta 0)
remote: Internal Server Error
To ghes.hostname.com:User/repo.git
! [remote rejected]       master -> master (Internal Server Error)

Если они возникают, обратитесь в службу поддержки GitHub Enterprise с пакетом поддержки. Известный временный обходной путь на данный момент — перезапустить github-gitauth службу с помощью следующих команд:

nomad stop github-gitauth
nomad run /etc/nomad-jobs/github/gitauth.hcl
nomad status github-gitauth

В настоящее время мы изучаем постоянное исправление для будущего горячего исправления [обновлено: 24.11.2022].

Экземпляры, испытывающие большое количество одновременных запросов Git, могут испытывать проблемы с производительностью. Если вы подозреваете, что эта проблема влияет на ваш экземпляр, обратитесь в Поддержка GitHub. Дополнительные сведения см. в разделе Создание запроса в службу поддержки. [Обновлено: 07.12.2022]

При проверке параметров домена в экземпляре с включенным протоколом TLS и изоляцией поддомена консоль управления не отображает два новых поддомена GitHub Enterprise Server 3.7 и http(s)://notebooks.HOSTNAME http(s)://viewscreen.HOSTNAMEв списке доменов. [Обновлено: 12.01.2023]

На экземплярах в конфигурации git push с высоким уровнем доступности операции могут завершиться ошибкой в следующих ситуациях. [Обновлено: 17.03.2023]

• Во время создания репозитория на узле реплики
• После сбоя при создании репозитория на узле реплики перед автоматическим восстановлением репозитория

На экземплярах в конфигурации с высоким уровнем доступности администраторы сайта должны выполнять ghe-repl-start команды и ghe-repl-stop только в то время, когда экземпляр находится в режиме обслуживания. Дополнительные сведения см. в разделах Включение и планирование режима обслуживания и Сведения о настройке высокого уровня доступности. [Обновлено: 17.03.2023]