О известных проблемах с обновлениями GitHub Enterprise Server
GitHub знает о следующих проблемах, которые могут повлиять на обновления до новых выпусков GitHub Enterprise Server. Дополнительные сведения см. в разделе "Известные проблемы" в заметках о выпуске GitHub Enterprise Server.
GitHub настоятельно рекомендует регулярные резервные копии конфигурации и данных экземпляра. Прежде чем продолжить обновление, создайте резервную копию экземпляра, а затем проверьте резервную копию в промежуточной среде. Дополнительные сведения см. в разделе [AUTOTITLE и Настройка резервных копий в экземпляре с помощью служебных программ резервного копирования](/admin/installation/setting-up-a-github-enterprise-server-instance/setting-up-a-staging-instance).
Требуемый размер корневого диска увеличился до 400 ГБ
Предыдущее требование к размеру корневого диска 400 ГБ для версий 3.15.2 и более поздних версий было удалено. Это требование было основано на анализе пакетов поддержки и запросов в службу поддержки. Некоторые факторы, такие как журналы, оказывают чрезмерное давление на корневой диск, который вызвал проблемы с устройством. Получив отзыв о том, что это сложно для многих клиентов приобретать новое оборудование, мы откатили требование в пользу постепенного подхода. Мы по-прежнему рекомендуем клиентам, особенно тем, кто использует автономные или автономные топологии высокой доступности, обновите корневой диск до 400 ГБ. Если вы сможете обновить корневой диск до 400 ГБ, ознакомьтесь со следующими инструкциями.
Для клиентов, использующих автономные топологии или топологии высокого уровня доступности, рекомендуется использовать новые установки версии 3.15 или более поздней версии или обновления до версии 3,15, чтобы использовать размер корневого диска не менее 400 ГБ. GitHub настоятельно рекомендует следовать инструкциям в Увеличение емкости хранилища.
Нешифрованные записи
При обновлении с GitHub Enterprise Server 3.11 или 3.12 до 3.13 или с 3.12 до 3.14 может возникнуть проблема с нешифрованной записью из-за отсутствия необходимых ключей для расшифровки. Единственным решением является удаление нешифрованных записей. Тип записей, затронутых этой проблемой, — это записи 2FA, что означает, что пользователям может потребоваться повторно включить двухфакторную проверку подлинности (2FA).
Перед обновлением
Если вы обновляете данные GitHub Enterprise Server 3.11 или 3.12 до 3.13 или с 3.12 до 3.14, можно запустить скрипт шифрования диагностика, чтобы определить незашифрованные записи заранее. Этот скрипт не будет изменять записи, но даст вам возможность понять влияние и запланировать его.
- Скачайте скрипт шифрования диагностика. Для скачивания скрипта можно использовать команду
curl -L -O https://gh.io/ghes-encryption-diagnostics. - Сохраните скрипт
/data/user/commonв каталоге на устройстве. - Следуйте инструкциям в верхней части скрипта и выполните его на устройстве. Если есть какие-либо нешифрованные записи, они вошли в
/tmp/column_encryption_records_to_be_deleted.logсистему. Все записи, зарегистрированные здесь, не удалось расшифровать, так как система не смогла найти ключи, которые использовались для шифрования записей.
Обратите внимание, что эти записи будут удалены в процессе обновления. Скрипт предупредит пользователей, которым потребуется повторно зарегистрировать 2FA после обновления. Затронутые дескрипторы пользователей вошли в /tmp/column_encryption_users_to_have_2fa_disabled.logсистему. Эти пользователи должны быть повторно зарегистрированы в 2FA.
Если скрипт возникает с непредвиденными проблемами, вам будет предложено связаться с Служба поддержки GitHub. Ошибки, связанные с этими проблемами, будут входить в /tmp/column_encryption_unexpected_errors.logсистему. Если вы находитесь в ужасной ситуации и не можете повторно зарегистрировать пользователей в 2FA, обратитесь к Служба поддержки GitHub для получения справки.
Сценарий будет печатать "Success: Encrypted Records OK". Если он смог найти ключи, связанные с зашифрованными записями. Эти записи будут расшифрованы и сохранены во время процесса обновления и не требуют вмешательства вручную.
Во время обновления
Если у вас нет возможности запустить скрипт шифрования диагностика заранее, существуют механизмы в продукте, которые помогут вам. Предварительные проверки во время обновления будут обнаруживать нешифрованные записи и регистрировать их /tmp/column_encryption_records_to_be_deleted.log. Последовательность предупреждает пользователей, которым потребуется повторно включить 2FA после обновления. Затронутые записи пользователей вошли в /tmp/column_encryption_users_to_have_2fa_disabled.logсистему.
Если обнаружены нешифрованные записи, вам будет предложено продолжить обновление. При продолжении процесс обновления удаляет нешифрованные записи. В противном случае процесс обновления завершится.
Если у вас есть вопросы во время обновления, вы можете обратиться к Служба поддержки GitHub. Когда у вас было время и возможность понять влияние, вы можете получить обновление.
Обновление с версии 3.14 до 3.16.0
Если вы используете GitHub Enterprise Server 3.14 и по умолчанию включили продукты безопасности на уровне организации, вы не можете обновиться непосредственно с 3.14 до 3.16.0. Чтобы определить право на обновление, выполните следующую команду:
ghe-console -y
Organization.any? { |o| [o.vulnerability_updates_enabled_for_new_repos?, o.security_alerts_enabled_for_new_repos?, o.dependency_graph_enabled_for_new_repos?, o.advanced_security_enabled_on_new_repos?, SecretScanning::Features::Org::TokenScanning.new(o).secret_scanning_enabled_for_new_repos?, SecretScanning::Features::Org::PushProtection.new(o).enabled_for_new_repos?].any? }
Если команда возвращается true, прямой переход с версии 3.14 до 3.16.0 завершится ошибкой, и мы рекомендуем дождаться следующего исправления 3.16.
Кроме того, вы можете перейти на 3.16.0 теперь, сначала обновив от 3.14 до 3.15, а затем с 3.15 до 3.16.0.
Обновление до версии 3.16.0 и 3.17.0 включает медленную миграцию данных для сканирования кода
При обновлении до версии 3.16.0 клиенты с включенным сканированием кода могут столкнуться с более медленными переходами из-за изменений в модели данных, требующих миграции данных. Мы рекомендуем сначала протестировать это обновление в нерабокой среде, так как это может привести к более длительному простою, чем ожидалось. [Обновлено: 2025-06-12]