GitHub AE release notes

Os proprietários corporativos podem ingressar em organizações no GitHub AE como membro ou proprietário na página Organizações da conta corporativa. Para obter mais informações, confira "Como gerenciar sua função em uma organização pertencente à sua empresa".

As funções de repositórios personalizadas estão em disponibilidade geral. Com as funções de repositórios personalizadas, os proprietários da organização já têm um controle mais granular sobre as permissões de acesso do repositório que podem conceder aos usuários. Também há suporte para as funções de repositórios personalizadas nas APIs REST. Para obter mais informações, confira "Como gerenciar funções de repositório personalizadas para uma organização" e "Organizações" na documentação da API REST.

Os proprietários corporativos podem impedir que os proprietários de organização convidem colaboradores para os repositórios do GitHub AE. Para obter mais informações, confira "Como impor uma política para convidar colaboradores para repositórios".

Os usuários podem optar por receber um evento de webhook que dispara quando alguém habilita ou desabilita um recurso de segurança ou análise de código para uma organização ou um repositório. Para saber mais, confira a seguinte documentação.

• "Eventos e cargas de webhook" na documentação do webhook
• "Como gerenciar as configurações de segurança e análise da sua organização"
• "Como gerenciar os recursos de segurança e de análise do seu repositório"

Os proprietários corporativos e os usuários podem ver os alertas de verificação de segredos e ignorar a proteção por push da verificação de segredos nos logs de auditoria da empresa e da organização e por meio da API REST. Para saber mais, confira a seguinte documentação.

• "Como proteger pushes com a verificação de segredos"
• "Auditar eventos de log para sua empresa"
• "Como revisar o log de auditoria da sua organização"
• "Verificação de segredo" na documentação da API REST

Os proprietários corporativos já podem configurar duas novas permissões para a verificação de segredos ao gerenciar as funções de repositórios personalizadas.

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

Para obter mais informações, confira "Como gerenciar funções de repositório personalizadas de uma organização".

Os usuários podem executar uma simulação dos padrões de verificação de segredos personalizados no nível da empresa, da organização ou do repositório, dependendo do acesso. As simulações permitem que os usuários 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 AE também notificará os usuários 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".

Os usuários podem habilitar a verificação de segredos para repositórios arquivados usando a interface do usuário ou a 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.

A verificação de segredos evita o vazamento de segredos no editor da Web. Para obter mais informações, confira "Como proteger os pushes com a verificação de segredos".

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 proprietários da organização e os gerentes de segurança podem ver os alertas da verificação de código na guia Segurança de uma organização. Para obter mais informações, confira "Sobre a visão geral de segurança".

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. Esse aprimoramento facilita o entendimento do status de alertas que foram introduzidos na 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. Os usuários podem posicionar o cursor sobre o ícone de origem da análise na barra lateral "Branches afetados" 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. Esses aprimoramentos facilitarão o entendimento dos alertas. Em particular, elas ajudarão os usuários a compreender aqueles 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".

Os usuários podem usar os parâmetros sort e direction na API REST ao recuperar alertas de verificação de segredos e classificá-los com base nos campos created ou updated do alerta. Os novos parâmetros estão disponíveis para toda a implantação do GitHub AE ou para organizações ou repositórios individuais. Para saber mais, confira a seguinte documentação.

• "Listar alertas de verificação de segredo para uma empresa"
• "Listar alertas de verificação de segredo para uma organização"
• "Listar alertas de verificação de segredo para um repositório"
• "Verificação de segredo" na documentação da API REST

Os usuários podem optar por receber um webhook que é disparado quando um segredo é detectado em um novo local. 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 usuários podem opcionalmente adicionar um comentário ao ignorar um alerta de verificação de código na interface do usuário da Web ou por meio da API REST. Os comentários de dispensa aparecem na linha do tempo do evento. Os usuários também podem adicionar ou recuperar um comentário de dispensa por meio da API REST. Para obter mais informações, confira "Triagem de alertas de verificação de código em solicitações de pull" e "Verificação de Código" na documentação da API REST.

Os usuários já podem recuperar os alertas de verificação de código para uma organização usando a API REST. Este novo ponto de extremidade da API complementa o ponto de extremidade para repositórios existente. Para saber mais, confira "Verificação do código" na documentação de API REST.

O conteúdo do repositório github/codeql-go foi movido para o repositório github/codeql, para ficar ao lado de bibliotecas semelhantes para todas as outras linguagens de programação suportadas pelo CodeQL. Agora é possível encontrar em um novo local as consultas, bibliotecas e o extrator CodeQL de código aberto para analisar bases de código escritas na linguagem de programação Go com as ferramentas de análise de código CodeQL do GitHub. Para obter mais informações, incluindo diretrizes sobre como migrar seus fluxos de trabalho existentes, confira github/codeql-go#741.

Os proprietários corporativos podem ver uma visão geral dos alertas do Dependabot na implantação do GitHub AE, incluindo uma exibição centrada no repositório dos riscos de segurança do aplicativo e uma exibição centrada nos alertas de todas as verificações de segredos e alertas do Dependabot. As exibições estão em versão beta e sujeitas a alterações. Para obter mais informações, confira "Como exibir a visão geral de segurança".

Os proprietários da organização e os gerentes de segurança podem ver os alertas do Dependabot na guia Segurança de uma organização. Para obter mais informações, confira "Sobre a visão geral de segurança".

Os usuários podem reabrir um alerta ignorado do Dependabot usando a interface do usuário da Web. Isso não afeta solicitações de pull do Dependabot ou a API do GraphQL. Para saber mais, confira "Sobre os alertas do Dependabot".

Os usuários já podem ver os alertas corrigidos no Dependabot com a API do GraphQL. Eles também podem acessar e filtrar por estado, além de um identificador numérico exclusivo, e 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 proprietários da organização e os gerentes de segurança podem usar a visão geral de segurança de uma organização para ter uma exibição centrada no repositório dos riscos de segurança do aplicativo ou uma exibição centrada nos alertas de toda a verificação de código, o Dependabot e os alertas da verificação de segredos em todos os repositórios de uma organização. Para obter mais informações, confira "Sobre a visão geral de segurança".

O GitHub Actions pode impor revisões de dependência nas solicitações de pull dos usuários ao verificar as dependências e avisar os usuários sobre vulnerabilidades de segurança associadas. A ação dependency-review-action é suportada por um novo ponto de extremidade da API que diferencia as dependências entre duas revisões. Para obter mais informações, confira "Sobre a revisão de dependência".

O grafo de dependência detecta arquivos YAML para fluxos de trabalho do GitHub Actions. O GitHub AE exibirá os arquivos de fluxo de trabalho na seção do grafo 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".

O grafo de dependência detecta os arquivos Cargo.toml e Cargo.lock para Rust. Esses arquivos serão exibidos na seção Grafo de dependência da guia Insights. Os usuários receberão alertas e atualizações do Dependabot para vulnerabilidades associadas às dependências do Rust. Os metadados de pacote, incluindo pacotes de mapeamento para repositórios, serão adicionados posteriormente. Para obter mais informações, confira "Sobre o grafo de dependência".

Se o GitHub Connect estiver habilitado para o GitHub AE, os usuários poderão contribuir com um aprimoramento para um aviso de segurança no Banco de Dados de Avisos do GitHub. Para contribuir, clique em Sugerir melhorias para esta vulnerabilidade enquanto visualiza os detalhes de um aviso. Para obter mais informações, consulte os seguintes artigos.

• "Como gerenciar o GitHub Connect"
• "Como procurar vulnerabilidades de segurança no Banco de Dados de Consultoria do GitHub" na documentação do GitHub Enterprise Cloud
• "Sobre os Avisos de Segurança do GitHub para repositórios" na documentação do GitHub Enterprise Cloud
• "Como editar os avisos de segurança no Banco de Dados de Consultoria do GitHub" na documentação do GitHub Enterprise Cloud

As pessoas que mantêm executores auto-hospedados já têm mais controle sobre quando os executores executam atualizações de software. Se você especificar o sinalizador --disableupdate para o executor, o executor não tentará executar uma atualização automática de software quando uma última versão do software do executor estiver disponível. Isso permite atualizações no executor auto-hospedado de acordo com um agendamento personalizado, e é especialmente conveniente se um executor auto-hospedado estiver em um contêiner. Para garantir a compatibilidade com o serviço do GitHub Actions, o software do executor precisa ser atualizado no período de até 30 dias em que uma nova versão do executor estiver disponível. Para obter mais informações sobre a instalação da última versão do executor, confira as instruções de instalação da última versão no actions/runner.

Ao usar o GitHub Actions, os proprietários corporativos e os administradores de repositório podem impedir que o Actions crie solicitações pull para reduzir o risco de mesclar uma alteração que não foi revisada por outra pessoa em uma ramificação protegida. Os proprietários da organização podiam habilitar essa restrição anteriormente. Para obter mais informações, consulte os seguintes artigos.

• "Como aplicar políticas para o GitHub Actions na sua empresa"
• "Como desabilitar ou limitar o GitHub Actions para sua organização"
• "Como gerenciar as configurações do GitHub Actions para um repositório"

Os proprietários da organização podem aumentar a segurança dos fluxos de trabalho de CI/CD em executores auto-hospedados escolhendo os fluxos de trabalho que podem acessar um grupo de executores. 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.

Os proprietários da organização podem 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".

Os usuários podem escrever um único fluxo de trabalho disparado por workflow_dispatch e workflow_call e usar o contexto inputs para acessar os valores de entrada. Anteriormente, as entradas workflow_dispatch estavam na carga do evento, o que aumentava a dificuldade para autores de fluxo de trabalho que queriam escrever um fluxo de trabalho que fosse reutilizável e acionado manualmente. Para fluxos de trabalho disparados por workflow_dispatch, as entradas ainda estão disponíveis no contexto github.event.inputs para manter a compatibilidade. Para obter mais informações, confira "Contextos".

Os usuários já podem executar novamente apenas os 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".

Para resumir o resultado de um trabalho, os usuários podem gerar Markdown e publicar o conteúdo como um resumo do trabalho. Por exemplo, após a execução de testes com o GitHub Actions, um resumo pode fornecer uma visão geral dos testes aprovados, reprovados ou ignorados, reduzindo potencialmente a necessidade de revisar toda a saída do log. Para obter mais informações, confira "Comandos de fluxo de trabalho do GitHub Actions".

Para diagnosticar de forma mais fácil as falhas de execução do trabalho durante uma nova execução do fluxo de trabalho, os usuários podem habilitar o log de depuração, que gera informações de saída sobre a execução e o ambiente de um trabalho. Para obter mais informações, confira "Executar novamente fluxos de trabalho e trabalhos" e "Como usar logs de execução de fluxo de trabalho".

Se você gerenciar executores auto-hospedados para o GitHub Actions, poderá garantir um estado consistente no próprio executor antes e depois da execução do fluxo ao definir os scripts a serem executados. Ao usar scripts, você não precisa mais exigir que os usuários incorporem manualmente essas etapas nos fluxos de trabalho. Os scripts pré e pós trabalho estão em versão beta e estão sujeitos a alterações. Para obter mais informações, confira "Como executar scripts antes ou depois de um trabalho".

Os proprietários da empresa podem configurar uma política para controlar se os nomes de usuário ou os nomes completos das pessoas são exibidos nos repositórios internos. Para obter mais informações, confira "Como impor políticas de gerenciamento de repositório na sua empresa".

Os proprietários da organização podem fixar um repositório no perfil da organização diretamente do repositório por meio do novo menu suspenso Fixar repositório.

Ao criar uma bifurcação, os usuários podem personalizar o nome da bifurcação. Para obter mais informações, confira "Criar um fork de um repositório".

Os usuários podem excluir uma ramificação associada a uma solicitação pull aberta. Para obter mais informações, confira "Como criar e excluir branches no seu repositório".

CODEOWNERS recebeu os aprimoramentos a seguir.

• Os erros de sintaxe já aparecem quando um arquivo CODEOWNERS é exibido na interface do usuário da 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".

Quando o usuário renomeia ou move um arquivo para um novo diretório, se pelo menos metade do conteúdo do arquivo for idêntico, o histórico de commit indica que o arquivo foi renomeado, semelhante ao git log --follow. Para obter mais informações, confira o Blog do GitHub.

Os usuários podem exigir uma implantação bem-sucedida de uma ramificação antes que alguém possa mesclar a solicitação de pull associada à ramificação. Para obter mais informações, confira "Sobre os branches protegidos" e "Como gerenciar uma regra de proteção de branch".

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

Os usuários podem ignorar as revisões na exibição de identificação criando um arquivo .git-blame-ignore-revs na raiz de um repositório. Para saber mais, confira "Exibir um arquivo".

Os usuários podem conceder exceções ao GitHub Apps para qualquer regra de proteção de ramificação compatível com as exceções. Para obter mais informações, confira "Sobre apps" e "Como gerenciar uma regra de proteção de branch".

Para as chaves de assinatura GPG públicas expiradas ou revogadas, o GitHub AE verifica as assinaturas de commits do Git e mostra os commits como verificados se o usuário fez o commit enquanto a chave ainda era válida. Os usuários também podem fazer upload de chaves GPG expiradas ou revogadas. Para obter mais informações, confira "Sobre a verificação de assinatura de commit".

Para afirmar que a confirmação está em conformidade com as regras e licenciamento que regem um repositório, agora os proprietários da organização e os administradores do repositório podem exigir que os desenvolvedores assinem as confirmações realizadas por meio da interface da web. Para obter mais informações, confira "Como gerenciar a política de aprovação de commit da sua organização" e "Como gerenciar a política de aprovação de commit do seu repositório".

Ao usar a árvore de arquivos localizada na guia Arquivos alterados de uma solicitação de pull, os usuários podem navegar pelos arquivos modificados, entender o tamanho e o escopo das alterações e se concentrar nas revisões. A árvore de arquivos aparece se uma solicitação de pull modificar pelo menos dois arquivos e a janela do navegador for suficientemente ampla. Para obter mais informações, confira "Como revisar as alterações propostas em uma solicitação de pull" e "Como filtrar arquivos em uma solicitação de pull".

Os usuários podem usar como padrão os títulos de solicitações de pull como a mensagem de confirmação para todas as mesclagens squash. Para obter mais informações, confira "Como configurar o squash de commit para solicitações de pull".

O botão Atualizar branch na página de solicitação de pull permite que os usuários atualizem o branch de uma solicitação de pull com as alterações mais recentes do branch base. Isso é útil para verificar se as alterações da solicitação de pull são compatíveis com a versão atual do branch base antes da mesclagem. Dois aprimoramentos fornecem mais maneiras de manter um branch atualizado.

• Quando o branch do tópico de uma solicitação de pull está desatualizado em relação ao branch base, os usuários já podem atualizar o branch fazendo a troca de base na última versão do branch base. A troca de base aplica as alterações do branch do tópico na última versão do branch base, resultando em um branch com um histórico linear já que nenhum commit de mesclagem foi criado. Para realizar a atualização fazendo a troca de base, clique no menu suspenso ao lado do botão Atualizar Branch, clique em Atualizar com troca de base e em 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 os usuários têm essa 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".

Ao visualizar os detalhes de uma versão específica, os usuários podem ver a data de criação de cada ativo da versão. Para obter mais informações, confira "Como ver as versões e as marcas do repositório".

Ao criar uma versão com notas de versão geradas automaticamente, os usuários podem ver a marca identificada como a versão anterior e selecionar uma marca diferente para especificar como a versão anterior. Para obter mais informações, confira "Notas sobre a versão geradas automaticamente".

Gists agora somente mostram os 30 comentários mais recentes quando são exibidos primeiro. Os usuários podem clicar em Carregar comentários anteriores… para ver mais detalhes. 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".

A edição do Markdown na interface da web foi aprimorada.

• Depois que o usuário seleciona o texto e cola uma URL, o texto selecionado se tornará um link Markdown da URL colada.
• Quando o usuário cola células de planilha ou tabelas HTML, o texto resultante será renderizado como uma tabela.
• Quando o usuário copia texto contendo links, o texto colado incluirá o link como um link Markdown.

Para obter mais informações, confira "Sintaxe básica de escrita e formatação".

Ao editar um arquivo Markdown na interface da web, se você clicar na guia Visualizar ela rolará automaticamente até o local na visualização que você estava editando. O local de rolagem é baseado na posição do cursor antes de você clicar na guia Visualizar.

Um tema claro de alto-contraste, com maior contraste entre os elementos de primeiro plano e de fundo, já está disponível. Para obter mais informações, confira "Como gerenciar suas configurações de tema".

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 AE 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 as versões. Durante a revisão das imagens adicionadas ou alteradas em uma solicitação de pull, as visualizações dessas imagens já são mostradas por padrão. Anteriormente, os usuários viam uma mensagem indicando que os arquivos binários não podiam ser mostrados e precisavam alternar a opção "Exibir comparação avançada". Para saber mais, confira "Trabalhar com arquivos sem código".

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 obter mais informações, confira o Log de alterações do GitHub.

Elementos interativos na interface da Web, como links e botões, mostram um contorno visível quando focados com o teclado, para ajudar os usuários a encontrar a posição atual na página. Além disso, quando focados, os campos de formulário têm um contorno de contraste mais elevado.

Colocar em foco ou posicionar o cursor sobre um rótulo já exibe uma dica de ferramenta com a descrição do rótulo.

Se um usuário atualizar a página ao criar um problema ou uma solicitação de pull, os destinatários, os revisores, os rótulos e os projetos serão preservados.

Para usar o fluxo de autorização de dispositivo para o OAuth e o GitHub Apps, os autores de aplicativos precisam habilitar o recurso manualmente. Essa alteração reduz a probabilidade de os aplicativos serem usados em ataques de phishing contra os usuários do GitHub AE, garantindo que os integradores estejam cientes dos riscos e façam uma escolha consciente de dar suporte a essa forma de autenticação. Os usuários que são proprietários ou administradores de um OAuth App ou de um GitHub App e desejam usar o fluxo de dispositivo podem habilitá-lo para um 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".

Os usuários com acesso de administrador a um repositório podem entender melhor quem tem acesso a ele, além de ver o nível de acesso de cada usuário e gerenciar mais facilmente esse acesso. Por exemplo, os usuários podem realizar as tarefas a seguir.

• Pesquisar todos os membros, equipes e colaboradores com acesso ao repositório.
• Exibir quando os membros têm atribuições de funções mistas, concedidas a eles diretamente como indivíduos ou indiretamente por meio de uma equipe: um novo aviso de "funções mistas" exibe a função de nível mais alto do usuário com acesso superior ao de uma das funções atribuídas.

Para obter mais informações, confira "Como gerenciar equipes e pessoas com acesso ao seu repositório".

Os proprietários corporativos agora podem mostrar links adicionais para colaboradores e membros da empresa em um rodapé personalizado. Para saber mais, confira "Configurar rodapés personalizados".

Os usuários podem reutilizar um fluxo de trabalho com uma única linha de configuração. Os fluxos de trabalho reutilizáveis economizam tempo e esforço de manutenção, eliminando a necessidade de copiar e colar definições de fluxo de trabalho nos repositórios. Eles estão em versão beta e sujeitos a alterações. Para obter mais informações, confira "Como reutilizar fluxos de trabalho".

A atualização da experiência de gerenciamento para executores auto-hospedados a torna mais simples e fornece uma visão geral aprimorada dos executores. Para saber mais, confira "Sobre os executores auto-hospedados" e "Gerenciar o acesso a executores auto-hospedados usando grupos".

O Dependabot agora compartilha segredos com o GitHub Actions quando uma execução de fluxo de trabalho é disparada, para que os usuários possam obter registros de pacotes privados nos pipelines de CI usando os segredos do Dependabot. Para obter mais informações, confira "Como gerenciar segredos criptografados do Dependabot".

Os usuários podem usar uma condicional if para impedir que etapas específicas em uma ação composta sejam executadas, a menos que uma condição seja atendida. Como etapas definidas em fluxos de trabalho, você pode usar qualquer contexto e expressão compatível para criar uma condicional. Para saber mais sobre ações compostas, confira "Criar uma ação composta".

Os usuários de um fluxo de trabalho podem obter uma experiência melhor ao especificar tipos de entrada para fluxos disparados manualmente. Os fluxos de trabalho agora dão suporte a choice, boolean e environment. Para obter mais informações, confira "Sintaxe de fluxo de trabalho do GitHub Actions".

O primeiro executor correspondente disponível no nível do repositório, da organização ou da empresa executará cada trabalho em todos os casos, o que significa que os trabalhos são enviados para executores auto-hospedados muito mais rapidamente, especialmente no caso de organizações e empresas com muitos executores. Anteriormente, ao executar um trabalho que exigia um executor auto-hospedado, o GitHub Actions procurava por um no repositório, na organização e na empresa, nessa ordem. Para saber mais, confira "Usar executores auto-hospedados em um fluxo de trabalho".

Os usuários podem indicar que uma ação JavaScript deve ser executada no Node.js 16 especificando runs.using como node16. O suporte para Node.js 16 complementa o suporte existente para Node.js 12. Os executores devem ter a versão 2.285.0 ou posterior do GitHub Actions Runner instalada. Para saber mais, confira "Sintaxe de metadados para o GitHub Actions" e o repositório actions/runner.

Os usuários podem adicionar, listar e remover rótulos de executores auto-hospedados usando a API REST. Para saber mais, confira "Executores auto-hospedados" na documentação da API REST.

Os usuários podem melhorar a segurança dos serviços e das ferramentas criadas com o Ruby usando a verificação de código do CodeQL. Para todas as versões comuns do Ruby até a 3.02 (incluindo essa versão), o CodeQL pode detectar problemas comuns, como injeção de SQL, ReDoS, injeção de comandos e argumentos do sistema operacional, expansão de entidade XML, XSS (script entre sites) refletido, XSS armazenado, desserialização não segura e credenciais embutidas em código. Para habilitar a análise do Ruby, os usuários devem atualizar um arquivo de fluxo de trabalho de verificação de código existente do CodeQL. O suporte do Ruby para CodeQL está na versão beta e sujeito a alterações. Para saber mais, confira "Configurar a verificação de código" e Documentação do CodeQL. Para saber mais sobre a verificação de código com o CodeQL, confira "Sobre a verificação de código com o CodeQL".

A análise do Python para CodeQL dá suporte a estruturas adicionais e pode detectar mais fontes potenciais de dados do usuário não confiáveis, as etapas pelas quais esses dados fluem e coletores potencialmente perigosos para os quais eles podem ser encaminhados. Para saber mais, confira "Linguagens e estruturas compatíveis" na documentação do CodeQL.

Os usuários podem recuperar detalhes de commit de segredos detectados em varreduras de repositório privado usando a API REST. O novo ponto de extremidade exibirá detalhes da primeira detecção de um segredo em um arquivo, incluindo o SHA de commit e a localização do segredo. Para saber mais, confira "Sobre a verificação de segredos" e "Verificação de segredos" na documentação da API REST.

A API de verificação de código inclui as melhorias a seguir.

• Os alertas incluem o carimbo de data/hora fixed_at, que representa a primeira vez em que não foram detectados em uma análise. Os usuários podem usar esses dados para entender melhor quando os alertas de verificação de código estão sendo corrigidos.
• É possível organizar de acordo com os resultados de alerta mais importantes por meio de sort e direction em created, updated ou number. Para saber mais, confira Verificação de código na documentação da API REST.
• Os alertas e a resposta do ponto de extremidade de alerta incluem um cabeçalho Last-Modified. Para saber mais, confira Last-Modified na documentação do Mozilla.
• As respostas em SARIF para análises de verificação de código incluem relatedLocations, que pode conter locais que não são o local principal do alerta. Para saber mais, confira a Especificação SARIF. Para saber mais, confira Verificação de código na documentação da API REST.
• O objeto da regra de alerta de resposta do webhook inclui dados help e tags. Para obter mais informações, confira "Eventos e cargas do webhook".

Proprietários de organizações e gerentes de segurança podem recuperar os resultados da verificação de segredos de repositórios privados no nível da empresa usando a API REST. Para saber mais, confira "Sobre a verificação de segredos" e "Verificação de segredos" na documentação da API REST.

Os usuários podem dispensar os alertas do Dependabot por meio da API do GraphQL. Para saber mais, confira "Mutações" na documentação da API do GraphQL.

O gráfico de dependência detecta as dependências do Python em repositórios que usam o gerenciador de pacotes Poetry. Essas dependências são detectadas nos arquivos de manifesto pyproject.toml e poetry.lock. Para obter mais informações, confira "Sobre o grafo de dependência".

Os desenvolvedores e pesquisadores de segurança podem usar o CodeQL para criar bancos de dados e analisar códigos em computadores equipados com chips de silício da Apple, como o M1. Tanto a CLI do CodeQL quanto a extensão do VS Code dão suporte ao silício da Apple. Para usar a CLI do CodeQL ou a extensão do VS Code no silício da Apple, os usuários devem instalar as ferramentas de desenvolvedor de linha de comando do Xcode e o Rosetta 2. O suporte do CodeQL para silício da Apple está na versão beta e sujeito a alterações.

• Para saber mais sobre a configuração da CLI do CodeQL em plataformas compatíveis, confira "Usar a CLI do CodeQL" na documentação do CodeQL.
• Para saber mais sobre o CodeQL, confira "Sobre o CodeQL" na documentação do CodeQL e "Sobre a verificação de código".

Os usuários da CLI do CodeQL 2.7.1 e posterior podem incluir ajuda de consulta em arquivos SARIF como Markdown, e o texto de ajuda aparecerá na IU de verificação de código do GitHub AE. Eles podem incluir ajuda de consulta como um arquivo Markdown com o mesmo nome do arquivo de consulta correspondente. Por exemplo, se o arquivo de consulta for MyCustomQuery.ql, o nome do arquivo de ajuda de consulta será MyCustomQuery.md. Para saber mais sobre a autoria de ajuda para consultas personalizadas do CodeQL, confira o guia de estilo de ajuda de consulta.

• Os usuários que não usam o GitHub Actions para CI/CD e verificação de código devem especificar a adição de ajuda de consulta ao executar o comando codeql database analyze incluindo o sinalizador --sarif-add-query-help. Para saber mais, confira "Analisar bancos de dados com a CLI do CodeQL" na documentação do CodeQL.

Os usuários podem cancelar a assinatura de todos os repositórios pertencentes a um determinado usuário ou organização. Para obter mais informações, confira "Como gerenciar suas assinaturas".

Os proprietários da organização podem cancelar a assinatura de notificações por email quando novas chaves de implantação são adicionadas aos repositórios pertencentes as respectivas organizações. Para obter mais informações, confira "Como configurar notificações".

A linha de assunto para notificações por email de problemas e solicitações de pull inclui "(Problema n° NUMBER)" ou "(PR #NUMBER)" para ajudar os usuários a distinguir facilmente entre os dois tipos de notificação.

O link Exibir no GitHub na parte inferior das notificações por email não está mais oculto por padrão no Gmail.

Os membros de uma organização agora podem exibir uma lista de proprietários da empresa. Sempre que um membro da organização receber uma solicitação para entrar em contato com o proprietário de uma empresa, um link direcionará o usuário para a lista. A lista também pode ser acessada usando o objeto Organization da API do GraphQL no ponto de extremidade enterpriseOwners. Para obter mais informações, confira "Como ver as funções das pessoas em uma organização".

Os usuários com acesso de administrador a um repositório podem renomear branches protegidos por regras de proteção de branch. Para saber mais, confira "Renomear um branch" e "Gerenciar uma regra de proteção de branch".

Em vez de permitir que todos ou nenhum usuário force o push, as pessoas com acesso de administrador a um repositório podem escolher quem pode forçá-lo nele. Para saber mais, confira "Sobre branches protegidos" e "Gerenciar uma regra de proteção de branch".

Os usuários com acesso de administrador a um repositório podem exigir que todas as alterações em um branch protegido sejam feitas usando uma solicitação de pull, mas sem a necessidade de revisões. Para saber mais, confira "Sobre branches protegidos" e "Gerenciar uma regra de proteção de branch".

Os usuários com acesso de administrador a um repositório podem permitir que usuários e equipes específicos ignorem os requisitos de solicitação de pull. Para obter mais informações, confira "Como gerenciar uma regra de proteção de branch".

Os usuários podem usar prefixos de caractere único para links automáticos personalizados. Os prefixos de links automáticos também permitem caracteres ., -, _, +, =, :, / e #, assim como caracteres alfanuméricos. Para obter mais informações, confira "Como configurar links automáticos para referenciar recursos externos".

Os usuários podem habilitar Notificar somente os membros da equipe solicitados independentemente de Habilitar atribuição automática nas configurações de revisão de código da equipe, a fim de permitir que os usuários solicitem a revisão da equipe, mas sem notificar sempre toda a equipe desnecessariamente. Para obter mais informações, confira "Como gerenciar as configurações de revisão de código para sua equipe".

A IU de versões foi aprimorada, fornecendo clareza sobre o que está incluído em uma determinada versão e reconhecimento para os colaboradores associados. A paginação foi aprimorada e uma nova funcionalidade de pesquisa está disponível.

Os usuários podem gerar automaticamente notas sobre a versão que incluem um resumo de todas as solicitações de pull de uma determinada versão. Para obter mais informações, confira "Notas sobre a versão geradas automaticamente".

Os usuários podem exibir renderizações de arquivos Markdown em gists. Ao criar ou editar um arquivo gist com a extensão de arquivo Markdown, .md, uma guia Pré-visualização ou Pré-visualizar alterações exibirá uma renderização Markdown do conteúdo do arquivo. Para obter mais informações sobre gists, confira "Editando e compartilhando conteúdo com gists".

Os usuários podem optar por usar uma fonte de largura fixa em campos Markdown, como comentários sobre problemas e solicitações de pull. Para saber mais, confira "Sobre criação e formatação no GitHub".

Os usuários podem especificar o tema para o qual uma imagem é exibida no Markdown. Para obter mais informações, confira "Sintaxe básica de escrita e formatação".

Os usuários podem criar rapidamente um link Markdown ao editar o texto em campos habilitados para Markdown, como comentários de problemas ou solicitação de pull, selecionando-o e colando uma URL.

Os links HTML que os usuários colam nos campos Markdown são convertidos automaticamente em links Markdown. Para colar links HTML como textos simples, pressione ⌘/ctrl + shift + v.

Os idiomas da direita para a esquerda são compatíveis nativamente em arquivos Markdown e comentários sobre problemas, solicitações de pull e discussões.

Os usuários podem definir um tamanho de guia preferencial. Todos os códigos no GitHub AE com guias serão renderizados usando o tamanho de guia preferencial. Para saber mais, confira "Gerenciar sua preferência de renderização de tamanho de guia".

Os usuários podem gerenciar atalhos de teclado com as novas configurações de acessibilidade do GitHub AE e optar por desabilitar os atalhos de teclas de caracteres que usam somente caracteres únicos, como s, g c e . (a tecla de ponto final). Para saber mais, confira "Gerenciar as configurações de acessibilidade".

Para garantir que todas as alterações sejam validadas pelo aplicativo pretendido, os usuários agora podem controlar em qual aplicativo do GitHub uma verificação de status obrigatória é fornecida. Se o status for fornecido por um aplicativo diferente ou por um usuário por meio de um status de commit, a mesclagem será impedida. As verificações de status obrigatórias existentes continuarão a aceitar o status de qualquer aplicativo, mas podem ser atualizadas para aceitar somente o status de um aplicativo específico. As verificações de status necessárias recém-adicionadas serão padronizadas para o aplicativo que relatou o status mais recentemente, mas é possível escolher um aplicativo diferente ou permitir que qualquer aplicativo forneça o status. Para saber mais, confira "Sobre branches protegidos" e "Editar uma regra de proteção de branch".

Proprietários de organização e usuários com acesso de administrador a um repositório podem disparar webhooks para escutar alterações nas regras de proteção de branch. Para obter mais informações, confira "Eventos e cargas do webhook".

A verificação de código e de segredo agora estão disponíveis para o GitHub AE. Para obter mais informações, confira "Sobre a varredura de código" e "Sobre a verificação de segredo."

Padrões personalizados para verificação de segredo agora estão disponíveis para o público geral. Para obter mais informações, confira "Definir padrões personalizados para a verificação de segredo".

Agora você pode encontrar todos os alertas de varredura de código associados à sua solicitação de pull com o novo filtro correspondente na página de alertas de varredura de código. A página de verificações de solicitação de pull mostra os alertas introduzidos em uma solicitação, mas não os alertas existentes no branch da solicitação de pull. O novo link "Visualizar todos os alertas de branch" na página de Verificações leva você à página de alertas de verificação de código com o filtro de solicitação pull específico já aplicado, para que você possa ver todos os alertas associados à solicitação. Isso é útil para gerenciar muitos alertas e ver informações mais detalhadas de alertas individuais. Para obter mais informações, confira "Como gerenciar alertas de verificação de código do seu repositório".

A Segurança Avançada do GitHub agora oferece uma visão empresarial dos riscos de segurança de aplicativos detectados pela verificação de código, por Dependabot e verificação secreta. A visão geral de segurança mostra o estado de habilitação dos recursos de segurança em cada repositório, assim como o número de alertas detectados.

Além disso, a visão geral de segurança lista todos os alertas de verificação de segredo no nível da organização. Visões semelhantes para alertas de verificação de código e Dependabot estão chegando em versões futuras. Para obter mais informações, confira "Sobre a visão geral de segurança".

O grafo de dependência agora está disponível no GitHub AE. O gráfico de dependência ajuda você a entender o software de código aberto do qual você depende para análise de manifestos de dependência verificados nos repositórios. Para obter mais informações, confira "Sobre o grafo de dependência".

Os alertas do Dependabot agora podem notificar sobre vulnerabilidades em suas dependências no GitHub AE. Você pode habilitar os alertas do Dependabot habilitando o grafo de dependência e o GitHub Connect, além de sincronizar vulnerabilidades do Banco de Dados de Avisos do GitHub. Esse recurso está na versão beta e sujeito a alterações. Para saber mais, confira "Sobre os alertas do Dependabot".

Depois de habilitar os alertas do Dependabot, os membros de sua organização receberão notificações sempre que uma nova vulnerabilidade que afete suas dependências for adicionada ao banco de dados consultivo do GitHub ou uma dependência vulnerável for adicionada ao manifesto. Os membros podem personalizar as configurações de notificação. Para saber mais, confira "Configurar notificações para % data variables.product.prodname_dependabot_alerts %}".

As organizações agora podem conceder às equipes permissão para gerenciar alertas e configurações de segurança em todos os repositórios. A função "gerente de segurança" pode ser aplicada à qualquer equipe e concede aos membros da equipe as seguintes permissões.

• Acesso de leitura em todos os repositórios da organização
• Acesso de gravação em todos os alertas de segurança na organização
• Acesso à guia de segurança no nível da organização
• Acesso de gravação às configurações de segurança no nível da organização
• Acesso de gravação às configurações de segurança no nível do repositório

Para obter mais informações, confira "Como gerenciar gerentes de segurança na sua organização".

O GitHub AE agora dá suporte a executores auto-hospedados efêmeros (trabalho único) e a um novo webhook workflow_job para facilitar o dimensionamento automático dos executores.

Os executores efêmeros são bons para ambientes autogerenciados em que cada trabalho é necessário para executar com uma imagem limpa. Depois que um trabalho é executado, o GitHub AE cancela automaticamente o registro de executores efêmeros, permitindo que você execute qualquer gerenciamento pós-tarefa.

É possível combinar executores efêmeros com o novo webhook workflow_job para escalar automaticamente executores auto-hospedados em resposta a solicitações de trabalho do GitHub Actions.

Para saber mais, confira "Dimensionamento automático com executores auto-hospedados" e "Conteúdo e eventos de webhook".

Você pode reduzir a duplicação em seus fluxos de trabalho usando a composição para fazer referência a outras ações. Anteriormente, as ações escritas em YAML só podiam usar scripts. Para saber mais, confira "Criar uma ação composta".

O gerenciamento de executores auto-hospedados no nível da empresa não requer mais o uso de tokens de acesso pessoal com o escopo admin:enterprise. Em vez disso, é possível usar o escopo new manage_runners:enterprise para restringir as permissões nos tokens. Os tokens com esse escopo podem ser autenticados em muitos pontos de extremidade da API REST para gerenciar os executores auto-hospedados da sua empresa.

Agora você pode usar a API REST para interagir programaticamente com o log de auditoria. Embora o encaminhamento de log de auditoria forneça o recurso de retenção e análise de dados com seu próprio kit de ferramentas e determine padrões ao longo do tempo, a nova API REST ajudará você a realizar análises limitadas de eventos importantes que ocorreram no histórico recente. Para obter mais informações, confira "Como revisar o log de auditoria para sua organização".

Agora você pode definir uma data de validade para tokens de acesso pessoal novos e existentes. O GitHub AE enviará um email para você quando for a hora de renovar um token que está prestes a expirar. Tokens expirados podem ser regenerados com um token duplicado que tenha as mesmas propriedades do original. Ao usar um token com a API do GitHub AE, você verá um novo cabeçalho, GitHub-Authentication-Token-Expiration, que indica a data de validade do token. Você pode usar isso em scripts, por exemplo, para registrar uma mensagem de aviso à medida que a data de validade se aproxima. Para saber mais, confira "Criar um token de acesso pessoal" e "Introdução à API REST".

Os proprietários da organização agora podem exportar uma lista das pessoas com acesso a um repositório no formato CSV. Para saber mais, confira "Exibir as pessoas que têm acesso ao repositório".

As novas configurações de gerenciamento de atribuição de revisão de código ajudam a distribuir a revisão de solicitação de pull de uma equipe entre seus membros para que o trabalho de análise não seja relegado a apenas um ou dois membros da equipe.

• Membros filho da equipe: limitar a atribuição apenas a membros diretos da equipe. Anteriormente, as solicitações de revisão de equipe podiam ser atribuídas a membros diretos ou a membros de equipes filhas.
• Contar solicitações existentes: continuar com a atribuição automática mesmo quando um ou mais membros da equipe já foram solicitados. Anteriormente, um membro da equipe já solicitado seria contado como uma das revisões automáticas de solicitação da equipe.
• Solicitação de revisão da equipe: manter uma equipe designada para revisão mesmo quando um ou mais membros foram designados recentemente.

Para obter mais informações, confira "Como gerenciar as configurações de revisão de código para sua equipe".

Dois novos temas estão disponíveis para a interface do usuário da Web do GitHub AE.

• Um tema escuro de alto contraste, com maior contraste entre os elementos de primeiro plano e de fundo
• Temas claros e escuros para daltônicos, que trocam cores como vermelho e verde por laranja e azul

Para obter mais informações, confira "Como gerenciar suas configurações de tema".

Agora você pode usar a sintaxe de nota de rodapé em qualquer campo Markdown para fazer referência a informações relevantes sem interromper o fluxo de sua narrativa. As notas de rodapé são exibidas como links sobrescritos. Clique em uma nota de rodapé para acessar a referência, exibida em uma nova seção na parte inferior do documento. Para obter mais informações, confira "Sintaxe básica de escrita e formatação".

Agora você pode alternar entre a visualização de origem e de Markdown renderizada por meio da interface do usuário da Web clicando no botão para "Exibir a diferença de origem" na parte superior de qualquer arquivo Markdown. Anteriormente, você precisava usar a exibição blame para vincular números de linha específicos em uma fonte de um arquivo markdown.

O GitHub AE agora gera automaticamente um sumário para Wikis com base nos cabeçalhos.

GitHub Actions é uma solução poderosa e flexível para CI/CD e automação de fluxo de trabalho. Para obter mais informações, confira "Entendendo o GitHub Actions".

Observe que quando GitHub Actions estiver habilitado durante esta atualização, duas organizações denominadas "GitHub Actions" (@actions e @github) aparecerão em sua empresa. Essas organizações são exigidas por GitHub Actions. Usuários nomeados @ghost e @actions aparecem como atores para a criação destas organizações no log de auditoria.

GitHub Packages é um serviço de hospedagem de pacotes, nativamente integrado a GitHub Actions, APIs e Webhooks. Crie um fluxo de trabalho de DevOps de ponta a ponta que inclui seu código, integração contínua e soluções de implantação. Durante este beta, GitHub Packages é oferecido gratuitamente para clientes de GitHub AE.

GitHub Advanced Security está disponível em beta e inclui tanto a verificação de código como a verificação de segredo. Durante este beta, as funcionalidades de GitHub Advanced Security são oferecidas gratuitamente para clientes de GitHub AE. Os administradores do repositório e da organização podem optar usar GitHub Advanced Security na guia de Security e Analysis em configurações.

Saiba mais sobre a verificação de código do GitHub Advanced Security e a verificação de segredo em GitHub AE.

Os clientes que usam o SCIM (System para Gerenciamento de Identidade entre Domínios) agora podem sincronizar grupos de segurança no Azure Active Directory com equipes de GitHub. Após uma equipe ser vinculada a um grupo de segurança a associação será atualizada automaticamente em GitHub AE quando um usuário for adicionado ou removido do seu grupo de segurança atribuído.

As listas de permissões de IP do GitHub fornecem a capacidade de filtrar o tráfego de intervalos de IP especificados pelo administrador, definidos pela notação CIDR. A lista de permitidos é definida no nível da conta da empresa ou da organização em Segurança > Configurações. Todo tráfego que tentar alcançar recursos dentro da conta da empresa e organizações serão filtrados pelo IP que permite listas. Essa funcionalidade é fornecida, além da capacidade de solicitar alterações no grupo de segurança de rede que filtram o tráfego na totalidade do inquilino de GHAE.

Os proprietários da organização agora podem desabilitar a publicação de sites do GitHub Pages em repositórios na organização. Esta ação não cancelará a publicação de sites existentes.

Os repositórios que usam GitHub Pages agora podem compilar e implantar de qualquer branch.

Ao escrever um problema ou solicitação de pull, a sintaxe da lista para itens, números e tarefas agora será concluída automaticamente depois que você pressionar return ou enter.

Agora, você pode excluir um diretório em um repositório da página do repositório. Ao acessar diretório, um novo botão kebab ao lado do botão "Adicionar arquivo" dá a opção de excluir o diretório.

Agora é mais fácil e rápido referenciar problemas ou solicitações de pull, com a pesquisa em várias palavras após "#".

Os proprietários de empresa agora podem publicar uma mensagem obrigatória. A mensagem é exibida para todos os usuários e eles devem reconhecê-la. Isto pode ser utilizado para exibir informações importantes, termos de serviço ou políticas.

A permissão de caminho de arquivo único GitHub App agora pode dar suporte a até dez arquivos.

Ao configurar um GitHub App, a URL de retorno de chamada de autorização é um campo obrigatório. Agora vamos permitir que o integrador especifique várias URLs de chamada de retorno. GitHub AE nega autorização se a URL de retorno da solicitação não estiver listada.

Um novo ponto de extremidade da API permite a troca de um token de usuário para servidor para um token de usuário para servidor com escopo para repositórios específicos.

Agora, os eventos são registrados no log de auditoria em promovendo um integrante da equipe para ser um mantenedor de equipe e ao rebaixar um mantenedor da equipe para ser um integrante da equipe.

Agora há suporte para o fluxo de autorização do dispositivo OAuth. Isso permite que qualquer cliente de CLI ou ferramenta de desenvolvedor efetue a autenticação usando um sistema secundário.

Um usuário não pode mais excluir sua conta se o provisionamento de SCIM estiver habilitado.

Os proprietários de empresas e organizações agora podem definir o nome do branch padrão para novos repositórios. Os proprietários de empresas também podem aplicar a sua escolha do nome padrão do branch em todas as organizações ou permitir que as organizações individuais escolham suas próprias.

Os repositórios existentes não são afetados por essas configurações, e seu nome de branch padrão não será alterado.

Esta alteração é uma das muitas alterações que GitHub está fazendo para apoiar projetos e mantenedores que desejam renomear o seu branch padrão. Para saber mais, confira github/renaming.

Os usuários não podem mais definir um endereço de email backup nos seus perfis. O endereço de email deles é definido apenas pelo IdP.

Você não pode mais habilitar a autenticação de dois fatores após a configuração de autenticação através do seu IdP.

GitHub AE agora pode conectar-se ao Azure Boards.

Os cabeçalhos de versão estavam ausentes nas APIs e agora foram definidos como "GitHub AE".

Foram corrigidos links na documentação.

Ocorreu uma falha na configuração de encaminhamento de log de auditoria nas configurações da empresa.

Acesar os gists pode gerar um "500 error".

O email de suporte ou URL não foi salvo. Agora, ele é salvo após o período de alguns minutos.

Os modelos de solicitação de pull no nível de organização não estavam sendo aplicados em todas as solicitações de pull na organização.