Enterprise Server 3.5 release notes

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.

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 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.

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.

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, pull requests in the repository intermittently failed to display the files validity or updated code owner information, requiring the user to reload the page.

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.

On an instance with GitHub Connect enabled, if "Users can search GitHub.com" was enabled, users would not see issues in private and internal repositories in search results for GitHub.com.

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.

After an enterprise owner enables Dependabot updates, the instance creates the initial set of updates faster.

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 "Habilitar e programar o modo de manutenção."

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 "Configurando um servidor proxy Web de saída."

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 "Utilitários de linha de comando."

Ao exibir uma lista de sessões abertas para os dispositivos conectados a uma conta de usuário, a interface do usuário da Web do GitHub Enterprise Server pode exibir um local incorreto.

No caso raro em que os fragmentos primários do Elasticsearch estavam localizados em um nó de réplica, o comando ghe-repl-stop falhava com ERROR: Running migrations.

ALTA: atualização do Git para incluir as correções de 2.39.2, que abordam CVE-2023-22490 e CVE-2023-23946.

Os pacotes foram atualizados para as versões de segurança mais recentes.

Ao usar uma URL de ponto de extremidade VPC como uma URL do AWS S3 para pacotes do GitHub, ocorria uma falha na publicação e instalação dos pacotes.

MÉDIA: uma vulnerabilidade de injeção de código foi identificada no GitHub Enterprise Server que permitiu definir variáveis de ambiente arbitrárias de um só valor de variável de ambiente no GitHub Actions quando um executor baseado no Windows é usado devido à limpeza inadequada de bytes nulos. Para explorar essa vulnerabilidade, um invasor precisava ter uma permissão existente para controlar o valor das variáveis de ambiente para uso com o GitHub Actions. Essa vulnerabilidade foi relatada por meio do Programa de Recompensas por Bugs do GitHub e recebeu a designação CVE-2023-22381.

Os pacotes foram atualizados para as versões de segurança mais recentes.

Durante a fase de validação de uma execução de configuração, um No such object error pode ter ocorrido nos serviços Notebook e Viewscreen.

Ao habilitar o gerenciamento automático de certificados TLS com Let's Encrypt, o processo pode falhar com o erro The certificate is not signed by a trusted certificate authority (CA) or the certificate chain in missing intermediate CA signing certificates.

Quando ocorre um tempo limite durante a geração do diff, como quando um commit exibe um erro em que a geração do diff está levando muito tempo, o evento do webhook push fornecerá informações diff vazias. Anteriormente, o evento de webhook push falhava ao ser entregue.

ALTA: Atualização do Git para incluir as correções de 2.39.1, que abordam CVE-2022-41903 e CVE-2022-23521.

Limpe segredos adicionais em pacotes de suporte e no log de configuração.

As dependências da ação do CodeQL foram atualizadas para as versões de segurança mais recentes.

Os pacotes foram atualizados para as versões de segurança mais recentes.

As métricas Active workers e Queued requests dos serviços de contêiner github (renomeadas com base nos metadados), gitauth e unicorn não eram lidas corretamente nos itens coletados e exibidos no Console de Gerenciamento.

Os emails de alerta do Dependabot seriam enviados para repositórios desabilitados.

Repositórios bloqueados para migração permitiriam que os arquivos fossem editados na interface do usuário da Web.

Ao exibir uma comparação de solicitações de pull para um arquivo grande com muitas linhas entre as alterações, não foi possível expandir o modo de exibição para exibir todas as alterações.

O git-janitorcomando não pôde corrigir arquivos multi-pack-index.lock desatualizados, resultando na falha na manutenção do repositório.

Os comandos ghe-support-bundle e ghe-cluster-support-bundle foram atualizados para incluir o sinalizador -p/--period para gerar um pacote de suporte com restrição de tempo. A duração pode ser especificada em dias e horas, por exemplo: -p '2 hours', -p '1 day', -p '2 days 5 hours'.

O desempenho das execuções de configuração iniciadas com ghe-config-apply foi aprimorado.

Ao atualizar uma instância com uma nova partição raiz, a execução do comando ghe-upgrade com a opção -t/--target garante que a verificação de simulação do tamanho mínimo de armazenamento em disco seja executada na partição de destino.

Ao exportar dados da conta, fazer backup de um repositório ou executar uma migração, o link para um arquivo morto do repositório agora expira após uma hora. Anteriormente, o link de arquivo morto expirava após cinco minutos.

ALTO: foi identificada uma vulnerabilidade de transversalidade de caminho no GitHub Enterprise Server que permitia a execução remota de códigos ao criar um site do GitHub Pages. A fim de explorar essa vulnerabilidade, um invasor precisaria de permissão para criar e compilar um site do GitHub Pages na instância. Essa vulnerabilidade foi relatada pelo Programa de Recompensas por Bugs do GitHub e recebeu a designação CVE-2022-46256.

ALTO: uma vulnerabilidade de autorização incorreta permitia que um token de usuário para servidor com escopo definido fosse escalado para um acesso de administrador completo a um repositório. Um invasor precisaria de uma conta com acesso de administrador para instalar um Aplicativo GitHub mal-intencionado. Essa vulnerabilidade afetava todas as versões do GitHub Enterprise Server anteriores à 3.7.0. Ela foi relatada pelo Programa de Recompensas por Bugs do GitHub e recebeu a designação CVE-2022-23741.

MÉDIA: uma vulnerabilidade de divulgação de informações confidenciais foi identificada no GitHub Enterprise Server que permitia que repositórios privados fossem adicionados a um grupo de executores do GitHub Actions por meio da API por um usuário que não tinha acesso a esses repositórios, resultando na exibição dos nomes dos repositórios na interface do usuário. Para explorar essa vulnerabilidade, um invasor precisava ter acesso à instância do GHES, permissões para modificar os grupos de executores do GitHub Actions e adivinhar com sucesso a ID oculta dos repositórios privados. Essa vulnerabilidade foi relatada por meio do Programa de Recompensas por Bugs do GitHub e recebeu a designação CVE-2022-46257.

Se uma dependência do GitHub Actions usar uma versão SHA fixada, o Dependabot não a marcará mais como vulnerável.

Quando um administrador de site executava o comando ghe-repl-sync-ca-certificates em um nó primário de instâncias por meio do shell administrativo (SSH), o comando replicava os certificados de CA do nó primário de instâncias em apenas um único nó de réplica. O comando não replicava os certificados em todos os nós de réplica disponíveis.

Falha na instalação do GitHub Enterprise Server no hipervisor do VMware ESXi devido à geração de um arquivo OVA com um valor de capacidade inválido.

Quando os usuários executavam uma operação usando a API, o GitHub Enterprise Server impunha cotas de tamanho de repositório mesmo quando elas estavam desabilitadas globalmente.

O evento de webhook member não incluía os valores de campo from e to para o campo permission como parte do campo changes.

Depois que a conta de um usuário era excluída da instância, os anexos de imagem que ele carregou em comentários não ficavam mais visíveis na interface da Web.

Em alguns casos, a página de configuração da verificação de código relatava erroneamente que o GitHub Actions não estava configurado para a instância.

Se um usuário carregava mais de um arquivo durante a criação de um Gist, não era possível excluir nenhum arquivo carregado após o primeiro.

Uma mensagem de nível de depuração aparecia em um log do sistema, podendo consumir espaço rapidamente no volume de armazenamento raiz da instância.

MEDIUM: Updated CommonMarker to address a scenario where parallel requests to the Markdown REST API could result in unbounded resource exhaustion. This vulnerability has been assigned CVE-2022-39209.

MEDIUM: Scoped user-to-server tokens from GitHub Apps could bypass authorization checks in GraphQL API requests when accessing non-repository resources. This vulnerability was reported via the GitHub Bug Bounty Program and has been assigned CVE-2022-23739.

MEDIUM: Pull request preview links did not properly sanitize URLs, allowing a malicious user to embed dangerous links in the instances web UI. This vulnerability was reported via the GitHub Bug Bounty program.

MEDIUM: An incorrect authorization vulnerability was identified in GitHub Enterprise Server that allowed a repository-scoped token with read/write access to modify GitHub Actions workflow files without a workflow scope. The "Conteúdo do repositório" should enforce workflow scope. This vulnerability was reported via the GitHub Bug Bounty program and has been assigned CVE-2022-46258.

Setting the maintenance mode with an IP Exception List would not persist across upgrades.

GitHub Pages builds could time out on instances in AWS that are configured for high availability.

After configuration of Dependabot and alert digest emails, the instance would send digest emails to suspended users.

The audit log timestamp for Dependabot alert events returned the creation date of the alert instead of the timestamp when a user took action on the alert.

When accessing an instances JavaScript resources from behind a proxy, the browser displayed Cross-Origin Resource Sharing (CORS) errors.

If a user named a status check with leading or trailing spaces, the instance created a duplicate check if another check existed with the same name and no leading or trailing spaces.

If a user configured a pre-receive hook for multiple repositories, the instances Hooks page would not always display the correct status for the hook.

When an enterprise owner impersonated a user and tried to install a GitHub App, the button to confirm the installation was disabled and could not be clicked.

After running migrations for the GitHub Enterprise Importer on an instance configured for high availability, replication of migration storage assets would not catch up.

Zombie processes no longer accumulate in the gitrpcd container.

ALTO: dependências atualizadas do Console de Gerenciamento para as versões de patch mais recentes, que abordam vulnerabilidades de segurança, incluindo CVE-2022-30123 e CVE-2022-29181.

ALTO: verificações foram adicionadas para resolver uma vulnerabilidade de chave de cache imprópria que permitia que um agente não autorizado acessasse arquivos de um repositório privado por meio de um repositório público. Essa vulnerabilidade recebeu a designação CVE-2022-23738.

MÉDIO: o CommonMarker foi atualizado para resolver um cenário em que solicitações paralelas para a API REST de Markdown podiam resultar em um esgotamento de recursos não associados. Essa vulnerabilidade foi designada CVE-2022-39209.

MÉDIO: o Redis foi atualizado para a 5.0.14 a fim de abordar CVE-2021-32672 e CVE-2021-32762.

MÉDIO: os executores do GitHub Actions foram atualizados para corrigir um bug que permitia que variáveis de ambiente em trabalhos do GitHub Actions escapassem do contexto da variável e modificassem a invocação de comandos docker diretamente. Para saber mais, confira a consultoria de segurança do Actions Runner.

MÉDIO: foi identificada no GitHub Enterprise Server uma vulnerabilidade de gerenciamento de privilégios inadequados que permitia que usuários com privilégios inadequados criassem ou excluíssem páginas por meio da API. Para explorar essa vulnerabilidade, um invasor precisaria ser adicionado ao repositório de uma organização com permissões de gravação. Essa vulnerabilidade foi relatada por meio do Programa de Recompensas por Bugs do GitHub e recebeu a designação CVE-2022-23737.

BAIXO: devido a uma vulnerabilidade do CSRF, uma solicitação GET para o ponto de extremidade site/toggle_site_admin_and_employee_status da instância podia alternar o status de administrador do site de um usuário sem fornecer notificação.

Os pacotes foram atualizados para as versões de segurança mais recentes.

Depois que um administrador de site fazia uma alteração que disparava uma execução de configuração, como desabilitar o GitHub Actions, a validação dos serviços falhava algumas vezes com a mensagem WARNING: Validation encountered a problem.

Depois que um administrador de site instalava um hotpatch com alterações para ativos da interface da Web, como arquivos JavaScript ou imagens, a instância não fornecia os novos ativos.

Quando um usuário acessava um repositório renomeado usando o Git, o nome do host na saída do Git indicava incorretamente GitHub.com em vez do nome do host da instância.

Em instâncias que usam autenticação e sincronização LDAP, a sincronização falharia e imprimiria undefined method ord for nil:NilClass no ldap-sync.log.

Resolvido um bug no qual o ponto de extremidade para criar um estado de proteção de marca para um repositório retornava um erro 500.

Ativos excluídos e ativos agendados para limpeza em um repositório, como arquivos LFS, demoravam muito para serem limpos.

Se um usuário instalava um Aplicativo GitHub para uma conta de usuário e a convertia em uma organização, o aplicativo não recebia permissões para a organização.

Os alertas de verificação de segredo ausentes na instância com uma licença do GitHub Advanced Security que não foi atualizada diretamente para o GitHub Enterprise Server 3.4 agora estão visíveis na interface da Web e por meio da API REST.

Em alguns casos, em uma instância com uma licença GitHub Advanced Security, os alertas de verificação de segredo não incluíam o tipo de provedor e, em vez disso, indicavam que o tipo de provedor era "desconhecido".

Para garantir que os administradores de site possam concluir uma atualização com êxito, a instância agora executará uma verificação de simulação a fim de garantir que a máquina virtual atenda aos requisitos mínimos de hardware. A verificação também confere a integridade do Elasticsearch. É possível examinar os requisitos atuais de CPU, memória e armazenamento do GitHub Enterprise Server na seção "Requisitos mínimos" de cada artigo em "Configurar uma instância do GitHub Enterprise Server".

Os arquivos do repositório para migrações agora incluem um campo is_archived.

ALTO: um Aplicativo GitHub pode usar um token de usuário para servidor com escopo definido a fim de ignorar a lógica de autorização do usuário e ajustar a escala de privilégios.

MÉDIO: o uso de um caractere de substituição Unicode da direita para a esquerda na lista de arquivos acessíveis para um Aplicativo GitHub pode obscurecer arquivos adicionais que o aplicativo poderia acessar.

BAIXO: conceder a um usuário a capacidade de ignorar as proteções de branch não permite mais que o usuário ignore o requisito de verificação de assinatura.

Os pacotes foram atualizados para as versões de segurança mais recentes.

Falha na instalação de um certificado TLS quando a cadeia de caracteres de assunto dele incluía caracteres UTF-8.

As execuções de configuração poderão falhar quando retry-limit ou retry-sleep-duration forem definidos manualmente por um administrador usando o ghe-config.

O comando ghe-find-insecure-git-operations não retornou todas as operações não seguras do Git após cada invocação.

Em alguns casos, o painel do monitor do console de gerenciamento não carregava corretamente.

Foi removido um link não funcional para exportar grafos do monitor do Console de Gerenciamento como uma imagem PNG.

Ao enviar um pacote de suporte para o GitHub Enterprise Support usando o ghe-support-upload, a opção -t não associará com êxito o pacote carregado ao tíquete especificado.

Em casos raros, uma atualização do GitHub Enterprise Server 3.3 para 3.4 modificaria incorretamente como os dados são armazenados, resultando em falhas durante futuras atualizações. Ao atualizar diretamente da 3.3 para essa versão, a falha não ocorrerá.

Ao usar uma URL de ponto de extremidade VPC como uma URL do AWS S3 para pacotes do GitHub, ocorria uma falha na publicação e instalação dos pacotes.

Os clones ou buscas do Git por SSH podem sofrer corrupção de dados para transferências com tamanho superior a 1 GB.

Um link de volta para as configurações de segurança da conta corporativa da instância poderá resultar em uma exibição incorreta.

Depois que um usuário excluía ou restaurava pacotes da interface da Web, as contagens de pacotes podiam ser renderizadas incorretamente.

Após a configuração bem-sucedida do Dependabot e dos emails de resumo de alerta, a instância não enviava emails de resumo.

Depois de atualizar para o GitHub Enterprise Server 3.5, as versões parecerão estar ausentes dos repositórios. Isso ocorreu enquanto as migrações de índice do Elasticsearch necessárias não foram concluídas com êxito. A interface do usuário das versões agora indica se está aguardando a conclusão das migrações de índice do Elasticsearch e links para a documentação sobre como observar o status e concluir imediatamente a migração.

Os fluxos de trabalho do GitHub Actions desabilitados manualmente em um repositório eram reativados se o repositório recebesse um push contendo mais de 2.048 confirmações ou se o branch padrão do repositório fosse alterada.

Ao exibir a diferença de uma solicitação de pull para um arquivo grande com muitas linhas entre as alterações, não era possível expandir a exibição de todas as alterações.

Se as proteções de branches foram habilitadas, a variável de ambiente GITHUB_REF_PROTECTED e os contextos github.ref_protected para as execuções do fluxo de trabalho do GitHub Actions foram definidos incorretamente como false.

Em instâncias que usam GitHub Advanced Security, a verificação de segredo revogou automaticamente tokens de acesso pessoal adicionados a repositórios públicos.

Os repositórios de pacotes exibiam erroneamente uma seção "Usado por".

After unlocking a repository for temporary access, a site administrator was unable to manage settings for security products in the repository.

Duplicate administrative SSH keys could appear in both the Management Console and the /home/admin/.ssh/authorized_keys file.

The site admin page for individual users at <code>http(s)://<em>HOSTNAME</em>/stafftools/users/<em>USERNAME</em>/admin</code> contained functionality not intended for GitHub Enterprise Server.

In some cases, running ghe-cluster-config-apply could replicate an empty configuration to existing nodes in a cluster.

In some cases, configuration runs started with ghe-config-apply did not complete, or returned a Container count mismatch error.

After updating a self-signed TLS certificate on a GitHub Enterprise Server instance, UI elements on some pages in the web interface did not appear.

The site admin bar at the top of the web interface contained a broken link to the SHA for the currently running version of the application.

In some cases, background tasks could stall due to a library that was used concurrently despite not being thread-safe.

Alerts from secret scanning for GitHub Advanced Security customers were missing in the web UI and REST API if a site administrator did not upgrade directly to GitHub Enterprise Server 3.4. The alerts are now visible.

When a user forked a repository into an organization, a long list of organizations would not render properly.

Generation of support bundles is faster as a result of parallelized log sanitization. For more information about support bundles, see "Fornecer dados para o GitHub Support."

APIs that contain the organization or org route now accept either the organization's slug or ID. Previously, the APIs only accepted slugs, which caused Link headers for GitHub Advanced Security endpoints to be inaccessible. For more information, see "Organizations" in the REST API documentation.

The enterprise audit log now includes more user-generated events, such as project.create. The REST API also returns additional user-generated events, such as repo.create. For more information, see "Como acessar o log de auditoria da sua empresa" and "Como usar a API do log de auditoria para sua empresa."

In some cases, cache replicas could reject some Git operations on recently updated repositories. For more information about repository caching, see "Sobre o cache do repositório."

CRITICAL: GitHub Enterprise Server's Elasticsearch container used a version of OpenJDK 8 that was vulnerable to an integer truncation issue when processing malicious XSLT stylesheets. The vulnerability is tracked as CVE-2022-34169.

HIGH: Previously installed apps on user accounts were automatically granted permission to access an organization on scoped access tokens after the user account was transformed into an organization account. This vulnerability was reported via the GitHub Bug Bounty program.

In some cases, GitHub Enterprise Server instances on AWS that used the r4.4xlarge instance type would fail to boot.

In some cases, UI elements within a pull request's Files changed tab could overlap.

When a custom dormancy threshold was set for the instance, suspending all dormant users did not reliably respect the threshold. For more information about dormancy, see "Sobre os usuários inativos."

When calculating committers for GitHub Advanced Security, it was not possible to specify individual repositories. For more information, see "Painel de administração do site."

In some cases, Elasticsearch's post-upgrade es:upgrade process could crash before completion.

The script for migration to internal repositories failed to convert the visibility for public repositories to internal or private. For more information about the migration, see "Migrando para repositórios internos."

Detection of GitHub Actions workflow files for the dependency graph was unavailable in GitHub Enterprise Server 3.5.0, 3.5.1, 3.5.2, and 3.5.3, but is now available in 3.5.4. For more information, see "Sobre o gráfico de dependências."

The ability to reopen dismissed Dependabot alerts was unavailable in GitHub Enterprise Server 3.5.0, 3.5.1, 3.5.2, and 3.5.3, but is now available in 3.5.4. For more information, see "Visualizando e atualizando alertas do Dependabot."

The ability to always suggest updates from the base branch to a pull request's HEAD was unavailable in GitHub Enterprise Server 3.5.0, 3.5.1, 3.5.2, and 3.5.3, but is now available in 3.5.4. For more information, see "Gerenciando sugestões para atualizar os branches do pull request."

The light high contrast theme was unavailable in GitHub Enterprise Server 3.5.0, 3.5.1, 3.5.2, and 3.5.3, but is now available in 3.5.4. For more information, see "Gerenciar as configurações de temas."

pre_receive_hook.rejected_push events were not displayed in the enterprise audit log.

MÉDIO: impede um ataque em que uma SSRF (falsificação de solicitação do lado do servidor) poderia forçar a ponte SVN (Subversion) a executar códigos remotos injetando dados arbitrários no Memcached.

MÉDIO: impede que um invasor execute código Javascript explorando uma vulnerabilidade de XSS (cross-site scripting) em elementos de IU suspensos na interface da Web do GitHub Enterprise Server.

Atualiza o Grafana para a versão 7.5.16, que lida com várias vulnerabilidades de segurança, incluindo CVE-2020-13379 e CVE-2022-21702.

Os pacotes foram atualizados para as versões de segurança mais recentes.

MÉDIO: uma vulnerabilidade de XSS armazenado identificada no GitHub Enterprise Server permitia a injeção de atributos arbitrários. Essa injeção foi bloqueada pela CSP (Política de Segurança de Conteúdo) do Github. Essa vulnerabilidade foi relatada por meio do Programa de Recompensas por Bugs do GitHub e recebeu a designação CVE-2022-23733. [Atualizado em 31-07-2022]

MÉDIO: uma vulnerabilidade envolvendo a desserialização de dados não confiáveis foi identificada no GitHub Enterprise Server que poderia levar à execução de código remota na ponte SVN (Subversion). Para explorar essa vulnerabilidade, um invasor precisaria obter acesso por meio de uma SSRF (solicitação forjada do lado do servidor) que permitiria que um invasor controlasse os dados que estão sendo desserializados. Essa vulnerabilidade foi relatada pelo Programa de Recompensas por Bugs do GitHub e foi designada como CVE-2022-23734.

Em alguns casos, o daemon collectd pode consumir memória em excesso.

Em alguns casos, os backups de arquivos de log rotacionados podem acumular e consumir armazenamento em excesso.

Após uma atualização para uma nova versão de recurso e a subsequente execução da configuração, o Elasticsearch pode registrar exceções excessivas durante a reconstrução de índices.

Em alguns casos em que um branch protegido exigia mais de uma revisão de aprovação, uma solicitação de pull poderia ser mesclada com um número menor que o necessário de revisões de aprovação.

O GitHub Enterprise Importer não migrou corretamente as configurações para projetos em repositórios.

Em instâncias que usam a autenticação LDAP, o prompt de autenticação para o modo sudo colocou incorretamente o cursor no campo de senha por padrão quando os campos de texto para nome de usuário e senha estavam visíveis.

O painel do administrador do site incluiu erroneamente uma opção para exportar um relatório listando usuários inativos.

O ponto de extremidade "Cobrança" da API de cobrança agora retorna cabeçalhos Link para fornecer informações sobre paginação.

O ponto de extremidade "Cobrança" da API de cobrança agora retorna o número correto de committers.totais.

Na barra lateral das configurações de uma organização, o item de navegação Arquivo morto não continha filhos.

Agora há suporte para o hipervisor VMware vSphere ESXi versão 7.0. [Atualizado em: 07/09/2022]

O utilitário de linha de comando ghe-set-password inicia os serviços necessários automaticamente quando a instância é inicializada no modo de recuperação.

As métricas para processos aqueduct em segundo plano são reunidas para o encaminhamento pelo Collectd e exibidas no console de gerenciamento.

O local do log de execução de configuração e migração do banco de dados, /data/user/common/ghe-config.log, agora é exibido na página que detalha uma migração em andamento.

MÉDIO: evita um ataque em que um parâmetro de cadeia de caracteres de consulta org pode ser especificado para uma URL do GitHub Enterprise Server que dá acesso a committers ativos de outra organização.

MÉDIO: garante que github.company.com e github-company.com não sejam avaliados por serviços internos como nomes de host idênticos, a fim de evitar um possível ataque de SSRF (falsificação de segurança do lado do servidor).

BAIXO: um invasor podia acessar o Console de Gerenciamento com um ataque de passagem de caminho via HTTP, mesmo que regras de firewall externas bloqueassem o acesso HTTP.

Os pacotes foram atualizados para as versões de segurança mais recentes.

Os arquivos dentro de um arquivo de artefatos não puderam ser abertos após a descompactação devido a permissões restritivas.

Em alguns casos, os pacotes enviados ao registro do contêiner não eram visíveis na IU da Web do GitHub Enterprise Server.

O console de gerenciamento parecia travado na tela Iniciar após a atualização de uma instância subprovisionada para o GitHub Enterprise Server 3.5.

Os tempos limite do Redis não interrompem mais as migrações de banco de dados durante a execução de ghe-config-apply.

Os processadores de trabalho em segundo plano ficariam presos em um estado parcialmente desligado, resultando em certos tipos de trabalhos em segundo plano (como varredura de código) parecendo travados.

Em alguns casos, os administradores do site não foram adicionados automaticamente como proprietários da empresa.

Os fluxos de trabalho do Actions que chamam outros fluxos de trabalho reutilizáveis não foram executados em um agendamento.

A resolução do Actions usando o GitHub Connect falhava brevemente após a alteração da visibilidade do repositório de público para interno.

Melhoria do desempenho das atualizações do Dependebot quando habilitadas pela primeira vez.

Aumente o número máximo de conexões simultâneas para os executores do Actions a fim de dar suporte ao objetivo de desempenho do GHES.

Os tempos limite de compilação e sincronização do GitHub Pages agora são configuráveis no Management Console.

Variável de ambiente adicionada para configurar os tempos limite do Redis.

Criar ou atualizar execuções de verificação ou conjuntos de verificação pode retornar 500 Internal Server Error caso o valor de determinados campos, como o nome, seja muito longo.

Melhoria do desempenho na guia "Arquivos alterados" das solicitações de pull quando o diff inclui muitas alterações.

A política de uso do cache do repositório do Actions não aceita mais um valor máximo menor que 1 para max_repo_cache_size_limit_in_gb.

Ao implantar nós do servidor de cache, agora é obrigatório descrever a topologia do datacenter (usando o argumento --datacenter) para cada nó no sistema. Esse requisito evita situações em que deixar a associação de datacenter definida como "padrão" faz com que as cargas de trabalho sejam balanceadas inadequadamente em vários datacenters.

O hipervisor do VMware vSphere ESXi 7.0 agora é compatível. [Atualizado em: 07-09-2022]

Os pacotes foram atualizados para as versões de segurança mais recentes.

Um script interno para validar nomes do host no arquivo de configuração do GitHub Enterprise Server retornaria um erro se a cadeia de caracteres do nome do host começasse com "." (caractere de ponto).

Nas configurações de HA em que o nome do host primário tiver mais que 60 caracteres, a configuração do MySQL falhará.

Quando GitHub Actions foi habilitado, mas o TLS estava desabilitado no GitHub Enterprise Server 3.4.1 e posteriores, a aplicação de uma atualização de configuração iria falhar.

O argumento --gateway foi adicionado ao comando ghe-setup-network para permitir a transmissão do endereço do gateway ao definir as configurações de rede por meio da linha de comando.

Os pontos de extremidade da API de cobrança do GitHub Advanced Security não estavam habilitados e acessíveis.

Os anexos de imagem excluídos retornavam um erro 500 Internal Server Error em vez de um erro 404 Not Found.

Em ambientes configurados com um servidor de cache de repositório, o comando ghe-repl-status mostrava incorretamente os gists como sub-replicados.

Os pontos de extremidade "Obter um commit" e "Comparar dois commits" na API Commit retornaria o erro 500 se o caminho de um arquivo no diff contivesse um caractere unicode codificado e de escape.

O cálculo de "máximo de committers na instância inteira" relatado no painel do administrador do site estava incorreto.

Uma entrada incorreta no banco de dados de réplicas de repositórios corrompeu o banco de dados ao executar uma restauração usando GitHub Enterprise Server Backup Utilities.

Um GitHub App não seria capaz de assinar o secret_scanning_alert_location evento webhook em uma instalação.

Não foi exibida a linha do tempo da atividade para alertas de digitalização de segredos.

Os repositórios excluídos não foram limpos após 90 dias.

A inclusão de métricas ao gerar um pacote de suporte de cluster foi otimizada.

Em configurações de alta disponibilidade em que o Elasticsearch relatava um status amarelo válido, as alterações introduzidas em uma correção anterior bloqueavam o comando ghe-repl-stop e não permitiam a interrupção da replicação. O uso de ghe-repo-stop --force agora forçará a parada do Elasticsearch quando o serviço estiver nos status normal ou amarelo válido.

Agora há suporte para o hipervisor VMware vSphere ESXi versão 7.0. [Atualizado em: 07-09-2022]

Você agora pode configurar uma lista de permissão de endereços IP que podem acessar serviços de aplicativo em sua instância do servidor GitHub Enterprise enquanto o modo de manutenção está habilitado. Os administradores que visitam a interface Web da instância de um endereço IP permitido podem validar a funcionalidade da instância após a manutenção e antes de desabilitar o modo de manutenção. Para obter mais informações, confira "Habilitar e programar o modo de manutenção".

Com funções de repositórios personalizados, as organizações agora têm um controle mais granular sobre as permissões de acesso do repositório que podem conceder aos usuários. Para obter mais informações, confira "Como gerenciar funções de repositório personalizadas de uma organização".

Uma função de repositórios personalizados é criada por um proprietário da organização e está disponível em todos os repositórios nessa organização. Cada função pode receber um nome personalizado e uma descrição. Pode ser configurado de um conjunto de mais de 40 permissões refinadas. Quando elas são criadas, os administradores de repositório podem atribuir uma função personalizada a qualquer usuário, equipe ou colaborador externo no repositório.

Funções personalizadas de repositório podem ser criadas, exibidas, editadas e excluídas por meio da nova guia Funções de repositório nas configurações de uma organização. No máximo 3 funções personalizadas podem ser criadas dentro de uma organização.

As funções de repositórios personalizados também têm suporte nas APIs REST do servidor GitHub Enterprise. A API das organizações podem ser usadas para listar todas as funções de repositórios personalizados em uma organização, e as APIs existentes para conceder acesso ao repositório para indivíduos e equipes foram estendidas para dar suporte a funções de repositórios personalizados. Para saber mais, confira "Organizações" na documentação da API REST.

O registro do Contêiner do GitHub (GHCR) agora está disponível no GitHub Enterprise Server 3.5 como beta público, oferecendo aos desenvolvedores a capacidade de publicar, baixar e gerenciar contêineres. O suporte ao contêiner dos pacotes do GitHub implementa os padrões de OCI para hospedar imagens do Docker. Para saber mais, confira "Registro de contêiner do GitHub".

A versão do Dependabot e as atualizações de segurança agora estão em disponibilidade geral no GitHub Enterprise Server 3.5. Todos os ecossistemas populares e os recursos que funcionam nos repositórios do GitHub.comagora podem ser configurados na sua instância do GitHub Enterprise Server. O Dependabot no GitHub Enterprise Server requer o GitHub Actions, um pool de executores auto-hospedados do Dependabot, o GitHub Connect habilitado e o Dependabot habilitado por um administrador. Para saber mais, confira "Configurar as atualizações do Dependabot".

Agora você pode analisar como sua equipe funciona, entender o valor que você obtém com o GitHub Enterprise Server e nos ajudar a aprimorar nossos produtos revisando os dados de uso de sua instância e compartilhando esses dados agregados com o GitHub. Você pode usar suas próprias ferramentas para analisar seu uso ao longo do tempo baixando seus dados em um CSV ou arquivo JSON ou acessando-o usando a API REST. Para ver a lista de métricas de agregação coletadas, confira "Sobre as estatísticas do servidor". Os dados das estatísticas do servidor não incluem dados pessoais ou conteúdo do GitHub, como código, problemas, comentários ou conteúdo de solicitações de pull. Para compreender melhor como os dados de estatísticas do servidor são armazenados e protegidos, confira "Segurança do GitHub". Para saber mais sobre as estatísticas do servidor, confira "Analisar como sua equipe trabalha com as estatísticas do servidor". Esse recurso está disponível na versão beta pública.

Os administradores do site agora podem habilitar e configurar um limite de taxa para o GitHub Actions. Por padrão, o limite de taxa está desabilitado. Quando os trabalhos do fluxo de trabalho não puderem ser atribuídos a um executor disponível, eles aguardarão em uma fila até que um executor esteja disponível. No entanto, se o GitHub Actions experimentar uma alta carga sustentada, a fila pode acumular mais rápido do que esvaziar e o desempenho da instância do GitHub Enterprise Server pode degradar. Para evitar isso, um administrador pode configura um limite de taxa. Quando o limite de taxa é excedido, podem ocorrer falhas imediatas em execuções adicionais de fluxo de trabalho em vez de serem colocadas na fila. Assim que a taxa tiver se estabilizado abaixo do limite, novas execuções podem ser enfileiradas novamente. Para obter mais informações, consulte "Configuração de limites de taxas".

O GitHub Actions no GitHub Enterprise Server agora dá suporte a OIDC para implantações seguras nos provedores de nuvem, que usa tokens de curta duração que são automaticamente rotacionados para cada implantação. O OIDC habilita as seguintes funcionalidades.

• Autenticação contínua entre provedores de nuvem e o GitHub Enterprise Server sem a necessidade de armazenar segredos de nuvem de longa duração na instância
• Os administradores de nuvem podem contar com os mecanismos de segurança de um determinado provedor de nuvem para garantir que os fluxos de trabalho do GitHub Actions tenham acesso mínimo aos recursos da nuvem. Não há duplicação de gerenciamento de segredos entre o GitHub Enterprise Server e a nuvem.

Para saber mais, confira "Proteção de implantações".

O suporte para o GitHub Actions em repositórios internos está em disponibilidade geral para organizações em sua instância do GitHub Enterprise Server. Você pode utilizar a automação do Innersource compartilhando ações em repositórios internos. Você pode gerenciar as configurações de um repositório ou usar a API REST para permitir o acesso a fluxos de trabalho em outros repositórios dentro da organização ou em qualquer organização na instância. Para saber mais, confira "Compartilhar ações e fluxos de trabalho com sua empresa", "Gerenciar as configurações do GitHub Actions para um repositório" e "Permissões do Actions" na documentação da API REST.

Você agora pode usar o armazenamento em cache de dependência para acelerar seus fluxo de trabalho do GitHub Actions. Para armazenar em cache as dependências de um trabalho, inclua a ação actions/cache a fim de criar um cache com uma chave exclusiva. Você pode compartilhar caches em todos os fluxos de trabalho no mesmo repositório. Esses fluxos de trabalho podem em seguida restaurar o cache e executar mais rapidamente.

Os usuários do Actions também podem usar nossas APIs de cache para:

• Defina a política corporativa para o intervalo de tamanho de cache permitido por repositório.
• Consulte o uso do cache em cada repositório e confira se o tamanho total de todos os caches está atingindo o limite máximo.
• Aumente o tamanho máximo do cache em um repositório dentro dos limites corporativos permitidos, com base nos respectivos requisitos de cache.
• Monitore o uso agregado de cache no nível da organização ou da empresa.

O armazenamento de blob externo que está configurado dentro da conta da sua empresa agora será compartilhado em todos os artefatos de fluxo de trabalho, logs e também os caches. Para obter mais informações, confira "Como armazenar dependências em cache para acelerar os fluxos de trabalho".

Agora você pode configurar o GitHub Enterprise Server para assinar confirmações automaticamente na interface da Web, como ao editar um arquivo o mesclar uma solicitação de pull. Confirmações assinadas aumentam a confiança de que as alterações vêm de fontes confiáveis. Esse recurso permite que a configuração de proteção de branch Exigir commits assinados impeça a entrada de commits não assinados em um repositório e autorize a entrada de commits assinados, mesmo aqueles feitos na interface da Web. Para obter mais informações, confira "Configurar a assinatura de commit da Web".

Para os clientes que sincronizam automaticamente o uso da licença entre o GitHub Enterprise Server e o GitHub Enterprise Cloud usando o GitHub Connect, agora é possível fazê-lo de maneira independente da sincronização semanal automática. Esse recurso também relata o status do trabalho de sincronização. Para obter mais informações, confira "Como sincronizar o uso da licença entre o GitHub Enterprise Server e o GitHub Enterprise Cloud."

Os fluxos de trabalho reutilizáveis estão agora em disponibilidade geral. O fluxos de trabalho reutilizáveis ajudam a reduzir a duplicação permitindo que você reutilize um fluxo de trabalho inteiro como se ele fosse uma ação. Com o lançamento da disponibilidade geral, um número de melhorias agora estão disponíveis para o GitHub Enterprise Server. Para obter mais informações, confira "Como reutilizar fluxos de trabalho".

• É possível utilizar saídas para transmitir dados de fluxos de trabalho reutilizáveis para outros trabalhos no fluxo de trabalho do chamador.
• É possível transmitir segredos de ambiente para fluxos de trabalho reutilizáveis.
• O log de auditoria inclui informações sobre quais fluxos de trabalho reutilizáveis são usados.
• Os fluxos de trabalho reutilizáveis que estão no mesmo repositório que o repositório de chamada podem ser referenciados com apenas o caminho e o nome do arquivo (PATH/FILENAME). O fluxo de trabalho chamaod será da mesma confirmação que o fluxo de trabalho do chamador.

Agora você tem mais controle sobre quando seus executores auto-hospedados realizam atualização de software. Se você especificar o sinalizador --disableupdate para o executor, ele não tentará executar uma atualização automática de software quando uma versão mais recente do executor estiver disponível. Isso permite que você atualize o executor auto-hospedado quando desejar, e é especialmente conveniente se ele estiver em um contêiner.

Para garantir a compatibilidade com o serviço do GitHub Actions, você precisará atualizar manualmente o executor dentro de 30 dias em que uma nova versão estiver disponível. Para saber como instalar a versão mais recente do executor, confira as instruções de instalação da versão mais recente no repositório do executor.

Os proprietários da organização agora podem aumentar a segurança de fluxos de trabalho de CI/CD em executores auto-hospedados escolhendo quais fluxos de trabalho podem acessar um grupo de executor. Anteriormente, qualquer fluxo de trabalho em um repositório, como um rotulador de problema, poderia acessar os executores auto-hospedados disponíveis para uma organização. Para saber mais, confira "Gerenciar o acesso a executores auto-hospedados usando grupos" e o Blog do GitHub.

Você agora pode controlar se o GitHub Actions pode aprovar solicitações de pull. Esse recurso impede que um usuário do GitHub Actions atenda ao requisito de proteção de ramificação "Aprovações obrigatórias" e mescle uma alteração que não foi revisada por outro usuário. Para evitar a interrupção dos fluxos de trabalho existentes, a opção Permitir que as revisões do GitHub Actions sejam contabilizadas com relação à aprovação necessária está habilitada por padrão. Os proprietários da organização podem desabilitar o recurso nas configurações do GitHub Actions da organização. Para obter mais informações, confira "Como desabilitar ou limitar o GitHub Actions na sua organização".

Você agora pode executar novamente apenas trabalhos com falha ou um trabalho individual em uma execução de fluxo de trabalho do GitHub Actions. Para mais informações, confira "Como reexecutar fluxos de trabalho e trabalhos".

O grafo de dependência agora detecta arquivos YAML para fluxos de trabalho do GitHub Actions. O GitHub Enterprise Server exibirá os arquivos de fluxo de trabalho na seção do gráfico de dependência da guia Insights. Os repositórios que publicam ações também poderão ver o número de repositórios que dependem dessa ação pelo controle "Usado por" na página inicial do repositório. Para obter mais informações, confira "Sobre o grafo de dependência".

• Observação: esse recurso não estava disponível no GitHub Enterprise Server 3.5.0, 3.5.1, 3.5.2 e 3.5.3. O recurso está disponível na versão 3.5.4 e posterior. [Atualizado em: 08-16/2022]

Os clientes da Segurança Avançada do GitHub agora podem exibir uma visão geral de alertas de segurança no nível empresarial. A nova guia Segurança no nível da empresa fornece uma visão centrada no repositório dos riscos de segurança do aplicativo, bem como uma visão centrada em alertas de todos os alertas de verificação de segredos. Para obter mais informações, confira "Sobre a visão geral de segurança".

A visão geral dos alertas de segurança no nível da organização agora está em disponibilidade geral. Os clientes da Segurança Avançada do GitHub podem usar a visão geral de segurança para exibir uma visão centrada no repositório dos de segurança do aplicativos, ou uma visão centrada em alertas de toda a verificação de código, o Dependabot e os alertas de verificação de segredos para todos os repositórios em uma organização. Para obter mais informações, confira "Sobre a visão geral de segurança".

A verificação de código agora detecta um número maior de CWEs e a verificação de código do CodeQL dá suporte completo aos recursos de linguagem padrão nas seguintes versões de linguagem.

• C# 10 / .NET 6
• Python 3.10
• Java 17
• TypeScript 4.5

Para saber mais, confira o Blog do GitHub.

Os clientes do GitHub Advanced Security agora podem exibir alertas de verificação de código na guia Segurança de uma organização. Essa exibição está disponível para proprietários de organizações e membros de equipes com a função de gerente de segurança. Para obter mais informações, confira "Sobre a visão geral de segurança".

Os usuários agora podem recuperar alertas de verificação de código para uma organização na sua instância do GitHub Enterprise Server pela API REST. Este novo ponto de extremidade da API complementa o ponto de extremidade para repositórios existente. Para saber mais, confira Verificação de código na documentação da API REST.

O GitHub Enterprise Server agora pode bloquear os pushes em que um token é detectado com alta confiança. Os desenvolvedores podem ignorar o bloqueio fornecendo detalhes de por que o segredo precisa ser confirmado por uma interface do usuário da Web. Para obter mais informações, confira "Como proteger os pushes com a verificação de segredos".

Os clientes de Segurança Avançada do GitHub agora podem realizar simulações personalizadas de padrões de verificação de segredos na organização ou no nível do repositório. Simulações permitem que pessoas com acesso de proprietário ou administrador revisem e ajustem os padrões antes de publicá-los e gerar alertas. É possível compor um padrão e, em seguida, usar Salvar e realizar simulação para recuperar os resultados. As verificações normalmente levam apenas alguns segundos, mas o GitHub Enterprise Server também notificará os proprietários da organização ou administradores do repositório por email quando os resultados da simulação estiverem prontos. Para saber mais, confira "Sobre a verificação de segredos" e "Definir padrões personalizados para a verificação de segredos".

O log de auditoria agora inclui eventos associados aos padrões personalizados de verificação de segredos. Esses dados ajudam os clientes do GitHub Advanced Security a entender as ações realizadas nos padrões personalizados no nível do repositório, da organização ou da empresa para auditorias de segurança e conformidade. Para saber mais, confira "Rever o log de auditoria da organização" ou "Rever os logs de auditoria da empresa".

Você agora pode configurar duas novas permissões para verificação de segredos ao gerenciar funções de repositório personalizadas.

• Exibir os resultados da verificação de segredos
• Ignorar ou reabrir os resultados da verificação de segredos

Para saber mais, confira "Gerenciar as funções personalizadas de repositório para uma organização".

Os clientes da Segurança Avançada do GitHub agora podem habilitar a verificação de segredos para repositórios arquivados por meio da interface do usuário e da API. Para saber mais, confira "Sobre a verificação de segredos", "Sobre os repositórios arquivados" e "Repositórios" na documentação da API REST.

Os clientes da Segurança Avançada do GitHub que usam verificação de segredos agora podem optar por receber um webhook cada vez que um segredo for detectado em uma nova localização. O evento de webhook secret_scanning_alert_location inclui detalhes de localização, como o SHA do commit e o alerta associado para a detecção. Uma localização é criada para cada novo caminho de arquivo que contém o segredo detectado. Para obter mais informações, confira "Eventos e cargas do webhook".

Os clientes do GitHub Advanced Security agora podem exibir os alertas do Dependabot na guia Segurança de uma organização. Essa exibição está disponível para proprietários de organizações e membros de equipes com a função de gerente de segurança. Para obter mais informações, confira "Sobre a visão geral de segurança".

Você agora pode configurar duas novas permissões para alertas do Dependabot ao gerenciar funções de repositório personalizadas.

• Exibir alertas do Dependabot
• Ignorar ou reabrir alertas do Dependabot

Para saber mais, confira "Gerenciar as funções personalizadas de repositório para uma organização".

Você agora pode reabrir alertas ignorados do Dependabot por meio da página da interface do usuário para um alerta fechado. Isso não afeta solicitações de pull do Dependabot ou a API do GraphQL. Para saber mais, confira "Sobre os alertas do Dependabot".

• Observação: esse recurso não estava disponível no GitHub Enterprise Server 3.5.0, 3.5.1, 3.5.2 e 3.5.3. O recurso está disponível na versão 3.5.4 e posterior. [Atualizado em: 08-16/2022]

Os usuários de atualizações de versão do Dependabot agora podem atualizar de maneira proativa dependências para projetos do Flutter ou Dart que usam o gerenciador de pacotes do Pub.

Para testar as atualizações de versão em seu próprio repositório Dart ou Flutter, adicione o arquivo de configuração a seguir em .github/dependabot.yaml. Observe os sinalizadores package-ecosystem: "pub" e enable-beta-ecosystems: true.

version: 2
enable-beta-ecosystems: true
updates:
  - package-ecosystem: "pub"
    directory: "/"
    schedule:
      interval: "weekly"

O novo objeto DependabotUpdate do GraphQL permite exibir informações sobre o que acontece com as atualizações de segurança do repositório. Quando o GitHub Enterprise Server detecta que uma dependência em seu repositório está vulnerável, o Dependabot tentará abrir uma solicitação de pull para atualizar essa dependência para uma versão não-vulnerável. Você agora pode ver a solicitação de pull que corrige a vulnerabilidade. Em alguns casos, o Dependabot não consegue abrir uma solicitação de pull. Anteriormente, a mensagem de erro gerada pelo Dependabot era visível somente na seção "Alertas do Dependabot" da guia Segurança. Agora, se o Dependabot encontrar um erro ao tentar abrir uma solicitação de pull para um alerta de segurança, será possível determinar o motivo usando a API do GraphQL. Para saber mais, confira "Objetos" na documentação da API do GraphQL.

Você agora pode exibir alertas corrigidos do Dependabot com a API do GraphQL. Você também pode acessar e filtrar por estado, além de por um identificador numérico exclusivo, e pode filtrar por estado no objeto de alerta de vulnerabilidade. Os campos a seguir agora existem para um RepositoryVulnerabilityAlert.

• number
• fixed_at
• fix_reason
• state

Para saber mais, confira "Objetos" na documentação da API do GraphQL.

Os eventos relacionados ao Git a seguir agora podem aparecer no log de auditoria da empresa. Se você habilitar o recurso e definir um período de retenção do log de auditoria, os novos eventos estarão disponíveis para pesquisa por meio da interface de usuário e da API, ou exportação via JSON ou CSV.

• git.clone
• git.fetch
• git.push

Devido ao grande número de eventos Git registrados, recomendamos monitorar o armazenamento de arquivos da sua instância e examinar suas configurações de alerta relacionadas. Para obter mais informações, confira "Como configurar o log de auditoria da sua empresa".

Essa versão inclui melhorias ao CODEOWNERS.

• Erros de sintaxe agora aparecem ao exibir um arquivo do CODEOWNERS pela Web. Anteriormente, quando uma linha em um arquivo do CODEOWNERS tinha um erro de sintaxe, o erro seria ignorado ou, em alguns casos, determinar a falha de carregamento do arquivo do CODEOWNERS inteiro. Os aplicativos do GitHub e o Actions podem acessar a mesma lista de erros usando novas APIs REST e GraphQL. Para saber mais, confira "Repositórios" na documentação da API REST e "Objetos" na documentação da API do GraphQL.
• Depois que alguém cria uma solicitação de pull ou envia novas alterações a uma solicitação de pull de rascunho, todos os proprietários de código que serão solicitados para revisão agora são listados na solicitação de pull em "Revisores". Esse recurso dá a você uma visão prévia de quem será solicitado a revisar assim que a solicitação de pull for marcada como pronta para revisão.
• Comentários em arquivos CODEOWNERS agora podem aparecer no final de uma linha, não somente em linhas dedicadas.

Para obter mais informações, confira "Sobre os proprietários de código".

O botão Atualizar branch na página de solicitação de pull permite atualizar o branch da solicitação de pull com as alterações mais recentes do branch base. Isso é útil para verificar se suas alterações estão compatíveis com a versão atual da ramificação de base antes de mesclar. Duas melhorias agora dão a você mais maneiras de manter sua ramificação atualizada.

• Quando o branch de tópico da solicitação de pull está desatualizado com o branch base, agora é possível atualizá-lo fazendo a troca de base na versão mais recente do branch base. Trocar a base aplica as alterações da sua ramificação na versão mais recente da ramificação de base, resultando em uma ramificação com um histórico linear já que nenhuma confirmação de mesclagem foi criada. Para atualizar fazendo a troca de base, clique no menu suspenso ao lado do botão Atualizar branch, selecione Atualizar com troca de base e escolha Trocar base do branch. Anteriormente, Atualizar branch realizava uma mesclagem tradicional que sempre resultava em um commit de mesclagem no branch de solicitação de pull. Essa opção ainda está disponível, mas agora você tem a escolha. Para obter mais informações, confira "Como manter sua solicitação de pull em sincronia com o branch base".

• Uma nova configuração de repositório permite que o botão Atualizar branch esteja sempre disponível quando o branch de tópico de uma solicitação de pull não está atualizado com o branch base. Anteriormente, esse botão só ficava disponível quando a configuração de proteção de branch Exigir que os branches sejam atualizados antes da mesclagem estava habilitada. Pessoas com acesso de administrador ou responsável pela manutenção podem gerenciar a configuração Sempre sugerir a atualização de branches de solicitação de pull na seção Solicitações de pull das configurações do repositório. Para saber mais, confira "Gerenciar sugestões de atualização de branches de solicitações de pull".

  • Observação: esse recurso não estava disponível no GitHub Enterprise Server 3.5.0, 3.5.1, 3.5.2 e 3.5.3. O recurso está disponível na versão 3.5.4 e posterior. [Atualizado em: 08-16/2022]

Você agora pode configurar cabeçalhos de HTTP personalizados que se aplicam a todos os sites de páginas do GitHub servidas de sua instância do GitHub Enterprise Server. Para saber mais, confira "Configurar o GitHub Pages para sua empresa".

Agora é possível ignorar as revisões na exibição de acusação criando um arquivo .git-blame-ignore-revs na raiz do repositório. Para saber mais, confira "Exibir um arquivo".

Um tema claro de alto contraste, com maior contraste entre os elementos de primeiro plano e de fundo, agora está em disponibilidade geral. Para obter mais informações, confira "Como gerenciar suas configurações de tema".

• Observação: esse recurso não estava disponível no GitHub Enterprise Server 3.5.0, 3.5.1, 3.5.2 e 3.5.3. O recurso está disponível na versão 3.5.4 e posterior. [Atualizado em: 08-16/2022]

Os proprietários de repositório agora podem configurar regras de proteção de marcação para proteger as marcações de um repositório. Assim que estiverem protegidas por uma regra de proteção de marcação, as marcações correspondentes a um padrão de nome especificado podem somente ser criadas e excluídas por usuários com a função de manutenção ou administrador no repositório. Para obter mais informações, confira "Como configurar regras de proteção de marca".

No GitHub Mobile para iOS 1.80.0 e posterior, os usuários agora podem editar arquivos dentro da ramificação de tópico de uma solicitação de pull. O suporte para edição de arquivos chegará ao GitHub Mobile para Android em uma versão futura. [Atualizado em: 2022-09-13]

Agora é possível para os aplicativos do GitHub carregarem ativos de versão.

Os requisitos mínimos de armazenamento raiz e memória aumentaram para o GitHub Enterprise Server 2.10 e 3.0 e agora são impostos a partir do 3.5.0.

• Na versão 2.10, o requisito mínimo de armazenamento raiz aumentou de 80 GB para 200 GB. A partir da versão 3.5.0, as verificações de simulação do sistema falharão se o armazenamento raiz for menor que 80 GB.
• Na versão 3.0, o requisito mínimo de memória aumentou de 16 GB para 32 GB. A partir da versão 3.5.0, as verificações de simulação do sistema falharão se o sistema tiver menos de 28 GB de memória.

Para obter mais informações, confira os requisitos mínimos para cada plataforma de implantação com suporte em "Configurar uma instância do GitHub Enterprise Server". [Atualizado em: 2022-06-20]

Agora há suporte para o hipervisor VMware vSphere ESXi versão 7.0. [Atualizado em: 2022-09-07]

Para usar o fluxo de autorização de dispositivo para OAuth e aplicativos do GitHub, você deverá habilitar manualmente o recurso. Essa alteração reduz a probabilidade de aplicativos serem usados em ataques de phishing contra usuários do GitHub Enterprise Server garantindo que os integradores estejam cientes dos riscos e façam uma escolha consciente de dar suporte a essa forma de autenticação. Se você for proprietário de ou gerenciar um aplicativo OAuth ou GitHub e quiser usar o fluxo de dispositivo, você poderá habilitá-lo para seu aplicativo por meio da página de configurações do aplicativo. Os pontos de extremidade da API de fluxo do dispositivo responderão com o código de status 400 para aplicativos que não habilitaram esse recurso. Para obter mais informações, confira "Como autorizar aplicativos OAuth".

A página de alerta da verificação de código agora sempre mostra o status de alerta e as informações para a ramificação padrão. Há um novo painel "Ramificações afetadas" na barra lateral onde se pode ver o status do alerta em outras ramificações. Se o alerta não existir em sua ramificação padrão, a página de alerta mostrará o status como "Em ramificação" ou "Em solicitação de pull" para a localização em que o alerta foi visto pela última vez. Essa melhoria facilita o entendimento do status de alertas que foram introduzidos em sua base de código. Para obter mais informações, confira "Sobre os alertas da verificação de código".

A página da lista de alertas não é alterada e pode ser filtrada por branch. Você pode usar a API de verificação de código para recuperar mais informações detalhadas de ramificação para alertas. Para saber mais, confira "Verificação de código" na documentação da API REST.

A verificação de código agora mostra os detalhes da origem da análise de um alerta. Se um alerta tiver masi de uma origem da análise, ele será mostrado na barra lateral "Ramificações afetadas" e na linha do tempo de alertas. Você pode passar o mouse sobre o ícone de origem da análise na barra lateral "Ramificações afetadas" para ver o status de alerta em cada origem da análise. Se um alerta tiver apenas uma única origem de análise, nenhuma informação sobre as origens de análise será exibida na página de alertas. Essas melhorias facilitarão o entendimento de seus alertas. Em específico, elas ajudarão a compreender os que têm várias origens de análise. Isso é especialmente útil para instalações com várias configurações de análise, como monorepos. Para obter mais informações, confira "Sobre os alertas da verificação de código".

Listas de repositórios de propriedade de um usuário ou organização agora têm uma opção adicional de filtro, "Modelos", facilitando o encontro de repositórios de modelos.

O GitHub Enterprise Server pode exibir vários formatos de imagens comuns, incluindo PNG, JPG, GIF, PSD e SVG, e fornece várias maneiras de comparar diferenças entre versões. Agora, ao analisar imagens adicionadas ou alteradas em uma solicitação de pull, as visualizações dessas imagens são mostradas por padrão. Anteriormente, você via uma mensagem indicando que os arquivos binários não poderiam ser mostrados e você precisaria alternar a opção "Exibir diff avançado". Para saber mais, confira "Trabalhar com arquivos sem código".

Novos gists agora são criados com um nome de branch padrão main ou com o nome de branch padrão alternativo definido nas configurações de usuário. Isso corresponde ao modo como outros repositórios são criados no GitHub Enterprise Server. Para saber mais, confira "Sobre branches" e "Gerenciar o nome de branch padrão para repositórios".

Gists agora somente mostram os 30 comentários mais recentes quando são exibidos primeiro. É possível clicar em Carregar comentários anteriores... para exibir mais. Isso permite que os gists tenham muitos comentários que apareçam mais rapidamente. Para saber mais sobre gists, confira "Editar e compartilhar conteúdos com gists".

As páginas de configuração para usuários, organizações, repositórios e equipes foram reformuladas, agrupando páginas de configurações semelhantes em seções para melhorar a arquitetura de informações e a descoberta. Para saber mais, confira o Log de alterações do GitHub.

Aumentar o foco ou passar o mouse sobre um rótulo agora exibe a descrição do rótulo em uma dica de ferramenta.

Criar e remover convites de repositório, seja por meio da API ou interface da Web, agora estão sujeitos a limites de taxa que podem ser habilitados em sua instância do GitHub Enterprise Server. Para saber mais, confira "Configurar limites de taxas".

O MinIO anunciou a remoção dos Gateways do MinIO a partir de primeiro de junho de 2022. Embora o Gateway do MinIO para NAS continue a ser um dos provedores de armazenamento com suporte para Github Actions e Github Packages, recomendamos passar para o suporte do MinIO LTS para garantir o suporte e correções de bugs do MinIO. Para saber mais sobre limites de taxa, confira "Remoção agendada do MinIO Gateway para GCS, Azure e HDFS no repositório minio/minio".

Após 3 de junho, o GitHub Connect não funcionará mais para instâncias que executam o GitHub Enterprise Server 3.1 ou versões anteriores, devido à alteração no formato dos tokens de autenticação do GitHub. Para continuar usando o GitHub Connect, atualize para o GitHub Enterprise Server 3.2 ou posterior. Para saber mais, confira o Blog do GitHub. [Atualizado em: 2022-06-14]

O executor do CodeQL foi preterido em favor do CLI do CodeQL. O GitHub Enterprise Server 3.4 e posterior não incluem mais o executor do CodeQL. Essa modificação apenas afeta quem usa a verificação de código do CodeQL em sistemas de CI/CD de terceiros. Os usuários do GitHub Actions não são afetados. O GitHub recomenda que os clientes migrem para o CLI do CodeQL, que é uma substituição de recursos completos para o executor do CodeQL e tem muitos recursos adicionais. Para saber mais, confira "Migrar do executor do CodeQL para a CLI do CodeQL".

O seletor de temas para o GitHub Pages foi removido das Configurações de páginas. Para saber mais sobre a configuração de temas para o GitHub Pages, confira "Adicionar um tema ao site do GitHub Pages usando o Jekyll".