Sobre problemas conhecidos com a GitHub Enterprise Server atualização
GitHub está ciente dos seguintes problemas que podem afetar atualizações para novas versões de GitHub Enterprise Server. Para obter mais informações, consulte "Problemas conhecidos" nas [notas de versãoGitHub Enterprise Server](/admin/release-notes).
GitHub recomenda fortemente backups regulares da configuração e dos dados da sua instância. Antes de prosseguir com qualquer atualização, faça o backup da instância e valide-o em um ambiente de preparo. Para saber mais, confira [AUTOTITLE](/admin/configuration/configuring-your-enterprise/configuring-backups-on-your-appliance) e [AUTOTITLE](/admin/installation/setting-up-a-github-enterprise-server-instance/setting-up-a-staging-instance).
Retomar as atualizações para a versão 3.15 ou superior
Pausamos as atualizações para as versões 3.15, 3.16 e 3.17. Agora você pode atualizar para 3.15.12, 3.16.8, 3.17.5 ou posterior. Não recomendamos atualizar para versões anteriores da 3.15, 3.16 ou 3.17. Como uma etapa adicional, é recomendável verificar a capacidade do sistema antes de atualizar. Confira Verificar a capacidade do sistema antes de atualizar.
Estendemos a janela de suporte para as versões 3.14, 3.15, 3.16 e 3.17. A janela de suporte para a versão 3.13 permanece inalterada. A data de encerramento de cada uma das versões, 3.14, 3.15, 3.16 e 3.17, foi atualizada. Para saber mais, confira Lançamentos do GitHub Enterprise Server.
Continuaremos lançando patches para as versões 3.14, 3.15, 3.16 e 3.17 ao longo desta janela de suporte estendido.
O tamanho do disco raiz necessário aumentou para 400 GB
O requisito anterior de tamanho de disco raiz de 400 GB para as versões 3.15.2 e posteriores foi removido. Esse requisito era baseado na análise de pacotes de suporte e tíquetes de suporte. Alguns fatores, como logs, colocavam pressão excessiva no disco raiz, o que causava problemas com o aparelho. Depois de receber comentários de que adquirir um novo hardware seria desafiador para muitos clientes, revertemos o requisito e adotamos uma abordagem gradual. Ainda recomendamos que os clientes, especialmente aqueles que usam topologias autônomas ou autônomas de alta disponibilidade, atualizem o disco raiz para 400 GB. Quando você conseguir atualizar o disco raiz para 400 GB, confira as instruções a seguir.
Para clientes que usam topologias autônomas ou de HA, é recomendável que novas instalações da versão 3.15 ou posteriores ou atualizações para a 3.15 usem o tamanho do disco raiz mínimo de 400 GB. GitHub recomenda fortemente seguir as diretrizes em Aumentar a capacidade de armazenamento.
Registros não criptografados
Se você estiver atualizando da GitHub Enterprise Server 3.11 ou 3.12 para a 3.13 ou da 3.12 para a 3.14, poderá encontrar um problema com registros não criptografados devido à falta de chaves necessárias para descriptografia. A única solução é excluir os registros não criptografados. O tipo de registro afetado por esse problema são registros 2FA, o que significa que talvez seja necessário solicitar aos usuários que habilitem novamente a 2FA (autenticação de dois fatores).
Antes de atualizar
Se você estiver atualizando da GitHub Enterprise Server 3.11 ou 3.12 para a 3.13 ou da 3.12 para a 3.14, poderá executar o script de diagnóstico de criptografia para identificar os registros indescriptografáveis antecipadamente. Este script não modifica nenhum registro, mas permite que você entenda o impacto e possa se planejar.
- Baixe o script de diagnóstico de criptografia. Você pode usar um comando como
curl -L -O https://gh.io/ghes-encryption-diagnosticspara baixar o script. - Salve o script no diretório
/data/user/commondo dispositivo. - Siga as instruções no início do script e execute-as no dispositivo. Se houver registros não criptografados, eles estarão registrados em
/tmp/column_encryption_records_to_be_deleted.log. Os registros que estão aqui não foram descriptografados porque o sistema não conseguiu encontrar as chaves usadas para a criptografia deles.
Esses registros serão excluídos como parte do processo de upgrade. O script avisará você sobre os usuários que precisarão se inscrever novamente na 2FA após a atualização. Os identificadores dos usuários afetados estão registrados em /tmp/column_encryption_users_to_have_2fa_disabled.log. Esses usuários precisarão ser inscritos novamente na 2FA.
Se o script tiver problemas inesperados, você será solicitado a entrar em contato Suporte do GitHub. Os erros relacionados a esses problemas serão registrados em /tmp/column_encryption_unexpected_errors.log. Se você estiver em uma situação crítica e não conseguir que os usuários se reinscrevam na 2FA, entre em contato Suporte do GitHub para obter ajuda.
O script informará: "Sucesso: registros criptografados OK". se conseguisse encontrar as chaves associadas aos registros criptografados. Esses registros serão descriptografados e preservados durante o processo de upgrade e não exigirão intervenção manual.
Durante a atualização
Caso você não tenha tido a oportunidade de executar o script de diagnóstico de criptografia com antecedência, o produto dispõe de mecanismos destinados a fornecer ajuda. As verificações pré-voo durante o processo de atualização detectarão registros não descriptografáveis e os registrarão em /tmp/column_encryption_records_to_be_deleted.log. A sequência avisará você sobre os usuários que precisarão habilitar novamente a 2FA após a atualização. Os registros de usuários afetados são registrados em /tmp/column_encryption_users_to_have_2fa_disabled.log.
Se forem detectados registros não criptografados, você precisará indicar se deseja continuar com a atualização. Se você continuar, o processo de atualização excluirá os registros não criptografados. Caso contrário, o processo de atualização será fechado.
Se você tiver dúvidas durante a atualização, poderá entrar em contato com Suporte do GitHub. Após ter tido o tempo e a oportunidade de entender o impacto, você poderá disparar a atualização novamente.
Atualizando do 3.14 para o 3.16.0
Se você estiver usando GitHub Enterprise Server a 3.14 e tiver habilitado produtos de segurança por padrão no nível da organização, não poderá atualizar diretamente da 3.14 para a 3.16.0. Para determinar a qualificação para a atualização, execute o seguinte comando:
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? }
Se o comando retornar true, uma atualização direta da 3.14 para a 3.16.0 falhará, e recomendamos que você aguarde o próximo patch 3.16 para atualizar.
Como alternativa, você pode passar para a 3.16.0 agora atualizando primeiro da 3.14 para a 3.15 e, em seguida, da 3.15 para a 3.16.0.
A atualização para 3.16.0 e 3.17.0 inclui uma migração de dados lenta para verificação de código
Os clientes que têm a verificação de código habilitada podem ter transições mais lentas ao atualizar para a versão 3.16.0 devido a alterações no modelo de dados que exigem migração de dados. Recomendamos testar essa atualização primeiro em um ambiente não de produção, pois isso pode resultar em um tempo de inatividade mais longo do que o esperado. [Atualizado em: 12/06/2025]