GitHub AE release notes
GitHub AE 3.6
O GitHub começou a implantar essas alterações para empresas Invalid Date.
3.6.0: Features
Experiência do administrador
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".
Gerenciamento de identidade e de acesso
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.
Políticas
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".
Segurança Avançada do GitHub
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.
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.
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
edirection
na API REST ao recuperar alertas de verificação de segredos e classificá-los com base nos camposcreated
ouupdated
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.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óriogithub/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.Dependabot
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.
Segurança do código
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
eCargo.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
GitHub Actions
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 noactions/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.
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
eworkflow_call
e usar o contextoinputs
para acessar os valores de entrada. Anteriormente, as entradasworkflow_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 porworkflow_dispatch
, as entradas ainda estão disponíveis no contextogithub.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".
Experiência da comunidade
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".
Organizações
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.
Repositórios
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".
Confirmações
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".
Solicitações de pull
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".
Versões
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".
Gist
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".
Markdown
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.
Acessibilidade
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".
3.6.0: Changes
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".
3.6.0: Deprecations
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".
GitHub AE 3.4
O GitHub começou a implantar essas alterações para empresas Invalid Date.
3.4.0: Features
Gerenciamento de segurança e acesso
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".
Administração
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".
GitHub Actions
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
eenvironment
. 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
comonode16
. 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órioactions/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.
Segurança Avançada do GitHub
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
edirection
emcreated
,updated
ounumber
. 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, confiraLast-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
etags
. Para obter mais informações, confira "Eventos e cargas do webhook".
- Os alertas incluem o carimbo de data/hora
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.
Dependabot
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.
Segurança do código
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
epoetry.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 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
Notificações
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.
Organizações
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 extremidadeenterpriseOwners
. Para obter mais informações, confira "Como ver as funções das pessoas em uma organização".Repositórios
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".Solicitações de pull
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".
Versões
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".
Gists
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".Markdown
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.
Experiência do desenvolvedor
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".
Acessibilidade
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".
Aplicativos GitHub
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".
Webhooks
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".
3.4.0: Changes
Quando usuários são convidados para um repositório privado, ao acessar a URL do repositório, um prompt para ingressar nele será exibido, em vez de um erro
404
.Os convites para repositórios privados aparecem nas notificações.
Quando um usuário digita
@
na IU da Web a fim de mencionar outro usuário, a lista classifica os participantes em problemas, solicitações de pull e discussões primeiro para que seja mais fácil ao usuário encontrar a pessoa desejada.Para evitar que códigos potencialmente maliciosos sejam executados em um fluxo de trabalho com privilégios, as alterações a seguir se aplicam aos fluxos de trabalho do GitHub Actions disparados pelo Dependabot.
- As execuções de fluxo de trabalho disparadas para os eventos
create
,deployment
edeployment_status
sempre receberão um token somente leitura e nenhum segredo. – As execuções de fluxo de trabalho disparadas para o eventopull_request_target
em solicitações de pull em que a referência base foi criada pelo Dependabot sempre receberão um token somente leitura e nenhum segredo. – As execuções de fluxo de trabalho em eventospush
epull_request
disparadas pelo Dependabot que respeitam opermissions
especificado nos fluxos de trabalho. As permissões do token padrão permanecerão como somente leitura.
- As execuções de fluxo de trabalho disparadas para os eventos
A configuração para ocultar alterações de espaço em branco na guia Arquivos alterados de uma solicitação de pull é preservada para ela.
A API "Atualizar um branch de solicitação de pull" para Aplicativos do GitHub agora exige que o usuário ou aplicativo que realiza a chamada tenha acesso de gravação ao repositório principal. Se ele não tiver acesso de gravação, a API retornará uma resposta
403 Forbidden
. Para saber mais, confira "Pulls" na documentação da API REST.
GitHub AE 3.3
O GitHub começou a implantar essas alterações para empresas Invalid Date.
3.3.0: Features
Os recursos de segurança avançada do GitHub estão disponíveis para o público geral
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".
Visualize todos os alertas de verificação de código de uma solicitação de pull
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".
Visão geral de segurança para organizações
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".
Gráfico de dependências
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".
Alertas do Dependabot
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 %}".
Função de gerente de segurança em organizações
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".
Executores efêmeros e webhooks de dimensionamento automático para GitHub Actions
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".
Ações de composição do GitHub Actions
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".
Novo escopo de token para gerenciamento de executores auto-hospedados
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 escoponew 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.Log de auditoria acessível via API REST
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".
Datas de validade para tokens de acesso pessoal
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".Exportar uma lista de pessoas com acesso a um repositório
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".
Gerenciamento aprimorado de atribuições de revisão de código
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".
Novos temas
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".
Aprimoramentos de markdown
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.
3.3.0: Changes
Desempenho
As cargas e tarefas de página agora são significativamente mais rápidas para repositórios com muitas refs do Git.
Administração
O processo de representação do usuário foi aprimorado. Uma sessão de representação agora exige uma justificativa para a representação, as ações são registradas no log de auditoria como sendo executadas como um usuário representado, e o usuário que for representado receberá uma notificação por email de que foi personalizado por um proprietário da empresa. Para saber mais, confira "Representar um usuário".
GitHub Actions
Para mitigar ataques man-in-the-middle ao usar ações resolvidas por meio do GitHub Connect do GitHub AE para o GitHub.com, o GitHub AE desativa o uso do namespace de ações (
OWNER/NAME
). A desativação do namespace impede que ele seja criado em sua empresa e garante que todos os fluxos de trabalho que fazem referência à ação façam o download do GitHub.com. Para obter mais informações, confira "Como habilitar o acesso automático às ações do GitHub.com usando o GitHub Connect".O log de auditoria agora inclui eventos adicionais do GitHub Actions. O GitHub AE agora registra entradas de log de auditoria para os eventos a seguir.
- Um executor auto-hospedado foi registrado ou removido.
- Um executor auto-hospedado foi adicionado ou removido de um grupo de executores.
- Um grupo de executores foi criado ou removido.
- Uma execução de fluxo de trabalho foi criada ou concluída.
- Um trabalho de fluxo de trabalho foi preparado. Mais importante, esse log inclui a lista de segredos que foram fornecidos ao executor.
Para obter mais informações, confira "Proteção de segurança do GitHub Actions".
Segurança Avançada do GitHub
A verificação de código agora mapeará alertas identificados em fluxos de trabalho
on:push
para que sejam exibidos em solicitações de pull, quando possível. Os alertas mostrados na solicitação de pull são aqueles identificados pela comparação da análise existente do início do branch com a análise do branch de destino com o qual você está mesclando. Observe que, se o commit de mesclagem da solicitação de pull não for usado, os alertas poderão ser menos precisos quando comparados à abordagem que usa gatilhoson:pull_request
. Para obter mais informações, confira "Sobre a verificação de código com o CodeQL".Alguns outros sistemas de CI/CD podem ser configurados exclusivamente para acionar uma pipeline quando é feito o push do código para um branch ou até exclusivamente para cada commit. Sempre que um pipeline de análise for acionado e os resultados forem carregados na API do SARIF, a verificação do código também tentará combinar os resultados da análise para uma solicitação de pull aberta. Se for encontrada uma solicitação de pull aberta, os resultados serão publicados conforme descrito acima. Para obter mais informações, confira "Como carregar um arquivo SARIF no GitHub".
O GitHub AE agora detecta segredos de provedores adicionais. Para saber mais, confira "Padrões de verificação de segredos".
Solicitações de pull
A linha do tempo e a barra lateral de Revisores na página de solicitação de pull agora indicam se uma solicitação de revisão foi atribuída automaticamente a um ou mais membros da equipe devido à equipe usar a atribuição de revisão de código.
Agora é possível selecionar Esperando sua revisãopara filtrar as pesquisas de solicitação de pull a fim de incluir somente aquelas que tiveram sua revisão solicitada diretamente. Para obter mais informações, confira "Pesquisar problemas e solicitações de pull".
Se você especificar o nome exato de um branch ao usar o menu seletor do branch, o resultado agora será exibido na parte superior da lista de branches correspondentes. Anteriormente, as correspondências exatas de nomes de branch poderiam aparecer na parte inferior da lista.
Ao visualizar um branch que tem uma solicitação de pull aberta correspondente, o GitHub AE agora vincula diretamente para as solicitações de pull. Anteriormente, havia um prompt de contribuição usando a comparação de branch ou de abertura de uma nova solicitação de pull.
Agora você pode clicar em um botão para copiar os conteúdos brutos completos de um arquivo para a área de transferência. Anteriormente, era necessário abrir um novo arquivo bruto, selecionar tudo e depois copiar. Para copiar os conteúdos de um arquivo, navegue para o arquivo e clique em na barra de ferramentas. Observe que atualmente esse recurso só está disponível em alguns navegadores.
Agora é exibido um aviso ao visualizar um arquivo que contém texto unicode bidirecional. O texto unicode bidirecional pode ser interpretado ou compilado diferentemente de como ele aparece em uma interface de usuário. Por exemplo, caracteres unicode bidirecionais ocultos podem ser usados para trocar segmentos de texto em um arquivo. Para saber como substituir esses caracteres, confira o Log de alterações do GitHub.
Repositórios
O GitHub AE agora inclui suporte aprimorado para arquivos CITATION.cff. Os arquivos CITATION.cff são arquivos de texto simples com informações de citação legíveis por humanos e computadores. O GitHub AE analisa essas informações em formatos convenientes, como APA e BibTeX, que podem ser copiados por outras pessoas. Para saber mais, confira "Sobre os arquivos CITATION".
Agora você pode adicionar, excluir ou visualizar links automáticos por meio do ponto de extremidade Autolinks da API de repositórios. Para saber mais, confira "Referências e URLs com link automático" e "Repositórios" na documentação da API REST.
Versões
O componente de seleção de marcações para versões do GitHub agora é um menu suspenso em vez de um campo de texto. Para obter mais informações, confira "Como gerenciar as versões do repositório".
Markdown
Ao arrastar e soltar arquivos, como imagens e vídeos em um editor Markdown, o GitHub AE agora usa o ponteiro do mouse em vez do local do cursor ao colocar o arquivo.
API REST
As visualizações da API REST foram graduadas e são uma parte oficial da API. Os cabeçalhos de exibição não são mais necessários para pontos de extremidade da API REST, mas ainda funcionarão conforme o esperado ao especificar uma versão prévia graduada no cabeçalho
Accept
de uma solicitação.
GitHub AE 3.2
O GitHub começou a implantar essas alterações para empresas December 06, 2021.
3.2.0: Features
Administração
Os clientes com assinaturas ativas ou de avaliação do GitHub AE agora podem provisionar os recursos do GitHub AE no portal do Azure. A sua assinatura do Azure deve ser sinalizada como recurso para acessar os recursos GitHub AE no portal. Contate o gerente da sua conta ou Equipe de vendas do GitHub para validar a elegibilidade da sua assinatura do Azure. Para obter mais informações, confira "Implantação do GitHub AE".
GitHub Actions
O GitHub Actions agora está disponível para o GitHub AE. 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".
Executores auto-hospedados são o tipo padrão sistema executor em GitHub AE e agora estão em disponibilidade geral para o GitHub Actions. Com executores auto-hospedados, você pode gerenciar os seus próprios computadores ou contêineres para a execução de trabalhos do GitHub Actions. Para saber mais, confira "Sobre os executores auto-hospedados" e "Adicionar executores auto-hospedados."
Ambientes, regras de proteção de ambiente e segredos de ambiente agora estão em disponibilidade geral para o GitHub Actions em GitHub AE. Para obter mais informações, confira "Usando ambientes para implantação".
GitHub Actions pode agora gerar um grafo visual do seu fluxo de trabalho em casa execução. Com a visualização do fluxo de trabalho, você pode realizar o seguinte.
- Exibir e entender fluxos de trabalho complexos.
- Acompanhar o progresso dos fluxos de trabalho em tempo real.
- Solucionar rapidamente problemas em execuções por meio do acesso fácil a metadados de trabalhos e logs.
- Monitorar o progresso dos trabalhos de implantação e acessar com facilidade os destinos de implantação.
Para obter mais informações, confira "Como usar o grafo de visualização".
O GitHub Actions agora permite controlar as permissões concedidas ao segredo
GITHUB_TOKEN
. OGITHUB_TOKEN
é um segredo gerado automaticamente que permite fazer chamadas autenticadas para a API do GitHub AE em execuções de fluxo de trabalho. GitHub Actions gera um token novo para cada trabalho e cancela o token quando o trabalho é completado. O token tem permissõeswrite
para diversos pontos de extremidade de API, exceto no caso de solicitações de pull de forks, que são sempreread
. Essas novas configurações permitem que você siga o princípio de menor privilégio nos seus fluxos de trabalho. Para obter mais informações, confira "Autenticação em um fluxo de trabalho".O GitHub Actions agora dá suporte para ignorar fluxos de trabalho
push
epull_request
por meio da procura de algumas palavras-chave comuns na mensagem de commit.GitHub CLI 1.9 e posterior permite que você trabalhe com GitHub Actions no seu terminal. Para obter mais informações, confira the GitHub Blog.
Varredura de código
A verificação de código agora está em beta para GitHub AE. Para obter mais informações, confira "Sobre a verificação de código".
Verificação de segredo
Agora você pode especificar os seus próprios padrões para verificação de segredo com a versão beta dos padrões personalizados em GitHub AE. Você pode especificar padrões para repositórios, organizações e sua empresa inteira. Quando você especifica um novo padrão, a verificação de segredo pesquisa pelo padrão em todo o histórico Git do repositório, assim como qualquer novo commit. Para obter mais informações, confira "Como definir padrões personalizados para a verificação de segredos".
GitHub Connect
GitHub Connect agora está disponível em beta para GitHub AE. Com o GitHub Connect, você tem todo o poder da maior comunidade de código aberto do mundo no sua empresa. Você pode permitir que usuários vejam resultados de pesquisa de GitHub.com em GitHub AE, mostrar as contagens de contribuição de GitHub AE em GitHub.com e usar os GitHub Actions de GitHub.com. Para saber mais, confira "Gerenciar conexões entre suas contas corporativas".
GitHub Packages
Agora você pode excluir qualquer pacote ou versão de pacote para GitHub Packages da interface do usuário da Web de GitHub AE. Você também pode desfazer a exclusão de qualquer pacote ou versão de pacote dentro de 30 dias. Para obter mais informações, confira "Como excluir e restaurar um pacote".
O registro npm para pacotes do GitHub e o GitHub.com não retorna mais um valor de tempo em respostas de metadados, a fim de fornecer melhorias substanciais de desempenho. O GitHub continuará retornando o valor de tempo no futuro.
Log de auditoria
Eventos para solicitações de pull e revisões de solicitações de pull agora estão incluídos no log de auditoria para empresas e organizações. Estes eventos ajudam os administradores a monitorar melhor a atividade de solicitação de pull e a garantir que os requisitos de segurança e de conformidade sejam atendidos. Os eventos podem ser exibidos pela interface de usuário da Web, exportados como CSV ou JSON ou acessados via API REST. Você também pode pesquisar eventos de solicitação de pull específicos no log de auditoria.
Eventos adicionais do GitHub Actions agora estão incluídos no log de auditoria para empresas e organizações.
- Um fluxo de trabalho foi excluído ou executado novamente.
- A versão de um executor auto-hospedado foi atualizada.
Autenticação
GitHub AE agora oficialmente oferece suporte de Okta para SSO de SAML (logon único) e provisionamento de usuário com SCIM. Você também pode mapear os grupos em Okta para equipes no GitHub AE. Para saber mais, confira "Configurar a autenticação e o provisionamento para sua empresa usando o Okta" e "Mapear grupos do Okta para equipes".
O formato dos tokens de autenticação para GitHub AE foi alterado. A alteração afeta o formato de tokens de acesso pessoal e tokens de acesso para aplicativos OAuth, bem como tokens de usuário para servidor, servidor para servidor e atualização no caso de Aplicativos do GitHub. O GitHub recomenda atualizar os tokens existentes o mais rápido possível para melhorar a segurança e permitir a verificação de segredo a fim de detectar os tokens. Para saber mais, confira "Sobre a autenticação no GitHub" e "Sobre a verificação de segredo".
Agora é possível autenticar conexões SSH no GitHub AE usando uma chave de segurança FIDO2 por meio da adição de uma chave SSH
sk-ecdsa-sha2-nistp256@openssh.com
à conta. As chaves de segurança SSH armazenam material de chave secreta em um dispositivo de hardware separado que exige verificação, como um toque, para operar. Armazenar a chave em um hardware separado e exigir a interação física da sua chave SSH oferece uma segurança adicional. Como a chave está armazenada no hardware e não pode ser extraída, a chave não pode ser lida ou roubada pelo software em execução no computador. A interação física evita o uso não autorizado da chave, pois a chave de segurança não será operada até que você interaja fisicamente com ela. Para obter mais informações, confira "Como gerar uma nova chave SSH e adicioná-la ao ssh-agent".As versões GCM (Git Credential Manager) Core 2.0.452 e posteriores agora fornecem armazenamento de credencial seguro e suporte de autenticação multifator para GitHub AE. O GCM Core com suporte ao GitHub AE foi incluído com as versões 2.32 e posteriores do Git para Windows. GCM Core não está incluído com Git para macOS ou Linux, mas pode ser instalado separadamente. Para saber mais, confira a última versão e as instruções de instalação no repositório
microsoft/Git-Credential-Manager-Core
.Notificações
Agora você pode configurar para quais eventos você gostaria de ser notificado em GitHub AE. Em qualquer repositório, selecione o menu suspenso Inspeção e clique em Personalizar. Para obter mais informações, confira "Como configurar notificações".
Problemas e pull requests
Com a versão mais recente do Octicons, os estados de problemas e solicitações de pull agora são mais visualmente distintos para facilitar a verificação do status. Para obter mais informações, confira the GitHub Blog.
Agora é possível ver todos os comentários de revisão de solicitações de pull na guia Arquivos delas selecionando o menu suspenso Conversas. Você também pode exigir que todos os comentários de revisão de solicitação de pull sejam resolvidos antes que qualquer pessoa migre a solicitação de pull. Para saber mais, confira "Sobre revisões de solicitações de pull" e "Sobre branches protegidos". Para saber mais sobre o gerenciamento das configurações de proteção de branch com a API, confira “Branches” na documentação da API REST e "Mutações" na documentação da API do GraphQL.
Agora você pode fazer o upload de arquivos de vídeo em qualquer lugar em que você faz gravação Markdown em GitHub AE. Compartilhe demonstrações, mostre etapas de reprodução e mais no problema e comentários de solicitação de pull, assim como em arquivos markdown dentro de repositórios, como READMEs. Para saber mais, confira "Anexar arquivos".
GitHub AE agora mostra uma caixa de diálogo de confirmação quando você solicita uma revisão de uma equipe com mais de 100 integrantes, o que permite que você evite notificações desnecessárias para grandes equipes.
Se um problema ou solicitação de pull tiver menos do que 30 destinatários possíveis, o controle de destinatários listará todos os usuários possíveis ao invés de um conjunto limitado de sugestões. Este comportamento ajuda as pessoas em organizações pequenas a encontrar o usuário correto rapidamente. Para saber como atribuir usuários a problemas e solicitações de pull, confira "Atribuir problemas e solicitações de pull a outros usuários do GitHub".
Agora é possível incluir diversas palavras após o
#
em um comentário de um problema ou solicitação de pull a fim de restringir ainda mais a pesquisa. Para ignorar as sugestões, pressione Esc.Para evitar a mesclagem de alterações inesperadas após você habilitar a mesclagem automática para uma solicitação de pull, a mesclagem automática é agora desabilitada automaticamente quando for efetuado o push de novas alterações por um usuário sem acesso de gravação no repositório. O usuários sem acesso de gravação ainda podem atualizar a solicitação de pull com alterações do branch de base quando a mesclagem automática estiver habilitada. Para evitar que um usuário malicioso use o conflito de mesclagem para introduzir alterações inesperadas à solicitação de pull, GitHub AE desabilitará a mesclagem automática para a solicitação de pull se a atualização causar um conflito de mesclagem. Para saber mais sobre a mesclagem automática, confira "Mesclar automaticamente uma solicitação de pull".
Pessoas com acesso de manutenção agora podem gerenciar a configuração "Permitir mesclagem automática" no nível do repositório. Esta configuração, que está desativada por padrão, controla se a mesclagem automática está disponível para as solicitações de pull no repositório. Anteriormente, somente pessoas com acesso de administração podiam gerenciar esta configuração. Além disso, essa configuração agora pode ser controlada usando as APIs REST "Criar um repositório" e "Atualizar um repositório". Para obter mais informações, confira "Como gerenciar a mesclagem automática para solicitações de pull no seu repositório".
A seleção de destinatários para problemas e solicitações de pull agora dão suporte à pesquisa de digitação antecipada, para que você possa encontrar usuários na sua organização mais rapidamente. Adicionalmente, as classificações de resultado de pesquisa foram atualizadas para dar preferência à combinação ao início do nome do usuário ou nome do perfil da pessoa.
Repositórios
Ao visualizar o histórico de commit de um arquivo, agora você pode clicar em para ver o arquivo no momento especificado no histórico do repositório.
Agora você pode usar a interface do usuário da Web para sincronizar um branch desatualizado de uma bifurcação com o branch upstream da bifurcação. Se não houver nenhum conflito de mesclagem entre os branches, GitHub AE atualiza o seu branch com avanço rápido ou mesclando pelo upstream. Se houver algum conflito, GitHub AE solicitará que você abra solicitações de pull para resolver os conflitos. Para obter mais informações, confira "Como sincronizar um fork".
Agora você pode classificar os repositórios no perfil de um usuário ou organização por contagem de estrelas.
Os pontos de extremidade das APIs REST dos repositórios “comparar dois commits”, o que retorna uma lista de commits alcançáveis de um commit ou branch, mas não alcançável de outro, agora dão suporte à paginação. Agora a API também pode retornar os resultados para comparações de mais de 250 confirmações. Para saber mais, confira a documentação da API REST "Commits" e "Partilhamento com paginação".
Ao definir um submódulo no sua empresa com um caminho relativo, agora é possível clicar no submódulo na IU da Web. Clicar no submódulo na interface do usuário da web levará você para o repositório vinculado. Anteriormente, somente era possível clicar em submódulos com URLs absolutas. Caminhos relativos para repositórios com o mesmo proprietário que seguem o padrão
../REPOSITORY
ou caminhos relativos para repositórios com um proprietário diferente que seguem o padrão../OWNER/REPOSITORY
são compatíveis. Para saber como trabalhar com submódulos, confira Trabalhar com submódulos no the GitHub Blog.Ao pré-calcular as comprovações, a quantidade de tempo que um repositório está sob o bloqueio foi reduzida drasticamente, o que permitiu mais operações de escrita com sucesso e melhorando o desempenho do monorrepositório.
Versões
Agora você pode reagir com emoji em todas as versões em GitHub AE. Para saber mais, confira "Sobre versões".
Temas
Temas escuros e escurecidos agora estão disponíveis para a IU da Web. Se você não tiver definido suas preferências de tema no GitHub AE, o GitHub AE fará a correspondência com as preferências do sistema. Você também pode personalizar os temas que estão ativos durante o dia e a noite. Para obter mais informações, confira "Como gerenciar suas configurações de tema".
Markdown
Agora os arquivos markdown nos seus repositórios geram automaticamente um sumário no cabeçalho quando o arquivo tiver dois ou mais títulos. Um sumário é interativo e faz o link para a seção correspondente. Todos os seis níveis de título do Markdown são compatíveis. Para obter mais informações, confira "Sobre os arquivos README".
O markup
code
agora é compatível com títulos para problemas e solicitações de pull. Os textos entre acentos graves (`
) aparecerão renderizados em uma fonte de largura fixa em qualquer lugar em que o título do problema ou da solicitação de pull aparecer na IU da Web do GitHub AE.Ao editar markdown em arquivos, problemas, solicitações de pull ou comentários, agora você pode usar um atalho de teclado para inserir um bloco de código. O atalho de teclado é command + E no Mac ou Ctrl + E em outros dispositivos. Para obter mais informações, confira "Sintaxe básica de escrita e formatação".
É possível acrescentar
?plain=1
à URL de qualquer arquivo Markdown para exibi-lo sem renderização e com números de linha. Você pode usar a exibição simples para fazer o link para outros usuários e linhas específicos. Por exemplo, acrescentar?plain=1#L52
realçará a linha 52 de um arquivo Markdown de texto sem formatação. Para saber mais, confira "Criar um link permanente para um snippet de código".Aplicativos GitHub
Solicitações de API para criar um token de acesso de instalação agora respeitam a lista de IP permitidos para uma empresa e organização. Qualquer solicitação de API feita com um token de acesso de instalação de um aplicativo GitHub instalado na sua organização já respeita a lista de IP permitidos. Atualmente, esse recurso não considera nenhuma regra de NSG (grupo de segurança de rede) do Azure configurada pelo Suporte do GitHub para o sua empresa. Para saber mais, confira "Restringir o tráfego de rede para sua empresa", "Gerenciar os endereços IP permitidos para sua organização" e "Aplicativos" na documentação da API REST.
Webhooks
Você pode reenviar programaticamente ou verificar o estado de Webhooks através de API REST. Para saber mais, confira "Repositórios," "Organizações" e "Aplicativos" na documentação da API REST.
GitHub AE 3.1
O GitHub começou a implantar essas alterações para empresas March 03, 2021.
3.1.0: Features
GitHub Actions beta
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 beta
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 beta
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.
Gerenciar equipes do seu provedor de identidade (IdP)
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.
Beta de listas de permissões de IP
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.
3.1.0: Changes
Alterações de desenvolvedor
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
ouenter
.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 "#".
Mudanças na administração
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.
Renomeação do branch padrão
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.
3.1.0: Bug fixes
Correções de bug
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.
3.1.0: Known issues
Problemas conhecidos
Os dados da localização geográfica não são mostrados no log de auditoria. As informações de localização podem ser detectadas no endereço IP associado a cada evento.
O link para GitHub Packages de uma página do repositório mostra uma página de pesquisa incorreta quando esse repositório não tem pacotes.