Enterprise Server 3.4 release notes

Os clientes de Segurança Avançada GitHub agora podem usar a API REST para recuperar detalhes de commit de segredos detectados em verificações de repositório privado. O novo ponto de extremidade retorna detalhes da primeira detecção de um segredo em um arquivo, incluindo a localização do segredo e o commit SHA. Para obter mais informações, consulte "Digitalização de segredo" na documentação da API REST.

Os proprietários da empresa e da organização agora podem exportar os dados do us oda sua licença de Segurança Avançada GitHub para um arquivo CSV. Os dados de cobrança de Segurança Avançada também podem ser recuperados por meio de pontos de extremidade de cobrança na API REST. Para obter mais informações, consulte "Registro de alterações GitHub."

Agora você pode reutilizar todos os fluxos de trabalho como se eles fossem uma ação. Esse recurso está disponível na versão beta pública. Em vez de copiar e colar as definições de fluxo de trabalho entre repositórios, agora você pode fazer referência a um fluxo de trabalho existente com uma única linha de configuração. Para obter mais informações, consulte "Registro de alterações de GitHub."

Dependabot is now available in GitHub Enterprise Server 3.4 as a public beta, offering both version updates and security updates for several popular ecosystems. Dependabot on GitHub Enterprise Server requires GitHub Actions and a pool of self-hosted runners configured for Dependabot use. Dependabot on GitHub Enterprise Server also requires GitHub Connect and Dependabot to be enabled by an administrator. Beta feedback and suggestions can be shared in the Dependabot Feedback GitHub discussion. For more information and to try the beta, see "Setting up Dependabot security and version updates on your enterprise."

Os usuários agora podem escolher o número de espaços ao qual uma aba equivale, definindo o seu tamanho da aba preferido nas configurações de "Aparência" da sua conta de usuário. Todos os códigos com um recuo de aba serão interpretados utilizando o tamanho preferido da aba.

O registro de conexão de dados de GitHub Connect agora inclui uma contagem do número de usuários ativos e inativos e o período de inavitidade configurado.

Agora você pode dar aos usuários acesso a links específicos para empresas adicionando rodapés personalizados a GitHub Enterprise Server. Para obter mais informações, consulte "Configurar rodapés personalizados."

WireGuard, usado para garantir a comunicação entre as instâncias de GitHub Enterprise Server em uma configuração de alta disponibilidade, foi transferido para a implementação do Kernel.

Os proprietários da organização podem agora cancelar a inscrição das notificações de e-mail quando novas chaves de implantação forem adicionadas aos repositórios pertencentes às suas organizações. Para obter mais informações, consulte "Configurar notificações".

Os e-mails de notificação de problemas e pull requests recém-criados agora incluem (Issue #xx) ou (PR #xx) no assunto do e-mail para que você possa reconhecer e filtrar e-mails que faxem referência a esse tipo de problema.

As organizações agora podem exibir um arquivo README.md na sua visão geral do perfil. Para obter mais informações, consulte "Registro de alterações de GitHub."

Os integrantes das organizações agora podem ver uma lista de proprietários da empresa na guia "Pessoas" da organização. A lista de proprietários corporativos agora pode ser acessadal usando a API do GraphQL. Para obter mais informações, consulte o campo "enterpriseOwners" no objeto Organização na documentação da API do GraphQL.

Agora, uma seção "Gerenciar acesso" é exibida nas configurações do repositório na página "Colaboradores e equipes". A nova seção torna mais fácil para os administradores do repositório verem e gerenciarem quem tem acesso ao repositório e o nível de acesso concedido a cada usuário. Os administradores podem agora:

• Pesquisar todos os integrantes, equipes e colaboradores com acesso ao repositório.
• Visualizar quando os integrantes têm atribuições mistas de funções, concedidas a eles diretamente como indivíduos ou indiretamente por meio de uma equipe. Isto pode ser visualizado por meio de um novo aviso de "funções mistas", que exibe o cargo de nível mais alto que o usuário é concedido se o seu nível de permissão for maior do que a sua função atribuída.
• Gerenviar o acesso a repositórios populares de forma confiável, com a paginação e menos tempos de inatividade quando grandes grupos de usuários tiverem acesso.

GitHub Enterprise Server 3.4 inclui melhorias na experiência de convite de repositório, como notificações de convites de repositórios privados, uma instrução de interface de usuário ao visitar um repositório privado, para o qual você tem um convite pendente, e um banner na página de visão geral do repositório público quando há um convite pendente.

Agora você pode usar prefixos de um caractere único para autolinks personalizados. Os prefixos de autolinks agora permitem os caracteres . , -, _, +, =, :, /, e #`, bem como caracteres alfanuméricos. Para obter mais informações sobre autolinks personalizados, consulte "Configurar autolinks para fazer referência a recursos externos."

Um arquivo CODE_OF_CONDUCT.md na raiz de um repositório agora está destacado na barra lateral "Sobre" na página de visão geral do repositório.

GitHub Enterprise Server 3.4 inclui melhorias na interface de usuário da bersão como, por exemplo, as notas de versão geradas automaticamente que exibem um resumo de todos os pull requests para uma determinada versão. Para obter mais informações, consulte "Registro de alterações de GitHub".

Quando uma versão é publicada, uma lista de avatares agora é exibida na parte inferior da versão. São exibidos avatares para todas as contas de usuário mencionadas nas observa~] pes da versão. Para obter mais informações, consulte "Gerenciar versões em um repositório".

Agora você pode usar a nova página de configurações de "Acessibilidade" para gerenciar seus atalhos de teclado. Você pode optar por desabilitar atalhos de teclado que usam apenas caracteres únicos como S, G C e . (a chave do ponto). Para mais informações, consulte "Registro de alterações de GitHub."

Agora você pode optar por usar uma fonte de largura fixa em campos habilitados por markdown, como comentários de problemas e descrições de pull request. Para obter mais informações, consulte "Registro de alterações de GitHub."

Agora você pode colar umURL no texto selecionado para criar rapidamente um link de Markdown. Isto funciona em todos os campos habilitados por Markdown, como comentários de problemas e descrições de pull request. Para obter mais informações, consulte "Registro de alterações de GitHub."

Agora a URL de uma imagem pode ser anexada com um contexto de tema, como #gh-dark-mode-only, para definir como a imagem do Markdown é exibida no visualizador. Para obter mais informações, consulte "Registro de alterações de GitHub."

Ao criar ou editar um arquivo gist com a extensão do arquivo do Markdown (.md), agora você pode usar a guia "Pré-visualizar" ou "Pré-visualizar alterações" para exibir uma interpretação do Markdown do conteúdo do arquivo. Para obter mais informações, consulte "Registro de alterações de GitHub."

Ao digitar o nome de um usuário do GitHub em problemas, pull requests e discussões, a sugestão de @mention agora classifica os participantes existentes mais altos que os outros usuários de GitHub, para que seja mais provável que o usuário que você está procurando esteja listado.

Idiomas da direita para a esquerda agora são compatíveis nativamente em arquivos Markdown, problemas, pull requests, discussões e comentários.

A configuração de diff para ocultar alterações de espaço em branco na guia "Arquivos alterados" de pull request agora é mantida para sua conta de usuário para esse pull request. A configuração escolhida é reaplicada automaticamente se você sair da página e voltar a usar a guia "Arquivos alterados" do mesmo pull request.

Ao usar a atribuição automática para análises de código de pull request, agora você pode optar por notificar apenas os integrantes da equipe solicitados, independentemente das suas configurações de atribuição automática. Essa configuração é útil em cenários em que muitos usuários são atribuídos automaticamente, mas nem todos os usuários exigem notificação. Para obter mais informações, consulte "Registro de alterações de GitHub."

Os administradores da organização e do repositório agora podem acionar os webhooks para ouvir alterações nas regras de proteção de branch em seus repositórios. Para obter mais informações, consulte o evento "branch_protection_rule" nos eventos de webhook e na documentação da carga.

Ao configurar os branches protegidos, agora você pode impor que uma verificação de estado necessária é fornecida por um aplicativo GitHub específico. Se um status for fornecido por um aplicativo diferente ou por um usuário por meio de um status de commit, a fusão é impedida. Isso garante que todas as alterações sejam validadas pelo aplicativo pretendido. Para obter mais informações, consulte "Registro de alterações de GitHub."

Apenas usuários com permissões de administrador agora podem renomear branches protegidos e modificar as regras de proteção de branch. Anteriormente, com exceção do branch padrão, um colaborador podia renomear um branch e, consequentemente, todas as regras de proteção do branch não curinga que foram aplicadas a esse branch também foram renomeadas. Para obter mais informações, consulte "Renomear um branch" e "Gerenciar uma regra de proteção de branch."

Agora os administradores podem permitir que apenas usuários e equipes específicos ignorem requisitos de pull request. Para obter mais informações, consulte "Registro de altrações de GitHub."

Agora os administradores podem permitir que apenas usuários e equipes específicos façam push forçado para um repositório. Para obter mais informações, consulte "Registro de alterações de GitHub."

Ao exigir pull requests para todas as alterações de um branch protegido, os administradores agora podem escolher se revisões aprovadas também são obrigatórias. Para obter mais informações, consulte "Registro de alterações de GitHub".

GitHub Actions workflows triggered by Dependabot for the create, deployment, and deployment_status events now always receive a read-only token and no secrets. Similarly, workflows triggered by Dependabot for the pull_request_target event on pull requests where the base ref was created by Dependabot, now always receive a read-only token and no secrets. These changes are designed to prevent potentially malicious code from executing in a privileged workflow. For more information, see "Automating Dependabot with GitHub Actions."

Workflow runs on push and pull_request events triggered by Dependabot will now respect the permissions specified in your workflows, allowing you to control how you manage automatic dependency updates. The default token permissions will remain read-only. For more information, see the "GitHub changelog."

GitHub Actions workflows triggered by Dependabot will now be sent the Dependabot secrets. You can now pull from private package registries in your CI using the same secrets you have configured for Dependabot to use, improving how GitHub Actions and Dependabot work together. For more information, see "Automating Dependabot with GitHub Actions."

Agora você pode gerenciar os grupos de executores e ver o status dos seus executores auto-hospedados usando as novas páginas de executores e grupos de executores na interface do usuário. A página de configurações de ações do seu repositório ou organização agora mostra uma visualização resumo dos seus executores e permite que você se aprofunde em um executor específico para editá-lo ou ver qual trabalho ele pode estar executando atualmente. Para obter mais informações, consulte "Registro de alterações de GitHub."

Autores das ações agora podem ter sua ação executada no Node.js 16 especificando runs.using como node16 no action.yml. Além do suporte existente ao Node.js 12; as ações podem continuar a especificar runs.using: node12 para usar o tempo de execução do Node.js 12.

Para fluxos de trabalho acionados manualmente, GitHub Actions agora é compatível com os tipos de entrada choice, boolean e environment além do tipo string padrão. Para obter mais informações, consulte "on.workflow_dispatch.inputs."

Actions written in YAML, also known as composite actions, now support if conditionals. This lets you prevent specific steps from executing unless a condition has been met. Like steps defined in workflows, you can use any supported context and expression to create a conditional.

The search order behavior for self-hosted runners has now changed, so that the first available matching runner at any level will run the job in all cases. This allows jobs to be sent to self-hosted runners much faster, especially for organizations and enterprises with lots of self-hosted runners. Previously, when running a job that required a self-hosted runner, GitHub Actions would look for self-hosted runners in the repository, organization, and enterprise, in that order.

Runner labels for GitHub Actions self-hosted runners can now be listed, added and removed using the REST API. For more information about using the new APIs at a repository, organization, or enterprise level, see "Repositories", "Organizations", and "Enterprises" in the REST API documentation.

O gráfico de dependência agora é compatível com a detecção de dependências do Python em repositórios que usam o gerenciador de pacotes do Poetry. As dependências serão detectadas a partir de arquivos manifestos 'pyproject.toml' e 'poetry.lock'.

When configuring Dependabot security and version updates on GitHub Enterprise Server, we recommend you also enable Dependabot in GitHub Connect. This will allow Dependabot to retrieve an updated list of dependencies and vulnerabilities from GitHub.com, by querying for information such as the changelogs of the public releases of open source code that you depend upon. For more information, see "Enabling the dependency graph and Dependabot alerts for your enterprise."

Os alertas de Alertas do Dependabot agora podem ser ignorados usando a API do GraphQL. Para obter mais informações, consulte a "dismissRepositoryVulnerabilityAlert" mutação na documentação da API do GraphQL.

The CodeQL CLI now supports including markdown-rendered query help in SARIF files, so that the help text can be viewed in the Varredura de código UI when the query generates an alert. For more information, see the "GitHub changelog."

The CodeQL CLI and Visual Studio Code extension now support building databases and analyzing code on machines powered by Apple Silicon, such as Apple M1. For more information, see the "GitHub changelog."

The depth of CodeQL's analysis has been improved by adding support for more libraries and frameworks from the Python ecosystem. As a result, CodeQL can now detect even more potential sources of untrusted user data, steps through which that data flows, and potentially dangerous sinks where the data could end up. This results in an overall improvement of the quality of Varredura de código alerts. For more information, see the "GitHub changelog."

Code scanning with CodeQL now includes beta support for analyzing code in all common Ruby versions, up to and including 3.02. For more information, see the "GitHub changelog."

Several improvements have been made to the Varredura de código API:

• The fixed_at timestamp has been added to alerts. This timestamp is the first time that the alert was not detected in an analysis.
• Alert results can now be sorted using sort and direction on either created, updated or number. For more information, see "List code scanning alerts for a repository."
• A Last-Modified header has been added to the alerts and alert endpoint response. For more information, see Last-Modified in the Mozilla documentation.
• The relatedLocations field has been added to the SARIF response when you request a code scanning analysis. The field may contain locations which are not the primary location of the alert. See an example in the SARIF spec and for more information see "Get a code scanning analysis for a repository."
• Both help and tags data have been added to the webhook response alert rule object. For more information, see "Code scanning alert webhooks events and payloads."
• Personal access tokens with the public_repo scope now have write access for code scanning endpoints on public repos, if the user has permission.

For more information, see "Code scanning" in the REST API documentation.

Segurança Avançada GitHub customers can now use the REST API to retrieve private repository secret scanning results at the enterprise level. The new endpoint supplements the existing repository-level and organization-level endpoints. For more information, see "Secret scanning" in the REST API documentation.

Em uma instância de GitHub Enterprise Server recém-configurada sem usuários, um invasor pode criar o primeiro usuário administrador.

As regras de firewall personalizadas são removidas durante o processo de atualização.

Arquivos LFS do Git enviados através da interface web são adicionados diretamente ao repositório e de forma incorreta.

Os problemas não podem ser fechados se contiverem um permalink para um blob no mesmo repositório, onde o caminho do arquivo blob's é maior que 255 caracteres.

Quando "Usuários podem pesquisar pelo GitHub.com" está habilitado com o GitHub Connect, os problemas em repositórios privados e internos não estão incluídos nos resultados de pesquisa do GitHub.com.

O registro npm de GitHub Package Registry não retorna mais o valor de tempo em respostas de metadados. Isso foi feito para permitir melhorias substanciais de desempenho. Continuamos a ter todos os dados necessários para devolver um valor de tempo como parte da resposta aos metadados e retomaremos o retorno desse valor no futuro, assim que tivermos resolvido os problemas de desempenho existentes.

Os limites de recursos que são específicos para processamento de hooks pre-receive podem causar falha em alguns hooks pre-receive.

Actions services needs to be restarted after restoring appliance from backup taken on a different host.

GitHub Enterprise Server 3.0 tornou-se obsoleto em 16 de fevereiro de 2022. Isso significa que não serão feitas versões de patch, mesmo para questões essenciais de segurança, após esta data. Para obter melhor desempenho, melhorar a segurança e novas funcionalidades, faça a atualização para a versão mais recente de GitHub Enterprise Server assim que possível.

GitHub Enterprise Server 3.1 irá tornar-se obsoleto em 3 de junho de 2022. Isso significa que não serão feitas versões de patch, mesmo para questões essenciais de segurança, após esta data. Para obter melhor desempenho, melhorar a segurança e novas funcionalidades, faça a atualização para a versão mais recente de GitHub Enterprise Server assim que possível.

Começando com GitHub Enterprise Server 3.3, GitHub Enterprise Server no XenServer tornou-se obsoleto e não é mais compatível. Entre em contato com o suporte do GitHub em caso de dúvidas.

Due to low usage, we have deprecated the Content References API preview in GitHub Enterprise Server 3.4. The API was previously accessible with the corsair-preview header. Users can continue to navigate to external URLs without this API. Any registered usages of the Content References API will no longer receive a webhook notification for URLs from your registered domain(s) and we no longer return valid response codes for attempted updates to existing content attachments.

The Codes of Conduct API preview, which was accessible with the scarlet-witch-preview header, is deprecated and no longer accessible in GitHub Enterprise Server 3.4. We instead recommend using the "Get community profile metrics" endpoint to retrieve information about a repository's code of conduct. For more information, see the "Deprecation Notice: Codes of Conduct API preview" in the GitHub changelog.

Starting with GitHub Enterprise Server 3.4, the deprecated version of the OAuth Application API endpoints have been removed. If you encounter 404 error messages on these endpoints, convert your code to the versions of the OAuth Application API that do not have access_tokens in the URL. We've also disabled the use of API authentication using query parameters. We instead recommend using API authentication in the request header.

The CodeQL runner is deprecated in GitHub Enterprise Server 3.4 and is no longer supported. The deprecation only affects users who use CodeQL code scanning in third party CI/CD systems; GitHub Actions users are not affected. We strongly recommend that customers migrate to the CodeQL CLI, which is a feature-complete replacement for the CodeQL runner. For more information, see the GitHub changelog.

Starting in GitHub Enterprise Server 3.1, support for GitHub's proprietary bit-cache extensions began to be phased out. These extensions are deprecated in GitHub Enterprise Server 3.3 onwards.

Any repositories that were already present and active on your GitHub Enterprise Server instance running version 3.1 or 3.2 will have been automatically updated.

Repositories which were not present and active before upgrading to GitHub Enterprise Server 3.3 may not perform optimally until a repository maintenance task is run and has successfully completed.

To start a repository maintenance task manually, browse to https://<hostname>/stafftools/repositories/<owner>/<repository>/network for each affected repository and click the Schedule button.