Enterprise Server 3.8 release notes

MEDIUM: Scoped installation tokens for a GitHub App kept approved permissions after the permissions on the integration installation were downgraded or removed. GitHub has requested CVE ID CVE-2023-23765 for this vulnerability, which was reported via the GitHub Bug Bounty program.

Packages have been updated to the latest security versions.

On an instance in a cluster configuration, when upgrading the MySQL master node, the post-upgrade configuration run would take 600 seconds longer than required due to incorrect detection of unhealthy nodes.

On an instance with a GitHub Advanced Security license and secret scanning enabled, rotation of the key used to encrypt secrets discovered by secret scanning would fail.

In some situations on an instance with multiple nodes, Git replication failed to fully replicate repositories that had previously been deleted, which resulted in a warning in ghe-repl-status output.

If a user made a request to the Collaborators API's Add a repository collaborator endpoint specifying a permission of read or write, the instance returned a 500 error.

On an instance with the dependency graph enabled, the correct path appears for manifests that originate from build-time submission snapshots.

The spokesctl command-line utility accepts more input formats.

People with administrative SSH access to an instance can configure the maximum memory usage in gigabytes for Redis using ghe-config redis.max-memory-gb VALUE.

MEDIUM: обновлен Git для включения исправлений с версии 2.40.1. Дополнительные сведения см. в статье Об уязвимостях безопасности Git, объявленных в блоге GitHub.

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

Администратору сайта не удалось обойти прокси-сервер для домена верхнего уровня (TLD) из списка исключений экземпляра или зарегистрированных доменов верхнего уровня (TLD).

На некоторых платформах после запуска ghe-diagnosticsпользователя с административным доступом по протоколу SSH выходные данные команды содержали косметическую SG_IO ошибку.

Когда администратор сайта использовал GitHub Enterprise Importer для импорта данных из GitHub Enterprise Cloud, миграция завершилась сбоем во время импорта комментариев на уровне файла. Этот сбой больше не препятствует выполнению импорта.

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

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

Начиная с GitHub Enterprise Server 3.8 с помощью интерфейса командной строки GitHub Enterprise Importer, startRepositoryMigration API GraphQL или REST API "Начать миграцию организации" требуется настроить поставщика хранилища BLOB-объектов в консоли управления. При использовании Хранилище BLOB-объектов Azure контейнеры хранилища были неправильно настроены как общедоступные. Хранилище BLOB-объектов Azure контейнеры теперь будут настроены как частные, и мы представили проверка, которая явно не выполняет экспорт, если контейнер хранилища является общедоступным.

Когда администратор сайта использовал GitHub Enterprise Importer, импорт репозитория завершился ошибкой, если столбец проекта в репозитории содержал 2500 или более архивных карточек.

В некоторых ситуациях на экземпляре с несколькими узлами репликация Git не смогла полностью реплицировать ранее удаленные репозитории, что привело к выводу предупреждения в выходных ghe-repl-status данных.

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

GitHub Enterprise Server опубликовал метрики распределения, которые не могут быть обработаны сбором. Метрики включали pre_receive.lfsintegrity.dist.referenced_oids, pre_receive.lfsintegrity.dist.unknown_oidsи git.hooks.runtime.

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

На экземпляре с лицензией GitHub Advanced Security, которая также была настроена для часового пояса больше UTC, в списке оповещений сканирования секретов отображается ошибка "Сбой загрузки секретов", если пользователь отсортировал секреты по дате в порядке убывания.

На экземпляре с лицензией GitHub Advanced Security, где включено сканирование секретов, чрезмерное ведение журнала /var/log может привести к ошибкам пользователей и снижению производительности системы, если журналы занимают все свободное место на томе.

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

Люди с административным доступом по протоколу SSH, создающие пакет поддержки с помощью ghe-support-bundle служебных программ или ghe-cluster-support-bundle , могут указать период времени для сбора данных с -p использованием пробелов или --period кавычек или без него. Например, в дополнение к '-p 5 days' или -p '4 days 10 hours'допустимы или -p 4days10hours . -p 5days

После того как администратор сайта экспортирует архив миграции с помощью служебной программы GitHub Enterprise Importers gh-migrator , ссылка на архив остается доступной в течение 48 часов, а не одного часа.

На экземпляре с включенным GitHub Actions вложенные вызовы повторно используемых рабочих процессов в задании повторного рабочего процесса с матрицей правильно оценивают контексты в выражениях, например strategy: ${{ inputs.strategies }}.

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

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

Когда администратор сайта выполнялся ghe-btop через SSH, команда не выполнялась и произошла /usr/bin/env: python3: No such file or directory ошибка.

Администраторам сайта, которые готовились включить GitHub Actions, не удалось запустить ghe-actions-precheck служебную программу, так как файл скриптов не был исполняемым.

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

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

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

После того как администратор сайта экспортировал архив миграции в AWS S3 с помощью служебной программы GitHub Enterprise Importer gh-migrator , URL-адрес архива стал недоступен.

Если администратор сайта экспортировал архив миграции в контейнер в регионе AWS S3s us-east-1 с помощью служебной программы GitHub Enterprise Importer gh-migrator , архив был недоступен.

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

Если администратор сайта предоставляет недопустимую конфигурацию для хранилища BLOB-объектов для GitHub Actions или GitHub Packages в экземпляре, на странице предварительных проверок отображаются сведения и сведения об устранении неполадок.

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

На экземпляре с лицензией на GitHub Advanced Security пользователи, создающие пользовательские шаблоны для сканирования секретов, могут предоставлять выражения, которые должны или не должны совпадать, не более 2000 символов. Это ограничение увеличено с 1000 символов.

HIGH: устранена уязвимость, связанная с неправильной проверкой подлинности, которая позволяла неавторизованному субъекту изменять секреты других пользователей путем проверки подлинности через центр сертификации SSH. Эта уязвимость была обнаружена в рамках программы   bounty для ошибок GitHubи назначена CVE-2023-23761. [Обновлено: 07.04.2023]

MEDIUM: устранена неправильная уязвимость сравнения, которая позволяла контрабанде фиксаций, отображая неправильный diff. Эта уязвимость была обнаружена в рамках программы   bounty для ошибок GitHubи назначена CVE-2023-23762. [Обновлено: 07.04.2023]

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

На экземпляре с включенным GitHub Actions GitHub Actions теперь будет правильно выполняться после восстановления удаленного репозитория.

На экземпляре с включенным GitHub Actions вложенные вызовы повторно используемых рабочих процессов в задании повторного рабочего процесса с матрицей правильно оценивают контексты в выражениях, например strategy: ${{ inputs.strategies }}.

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

После того как администратор использовал /setup/api/start конечную точку REST API для отправки лицензии, выполнение конфигурации завершилось ошибкой Connection refused на этапе миграции.

В экземпляре в конфигурации кластера, когда администратор сайта установил режим обслуживания с помощью ghe-maintenance -s, Permission denied при попытке служебной программы получить доступ /data/user/common/cluster.confк появляется ошибка .

На экземпляре в конфигурации с высоким уровнем доступности, если администратор разорвал репликацию с узла реплика с помощью ghe-repl-teardown сразу после запуска ghe-repl-setup, но до ghe-repl-start, ошибка указывает на то, что скрипт cannot launch /usr/local/bin/ghe-single-config-apply - run is locked. ghe-repl-teardown теперь отображает информационное оповещение и продолжает снос.

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

Команды, которые администраторы сайта выполняли по протоколу SSH на любом из узлов экземпляров, не регистрировались в /var/log/ssh-console-audit.log.

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

После того как пользователь импортировал репозиторий с включенной защитой от push-уведомлений, репозиторий не был сразу виден в представлении "Покрытие безопасности" в обзоре безопасности.

Ответы от конечной /repositories точки REST API ошибочно включали удаленные репозитории.

Если администратор сайта использовал для ghe-migrator переноса данных в GitHub Enterprise Server, в некоторых случаях вложенная команда связи не сохраняются после импорта команд.

Если репозиторий содержит CODEOWNERS файл с проверка заметками, вкладка "Файлы изменены" запросов на вытягивание возвращает ошибку 500 и отображается сообщение "Ой, что-то пошло не так" в разделе "Файлы без изменений с проверка заметками".

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

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

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

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

Владельцу предприятия не удалось включить двухфакторную проверку подлинности (2FA) для экземпляра, если владельцы предприятия не включили двухфакторную проверку подлинности для своих учетных записей пользователей. [Обновлено: 17.04.2023]

На экземпляре с включенным GitHub Packages после отправки пользователей в реестр контейнеров экземпляр ошибочно ответил ошибкой 429 Too Many Requests в тех случаях, когда экземпляр может вместить запрос. Ограничения были увеличены, и пользователи должны получать это сообщение реже. [Обновлено: 30.05.2023]

Когда администратор сайта настраивает исходящий веб-прокси-сервер для GitHub Enterprise Server, экземпляр теперь проверяет домены верхнего уровня (TLD), исключенные из конфигурации прокси-сервера. По умолчанию можно исключить общедоступные TLD, которые указаны в IANA. Администраторы сайта могут указать список незарегистрированных TLD для исключения с помощью ghe-config. Префикс . требуется для любых общедоступных TLD. Например, значение .example.com является допустимым, а example.com — нет. Дополнительные сведения см. в разделе Настройка сервера веб-прокси исходящего трафика.

Чтобы избежать периодических проблем с успехом операций Git на экземпляре с несколькими узлами, GitHub Enterprise Server проверяет состояние контейнера MySQL перед попыткой SQL-запроса. Время ожидания также было сокращено.

По умолчанию для выходных данных из ghe-saml-mapping-csv -d используется /data/user/tmp путь вместо /tmp. Дополнительные сведения см. в разделе Служебные программы командной строки.

На экземпляре с лицензией на GitHub Advanced Security пользователи, создающие пользовательские шаблоны для сканирования секретов, могут предоставлять выражения, которые должны или не должны совпадать, не более 2000 символов. Это ограничение увеличено с 1000 символов.

Проекты, гибкий инструмент для планирования и отслеживания работы на GitHub Enterprise Server, теперь доступен в виде бета-версии. Проект — это адаптируемая электронная таблица, которая интегрирует проблемы и запросы на вытягивание, чтобы помочь пользователям спланировать и отслеживать работу эффективно. Пользователи могут создавать и настраивать несколько представлений, а каждое представление может фильтровать, сортировать и группировать проблемы и запросы на вытягивание. Пользователи также могут определять настраиваемые поля для отслеживания уникальных метаданных для команды или проекта, что позволяет настраивать любые потребности или процессы. Эта функция может быть изменена. Дополнительные сведения см. в разделе Сведения о Projects (beta).

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

Чтобы установить или соблюдать внутренние политики, администраторы сайтов могут использовать консоль управления для настройки политики экземпляра для хранения данных, связанных с проверками, включая данные проверок, созданные GitHub Actions и API состояний. Администраторы могут включать или отключать хранение, устанавливать пользовательское пороговое значение хранения или устанавливать пользовательский порог жесткого удаления. Дополнительные сведения см. в разделе Настройка приложений [Обновлено: 03.02.2023]

При создании пакетов поддержки с помощью ghe-support-bundle программы командной строки администраторы сайта могут указать точную длительность сбора данных в пакете. Дополнительные сведения см. в статье "Программы командной строки".

Пользователи могут просматривать и отзывать сеансы браузера и GitHub Mobile для экземпляра GitHub Enterprise Server. Дополнительные сведения см. в разделе Просмотр сеансов и управление ими.

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

Владельцы предприятий и организаций могут поддерживать соблюдение принципа минимальных привилегий, предоставляя доступ к конечным точкам журнала аудита без предоставления полных прав администратора. Для предоставления этого доступа личные маркеры доступа и приложения OAuth теперь поддерживают read:audit_log область. Дополнительные сведения см. в разделе Использование API журнала аудита для предприятия.

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

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

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

• "business_secret_scanning category actions", "business_secret_scanning_push_protection category actions" и "business_secret_scanning_push_protection_custom_message category actions" in "Audit Log events for your enterprise" (События журнала аудита для предприятия)
• Просмотр журнала аудита для организации

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

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

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

• Управление оповещениями при сканировании секретов
• "Проверка секретов" в документации по REST API

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

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

• Анализ Ruby может обнаружить более чем в два раза больше распространенных слабых мест (CWEs), которые он может обнаружить во время бета-версии. В общей сложности 30 правил могут определять ряд уязвимостей, включая межсайтовые скрипты (XSS), отказ в обслуживании регулярных выражений (ReDoS), внедрение SQL и многое другое. Дополнительные библиотеки и платформы для Ruby-on-Rails гарантируют, что разработчики веб-служб получают еще более точные результаты. GitHub Enterprise Server поддерживает все распространенные версии Ruby, вплоть до 3.1.
• Поддержка Kotlin является расширением существующей поддержки Java и преимуществами существующих запросов CodeQL для Java, которые применяются как к мобильным, так и к серверным приложениям. GitHub также улучшил и добавил ряд мобильных запросов, охватывающих такие проблемы, как обработка намерений, проблемы проверки Веб-представления, внедрение фрагментов и многое другое.

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

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

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

• GitHub Actions авторы могут автоматически обновлять зависимости в файлах рабочих процессов.
• Разработчики Dart или Flutter, использующие Pub, могут автоматически обновлять зависимости в своих проектах.

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

Разработчики Dart и JavaScript на экземпляре с включенным граф зависимостей могут получать оповещения Dependabot об известных уязвимостях в зависимостях проекта.

• Для Dart граф зависимостей обнаруживает pubspec.lock файлы и pubspec.yaml .
• Разработчики JavaScript, использующие Node.js и npm, могут получать оповещения об известных уязвимостях в манифестах Yarn версии 2 и 3. Это дополняет существующую поддержку манифестов версии 1. Граф зависимостей обнаруживает package.jsonфайлы и yarn.lock .

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

• Сведения о графе зависимостей
• Рекомендации по безопасности просмотра в базе данных рекомендаций GitHub
• Сведения об оповещениях Dependabot

Разработчики Python, использующие поддерживаемые диспетчеры пакетов на экземпляре с включенным граф зависимостей, могут получать оповещения Dependabot о зависимостях в pyproject.toml файлах, которые соответствуют стандарту PEP 621. Дополнительные сведения см. в разделе Сведения об обновлениях версий Dependabot.

Разработчики Python, получающие оповещения Dependabot, могут сократить количество обновлений версий, если текущая зависимость уже удовлетворяется новой версией. Чтобы настроить это поведение, используйте стратегию increase-if-necessary управления версиями. Дополнительные сведения см. в разделе Параметры конфигурации для файла dependabot.yml.

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

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

Пользователи могут программно просматривать оповещения Dependabot и работать с ними с помощью REST API. Новые конечные точки для просмотра, перечисления и обновления оповещений Dependabot доступны в бета-версии. Эти конечные точки могут быть изменены. Дополнительные сведения см. в разделе "Оповещения Dependabot" в документации по REST API.

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

Участники могут определить политику безопасности репозитория, создав SECURITY.md файл. Чтобы повысить видимость политики, GitHub Enterprise Server будет ссылаться на политику на вкладке кода . Дополнительные сведения см. в разделе Добавление политики безопасности в репозиторий.

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

• "Проверка зависимостей" в документации по REST API
• Настройка проверки зависимостей

API GraphQL предоставляет доступ к граф зависимостей репозитория. Эта функция доступна в предварительной версии и может быть изменена. Дополнительные сведения см. в разделе Объекты документации по API GraphQL.

Во время настройки хранилища для GitHub Actions администраторы сайта могут избежать рисков, связанных с вводом конфиденциальных секретов и ключей доступа, используя OIDC для подключения к поставщикам хранилища объектов. GitHub Actions на GitHub Enterprise Server поддерживает OIDC для подключений к AWS, Azure и Google Cloud Platform. Эта функция находится в бета-версии и может быть изменена. Дополнительные сведения см. в разделе Включение GitHub Actions для GitHub Enterprise Server.

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

• Чтобы использовать эту функцию, приложение средства выполнения тестов должно быть версии 2.297.0 или более поздней. Версии 2.298.2 и более поздние будут предупреждать пользователей, использующих save-state команды или set-output . Эти команды будут полностью отключены в будущем выпуске.
• Чтобы использовать обновленные saveState функции иsetOutput, рабочие процессы, использующие набор средств GitHub Actions, должны вызывать @actions/core версию 1.10.0 или более позднюю.

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

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

• Управление параметрами GitHub Actions для репозитория
• "Разрешения GitHub Actions" в документации по REST API

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

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

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

runs-on:
  group: my-group
  labels: [ self-hosted, label-1 ]

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

Пользователи могут применять стандартные методики CI/CD во всех репозиториях организации, определяя необходимые рабочие процессы. Эти рабочие процессы активируются по мере необходимости проверки состояния для всех запросов на вытягивание, предназначенных для ветвь по умолчанию репозиториев, что блокирует слияние до тех пор, пока не пройдет проверка. Эта функция находится в бета-версии и может быть изменена. Дополнительные сведения см. в разделе Требуемые рабочие процессы.

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

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

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

Для повышения возможности обнаружения в GitHub Discussions представлены следующие улучшения.

• Владельцы репозитория могут закреплять обсуждения в определенной категории.
• Названия и описания категорий отображаются на странице категории.

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

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

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

Администраторы репозитория могут обеспечить безопасность и стабильность ветвей, требуя утверждения запроса на вытягивание кем-либо, кроме последнего push-сервера, или блокируя ветвь. Дополнительные сведения см. в разделе Сведения о защищенных ветвях.

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

API GraphQL поддерживает создание и удаление связи между ветвью и проблемой. Дополнительные сведения см. в следующей документации.

• "Создание ветви для работы с проблемой"
• "createLinkedBranch" и "deleteLinkedBranch" в документации по API GraphQL "Мутации"
• "Объекты" в документации по API GraphQL

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

• Управление выпусками в репозитории
• "Выпуски" в документации по REST API
• "Объекты" в документации по API GraphQL

Пользователи могут экономить время и реже переключать контекст, получая и выполняя действия в режиме реального времени о действиях GitHub Enterprise Server непосредственно в Slack или Microsoft Teams. Интеграция GitHub для этих служб теперь общедоступна. Дополнительные сведения см. в разделе Расширения и интеграции GitHub.

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

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

Прежде чем администратор сайта сможет перейти с GitHub Enterprise Server с помощью интерфейса командной строки GitHub Enterprise Importer, GRAPHQL API startRepositoryMigration или REST API запуска миграции организации, администратор должен использовать консоль управления для настройки поставщика хранилища BLOB-объектов для хранения архивов миграции. Поддерживаемые возможности включают Amazon S3 и Хранилище BLOB-объектов Azure. Ранее хранилище BLOB-объектов не требовалось и при необходимости можно было настроить с помощью gh gei. Это изменение добавляет поддержку миграций, когда размер источника или метаданных Git превышает 1 ГБ.

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

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

Экземпляры с лицензией на GitHub Advanced Security будут регулярно выполнять сканирование журнала для обнаружения новых типов секретов в репозиториях с включенным GitHub Advanced Security и сканированием секретов. Ранее пользователям приходилось вручную выполнять проверку журналов.

На экземплярах с лицензией GitHub Advanced Security, чтобы гарантировать, что в будущих выпусках GitHub Enterprise Server всегда будет отображаться предварительный просмотр обнаруженного секрета в ИНТЕРФЕЙСАх API или пользовательском веб-интерфейсе, обнаруженные секреты теперь хранятся отдельно от исходного кода. Обнаруженные секреты хранятся с помощью симметричного шифрования. [Обновлено: 15.02.2023]

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

• Средство увязки программ в пакеты
• Docker
• Gradle
• Maven
• npm
• Nuget
• Python
• Yarn

Дополнительные сведения см. в разделе Параметры конфигурации для файла dependabot.yml.

Разработчики Elixir, использующие локальные hex-репозитории , могут настроить частный реестр для обновления версий Dependabot на GitHub Enterprise Server. Дополнительные сведения см. в разделе Параметры конфигурации для файла dependabot.yml.

Оповещения Dependabot имеют следующие улучшения удобства использования.

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

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

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

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

Интеграторы, желающие получить веб-перехватчик для оповещений Dependabot, должны использовать новый dependabot_alert веб-перехватчик. Этот веб-перехватчик заменяет repository_vulnerability_alert веб-перехватчик. Дополнительные сведения см. в разделе События веб-перехватчика и полезные данные.

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

Разработчики JavaScript, использующие обновления безопасности Node.js, npm и Dependabot, могут сэкономить время при обновлении проектов npm с транзитивными зависимостями.

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

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

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

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

• Чтобы ускорить проверку, GitHub предлагает пользователям указать причину изменения.
• Чтобы убедиться, что вклад соответствует намерению пользователя, GitHub не будет изменять порядок ссылок в diff.

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

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

GitHub Actions рабочие процессы больше не будут запускаться бесконечно при использовании GITHUB_TOKEN с событиями workflow_dispatch и repository_dispatch . До этого изменения события, активированные с помощью GITHUB_TOKEN , не создавали новое выполнение рабочего процесса. Дополнительные сведения см. в статье Активация рабочего процесса.

Для запланированных запусков рабочих процессов GitHub Actions пользователи увидят дополнительные сведения о репозитории, организации и предприятии в полезных данных для github.event.

Пользователи GitHub Actions лучше понять ход выполнения задания при использовании правил защиты среды. Веб-перехватчик workflow_job поддерживает новое waiting состояние всякий раз, когда задание ожидает правила защиты среды. Кроме того, если задание ссылается на environment ключ в определении YAML, полезные workflow_job данные веб-перехватчика также будут содержать новое свойство , deployment. deploymentсодержит метаданные о развертывании, созданном проверка запуска. Дополнительные сведения см. в разделе Использование сред для развертывания.

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

• business.sso_response События и org.sso_response отображаются в REST API и полезных данных для потоковой передачи журналов аудита.
• repo.renameСобытия , project.renameи protected_branch.update_name включают текущие и прошлые имена для переименованных в old_name поле.
• События для оповещений Dependabot содержат alert_numberполя , ghsa_id, dismiss_reasonи dismiss_comment , а также ссылку на оповещение и точную метку времени.

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

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

Вкладки Беседы и Файлы в запросах на вытягивание теперь загружаются быстрее из-за отложенного выделения синтаксиса.

Чтобы обеспечить более согласованное взаимодействие между веб-интерфейсом и рабочими станциями пользователей, а также ускорить процесс проверки возможности автоматического слияния запроса на вытягивание, GitHub Enterprise Server теперь использует merge-ort стратегию. Дополнительные сведения см. в статье Стратегии слияния в документации по Git.

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

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

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

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

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

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

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

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

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

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

1. В конце URL-адреса застрявшего обсуждения запишите номер обсуждения.
2. В пользовательском веб-интерфейсе перейдите в репозиторий, в котором зависло преобразование.
3. В правом верхнем углу веб-интерфейса щелкните .
4. В разделе "Совместная работа" щелкните ЧИСЛО обсуждений.
5. В списке щелкните номер из шага 1.
6. В разделе "Преобразование" щелкните Задание преобразования в очередь.
7. Подождите несколько минут, а затем проверьте состояние проблемы.

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

Если администратор корневого сайта заблокирован в консоли управления после неудачных попыток входа, учетная запись не разблокируется автоматически после определенного времени блокировки. Пользователь с административным доступом по протоколу SSH к экземпляру должен разблокировать учетную запись с помощью административной оболочки. Дополнительные сведения см. в разделе Устранение неполадок с доступом к консоли управления. [Обновлено: 23.02.2023]

Во время обновления до GitHub Enterprise Server 3.8.0 в кластере после обновления узлов, отличных от основного узла MySQL, и перед обновлением основного узла MySQL следующая ошибка может появиться несколько раз после запуска ghe-cluster-config-apply.

Error response from daemon: conflict: unable to delete IMAGE_ID (cannot be forced) - image is being used by running container CONTAINER_ID

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

После обновления до GitHub Enterprise Server 3.8.0 команды, выполняемые по протоколу SSH на любом из узлов экземпляра, не будут входить в /var/log/ssh-console-audit.logсистему . Чтобы устранить эту проблему, перейдите по протоколу SSH в затронутый узел и выполните следующую команду.

source /etc/bash.bashrc

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

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

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

Использование API поиска может привести к сбою последующих запросов к другим интерфейсам. При возникновении этой проблемы затронутые пользователи API или веб-интерфейса получат ответы HTTP 5xx, и это NoMethodError исключение будет зарегистрировано:

NoMethodError (undefined method `starts_with?' for [:ok, "refs/heads/main"]:Array):

На экземпляре с лицензией GitHub Advanced Security, где включено сканирование секретов, чрезмерное вхождение в /var/log систему может привести к ошибкам пользователей и снижению производительности системы, если журналы занимают все свободное место на томе. Чтобы предотвратить возникновение этой проблемы для пользователей, отслеживайте свободное место на корневом томе экземпляра. Дополнительные сведения см. в разделах Настройка проверки секретов для (модуль) и Мониторинг (модуль). Если вы подозреваете, что эта проблема затрагивает ваш экземпляр, и вам нужна помощь, обратитесь в службу поддержки GitHub. [Обновлено: 03.05.2023]