A versão 13.4 foi lançada com armazenamento HashiCorp para variáveis CI, Agente Kubernetes e central de segurança, bem como recursos alternáveis no Starter
No GitLab, estamos sempre pensando em como podemos ajudar os usuários a reduzir riscos, melhorar a eficiência e melhorar a velocidade de entrega em sua plataforma favorita. Este mês adicionamos muitos novos recursos úteis que expandem os recursos de segurança, reduzem o número de vulnerabilidades, aumentam a eficiência, simplificam o trabalho com o GitLab e ajudam sua equipe a fornecer recursos ainda mais rápido. Esperamos que você ache úteis os principais recursos do lançamento, bem como 53 outros novos recursos, adicionado nesta versão.
Recursos avançados de segurança
Tentamos adicionar vários novos recursos ao GitLab DevSecOps todos os meses, e esta versão não é exceção. no âmbito da montagem e implantação. Além disso, as organizações que desejam apoiar a separação de responsabilidades de implantação de código podem agora . Este papel corresponde e permitirá que você confirme solicitações de mesclagem (na localização russa das “solicitações de mesclagem” do GitLab) e implante o código em ambientes seguros, sem fornecer acesso para alterar o código em si.
Outra forma de reduzir riscos é usar novos . As equipes de operações podem implantar clusters Kubernetes do GitLab sem precisar expor seu cluster a toda a Internet. Também estamos introduzindo suporte de controle automático de versão para novos arquivos de estado do Terraform com para oferecer suporte à conformidade e facilidade de depuração. Finalmente, o painel de segurança da instância tornou-se com relatórios de vulnerabilidade e configurações de segurança.
Trabalho mais conveniente e eficiente com GitLab
Melhoramos nossa pesquisa global para incluir , permitindo que você navegue facilmente até os tickets, grupos, projetos, configurações e tópicos de ajuda mais recentes. Temos o prazer de anunciar que o GitLab Pages para redirecionar páginas e diretórios individuais dentro do site, o que permitirá aos usuários implantar seus sites com mais eficiência. E para aqueles que gostariam de receber informações ampliadas sobre a implantação, esta versão permite !
Contribuições de código aberto
Estavam presentes que eu adicionei . As marcas na cobertura do teste de unidade do código alterado dão aos desenvolvedores uma ideia clara da cobertura do código durante a revisão; essas informações ajudam a acelerar as revisões e reduzir o tempo de fusão e implantação de novo código. E nós também e planejar .
E isso é apenas o começo!
Como sempre, há muito pouco espaço na visão geral, mas há muitos recursos interessantes na versão 13.4. Aqui estão mais alguns:
- .
Se você quiser saber com antecedência o que o espera em próximo solte, dê uma olhada .
.
este mês -
Fábio contribuiu significativamente в - um recurso aguardado há muito tempo na comunidade GitLab. Esta é uma contribuição verdadeiramente importante com mudanças não triviais que exigiram colaboração constante com os membros da equipe do GitLab e afetaram muitas áreas do projeto, como UX, front-end e back-end.
Principais recursos da versão GitLab 13.4
Use chaves HashiCorp Vault em trabalhos de CI
(PREMIUM, ULTIMATE, PRATA, OURO)
Na versão 12.10, o GitLab introduziu a capacidade de receber e transferir chaves para trabalhos de CI usando o manipulador de trabalhos GitLab (executor GitLab). Agora estamos expandindo , adicionando nova sintaxe secrets arquivar .gitlab-ci.yml. Isso tornará mais fácil configurar e usar o repositório HashiCorp com GitLab.
и .
Apresentando o Agente GitLab Kubernetes
(PRÊMIO, FINAL)
A integração do GitLab com o Kubernetes há muito tempo possibilita a implantação em clusters do Kubernetes sem a necessidade de configuração manual. Muitos usuários gostaram da facilidade de uso deste pacote, enquanto outros encontraram algumas dificuldades. Para a integração atual, seu cluster deve estar acessível pela Internet para que o GitLab possa acessá-lo. Para muitas organizações, isso não é possível porque elas restringem o acesso aos clusters por motivos de segurança, conformidade ou regulatórios. Para contornar essas restrições, os usuários precisavam construir suas ferramentas em cima do GitLab, caso contrário não seriam capazes de usar esse recurso.
Hoje estamos apresentando o Agente GitLab Kubernetes, uma nova maneira de implantar em clusters Kubernetes. O agente é executado dentro do seu cluster, portanto você não precisa expô-lo a toda a Internet. O agente coordena a implantação solicitando novas alterações do GitLab, em vez de o GitLab enviar atualizações para o cluster. Não importa qual método GitOps você usa, o GitLab tem o que você precisa.
Observe que este é o primeiro lançamento do agente. Nosso foco atual para o GitLab Kubernetes Agent é configurar e gerenciar implantações por meio de código. Alguns recursos de integração existentes do Kubernetes, como placas de implantação e aplicativos gerenciados pelo GitLab, ainda não são suportados. que essas capacidades serão adicionadas ao agente em versões futuras, bem como novas integrações focadas em segurança e conformidade.
и .
Conceda aos usuários permissões de implantação sem acesso ao código
(PREMIUM, ULTIMATE, PRATA, OURO)
Anteriormente, o sistema de permissões do GitLab dificultava a divisão adequada de responsabilidades dentro de sua equipe entre os responsáveis pelo desenvolvimento e os responsáveis pela implantação. Com o lançamento do GitLab 13.4, você pode dar permissão para aprovar solicitações de mesclagem para implantação, bem como para realmente implantar código para pessoas que não escrevem o código, sem conceder-lhes direitos de acesso de mantenedor (na localização russa do “mantenedor” do GitLab ).
и .
Centro de Segurança
(FULTIMADO, OURO)
Anteriormente, o gerenciamento de vulnerabilidades em nível de instância era limitado tanto em funcionalidade quanto em flexibilidade. A interface era uma página única que combina detalhes de vulnerabilidades, gráficos de métricas e configurações. Não há muito espaço para desenvolver esses recursos ou usar outros recursos de segurança.
Fizemos mudanças fundamentais na forma como gerenciamos a segurança e a transparência no GitLab. O painel de segurança da instância foi transformado em uma central de segurança completa. A maior mudança é a introdução de uma nova estrutura de menu: em vez de uma página, agora você vê o painel de segurança, o relatório de vulnerabilidade e a seção de configurações separadamente. Embora a funcionalidade não tenha mudado, dividi-la em partes permitirá melhorias nesta seção que de outra forma seriam difíceis. Isso também prepara o terreno para a adição de outros recursos relacionados à segurança no futuro.
A seção dedicada ao Relatório de Vulnerabilidades agora tem mais espaço para exibir detalhes importantes. Aqui estão as vulnerabilidades que estão atualmente na lista de vulnerabilidades do projeto. Mover widgets com métricas de vulnerabilidade para uma seção separada cria um painel de controle de segurança conveniente. Agora é uma tela para visualizações futuras – não apenas para gerenciamento de vulnerabilidades, mas para quaisquer métricas relacionadas à segurança. Por fim, uma área de configurações separada cria um espaço comum para todas as configurações de segurança em nível de instância, não apenas para o gerenciamento de vulnerabilidades.
и .
Recursos alternáveis agora estão no GitLab Starter
(STARTER, PREMIUM, ULTIMATE, BRONZE, PRATA, OURO)
GitLab 11.4 foi lançado . Em 12.2 introduzimos estratégias para eles и , e em 13.1 eles adicionaram и para diferentes ambientes.
No início deste ano, o GitLab assumiu um compromisso em código aberto. Nesta versão, concluímos a migração dos recursos alternáveis para o plano Starter e continuaremos a migrá-los para o Core do . Estamos entusiasmados em trazer esse recurso para mais usuários e queremos saber como você o usa.
и .
Navegação rápida na barra de pesquisa
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUITO, BRONZE, PRATA, OURO)
Às vezes, ao navegar no GitLab, você deseja ir direto para um projeto específico, em vez da página de resultados da pesquisa.
Usando a barra de pesquisa global, você pode navegar rapidamente até os tickets, grupos, projetos, configurações e tópicos de ajuda mais recentes. Você pode até usar uma tecla de atalho /para mover o cursor para a barra de pesquisa para navegar no GitLab com ainda mais eficiência!
и .
Mostrando cobertura de código em diferenças de solicitação de mesclagem
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUITO, BRONZE, PRATA, OURO)
Ao revisar uma solicitação de mesclagem, pode ser difícil determinar se o código alterado é coberto por testes unitários. Em vez disso, os revisores podem confiar na cobertura geral e solicitar que ela seja aumentada antes de aprovar uma solicitação de mesclagem. Isso pode levar a uma abordagem aleatória para escrever testes, o que na verdade não melhorará a qualidade do código ou a cobertura do teste.
Agora, ao visualizar uma comparação de solicitação de mesclagem, você verá uma exibição visual da cobertura do código. Novas marcas permitirão que você entenda rapidamente se o código alterado é coberto por um teste de unidade, o que ajudará a acelerar a revisão do código e o tempo de mesclagem e implantação do novo código.
Obrigado e Siemens por esse recurso!
и .
Mais ambientes e projetos no painel Ambientes
(PREMIUM, ULTIMATE, PRATA, OURO)
Desde o lançamento do GitLab 12.5 usando você poderia monitorar o estado dos ambientes, mas não mais do que sete ambientes em três projetos. Aprimoramos esse painel na versão 13.4 paginando-o para ajudar você a manter e gerenciar seus ambientes em escala. Agora você pode ver mais ambientes em mais projetos.
и .
GitLab assume o controle do provedor GitLab Terraform
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUITO, BRONZE, PRATA, OURO)
Nós recentemente e planejar . No último mês, aceitamos 21 solicitações de mesclagem e fechamos 31 tickets, incluindo alguns bugs antigos e recursos ausentes, como ... Você pode na documentação do Terraform.
и .
Teste de API difuso com especificações OpenAPI ou arquivo HAR
(FULTIMADO, OURO)
O teste de difusão de API é uma ótima maneira de encontrar bugs e vulnerabilidades em seus aplicativos da web e APIs que outros scanners e métodos de teste podem não perceber.
O teste de difusão de API no GitLab permite que você forneça ou seu aplicativo e, em seguida, gera automaticamente dados de entrada aleatórios projetados para testar casos extremos e encontrar bugs. Os resultados são imediatamente visíveis em seu pipeline.
Este é nosso primeiro lançamento de teste fuzz de API e adoraríamos saber sua opinião. Temos mais em estoque para testes de fuzz , que basearemos no lançamento deste recurso.
и .
Visualize novos gráficos no painel de métricas
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUITO, BRONZE, PRATA, OURO)
Anteriormente, criar um gráfico no painel de métricas do GitLab não era uma tarefa fácil. Depois de criar a métrica no arquivo YAML do painel, você fez alterações em master, sem poder verificar se o gráfico recém-criado funciona exatamente como você precisa. A partir desta versão, você pode visualizar as alterações à medida que cria o gráfico, tendo uma ideia do resultado antes de enviar as alterações para o arquivo YAML do painel.
и .
Dados de cobertura de código por testes para todos os projetos do grupo
(PREMIUM, ULTIMATE, PRATA, OURO)
Ao gerenciar um grande número de projetos no GitLab, você precisa de uma única fonte de informações sobre como a cobertura do código muda ao longo do tempo em todos os projetos. Anteriormente, exibir essas informações exigia um trabalho manual tedioso e demorado: era necessário baixar os dados de cobertura de código de cada projeto e combiná-los em uma tabela.
Na versão 13.4, tornou-se possível montar de forma fácil e rápida .csv arquivo com todos os dados de cobertura de código para todos os projetos do grupo ou para uma seleção de projetos. Este recurso é MVC, será seguido pela capacidade .
и .
Suporte para novos idiomas para testes fuzz completos
(FULTIMADO, OURO)
Esta versão apresenta suporte para vários novos idiomas para testes fuzz visando cobertura total.
Agora você pode avaliar todos os recursos de testes de difusão em seus aplicativos Java, Rust e Swift e encontrar erros e vulnerabilidades que outros scanners e métodos de teste podem não perceber.
и .
Alertas na página principal do ambiente
(PREMIUM, ULTIMATE, PRATA, OURO)
A página Ambientes mostra o estado geral dos seus ambientes. Nesta versão melhoramos esta página adicionando exibição de alerta. Os alertas acionados juntamente com o status dos seus ambientes ajudarão você a tomar medidas rapidamente para corrigir as situações que surgirem.
и .
Pipelines aninhados agora podem executar seus próprios pipelines aninhados
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUITO, BRONZE, PRATA, OURO)
Ao usar pipelines aninhados, agora é possível executar novos pipelines dentro de pipelines filhos. O nível extra de profundidade pode ser útil se você precisar de flexibilidade para gerar um número variável de pipelines.
Anteriormente, ao usar pipelines aninhados, cada pipeline filho exigia que um trabalho de gatilho fosse definido manualmente no pipeline pai. Agora você pode criar pipelines aninhados que iniciarão dinamicamente qualquer número de novos pipelines aninhados. Por exemplo, se você tiver um monorepositório, poderá gerar dinamicamente o primeiro subpipeline, que criará o número necessário de novos pipelines com base nas alterações na ramificação.
и .
Navegação aprimorada entre pipelines pai e aninhados
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUITO, BRONZE, PRATA, OURO)
Anteriormente, navegar entre pipelines pai e aninhados não era muito conveniente - eram necessários muitos cliques para chegar ao pipeline desejado. Também não foi fácil descobrir qual trabalho iniciou o pipeline. Agora será muito mais fácil ver as conexões entre pipelines pai e aninhados.
и .
Empregos de matriz paralela mostram variáveis relevantes no cargo
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUITO, BRONZE, PRATA, OURO)
Se você usou , você deve ter notado que era difícil determinar qual variável de matriz era usada para um trabalho específico, pois os nomes dos trabalhos pareciam matrix 1/4. Na versão 13.4, você verá os valores das variáveis relevantes que foram usadas naquele trabalho em vez do nome genérico do trabalho. Por exemplo, se o seu objetivo é depurar a arquitetura x86, então o trabalho seria chamado matrix: debug x86.
и .
Outras melhorias no GitLab 13.4
Conectando uma conta Atlassian
(CORE, STARTER, PREMIUM, FINAL)
Os usuários do GitLab agora poderão conectar suas contas do GitLab à sua conta do Atlassian Cloud. Isso permitirá que você faça login no GitLab com suas credenciais da Atlassian e também estabelecerá as bases para futuras melhorias de integração. e com outros produtos da linha Atlassian.
и .
Exportando uma lista de todos os commits de mesclagem
(FULTIMADO, OURO)
As organizações focadas em conformidade precisam de uma forma de mostrar aos auditores uma visão holística dos componentes associados a qualquer mudança na produção. No GitLab, isso significa coletar tudo em um só lugar: solicitações de mesclagem, tickets, pipelines, verificações de segurança e outros dados de commit. Até agora, você tinha que coletá-las manualmente no GitLab ou configurar suas ferramentas para coletar as informações, o que não era muito eficiente.
Agora você pode coletar e exportar esses dados de forma programática para atender aos requisitos de auditoria ou realizar outras análises. Para exportar uma lista de todos os commits de mesclagem do grupo atual, você precisa ir para e clique no botão Lista de todos os commits de mesclagem. O arquivo resultante conterá todos os commits da solicitação de mesclagem, seu autor, ID da solicitação de mesclagem associada, grupo, projeto, confirmadores e outras informações.
и .
Liste e gerencie tokens de acesso pessoal via API
(FULTIMADO, OURO)
Gerenciar o acesso ao namespace GitLab é uma parte importante dos esforços de conformidade. Dos princípios de menor privilégio à desativação do acesso cronometrado, pode haver vários requisitos associados aos tokens de acesso pessoal no GitLab. Para facilitar a manutenção e o gerenciamento de todas essas credenciais de usuário em seu namespace, fornecemos a capacidade de listar todos os tokens de acesso pessoal e, opcionalmente, via API.
Essas melhorias na API do GitLab permitem que os usuários listem e revoguem seus próprios tokens de acesso pessoal e que os administradores listem e revoguem os tokens de seus usuários. Agora será mais fácil para os administradores ver quem tem acesso ao seu namespace, tomar decisões de acesso com base nos dados do usuário e revogar tokens de acesso pessoal que possam ter sido comprometidos ou que estejam fora das políticas de gerenciamento de acesso da empresa.
и .
Problemas relacionados e outros recursos estão agora no GitLab Core
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUITO, BRONZE, PRATA, OURO)
Há alguns meses anunciámos um plano para . Ao trabalhar para cumprir esta promessa, fizemos , и (na localização russa do “quadro de discussão” do GitLab) disponível no plano Core. Isso vale apenas para relacionamentos “vinculados a”, “bloqueios” e relacionamentos “bloqueados” permanecem nos planos pagos.
и .
Exibindo o nome da ramificação de origem na barra lateral da solicitação de mesclagem
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUITO, BRONZE, PRATA, OURO)
Ao revisar alterações de código, discussões e confirmações de solicitações de mesclagem, geralmente é desejável fazer uma verificação local da ramificação para uma revisão mais profunda. No entanto, encontrar o nome do thread se torna cada vez mais difícil à medida que mais conteúdo é adicionado à descrição da solicitação de mesclagem e você precisa rolar a página para baixo.
Adicionamos o nome do branch à barra lateral da solicitação de mesclagem, tornando-o acessível a qualquer momento e eliminando a necessidade de rolar a página inteira. Assim como o link para a solicitação de mesclagem, a seção da ramificação de origem contém um conveniente botão “copiar”.
Obrigado pela sua enorme contribuição para o desenvolvimento deste recurso!
и .
Indicação da presença de arquivos recolhidos em diferenças de solicitação de mesclagem
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUITO, BRONZE, PRATA, OURO)
As solicitações de mesclagem que adicionam alterações a vários arquivos às vezes reduzem as diferenças de arquivos grandes para melhorar o desempenho de renderização. Quando isso acontece, é possível pular acidentalmente um arquivo durante a revisão, especialmente em solicitações de mesclagem com um grande número de arquivos. A partir da versão 13.4, as solicitações de mesclagem sinalizarão diferenças que contêm arquivos dobrados, para que você não perca esses arquivos durante a revisão do código. Para maior clareza, planejamos adicionar destaque a esses arquivos em uma versão futura. Fique atento às atualizações sobre .
и .
Aviso sobre a presença de arquivos recolhidos na comparação de uma solicitação de mesclagem
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUITO, BRONZE, PRATA, OURO)
Na seção de diferenças de solicitação de mesclagem, arquivos grandes são recolhidos para melhorar o desempenho. No entanto, ao revisar o código, alguns arquivos podem ser perdidos quando o revisor percorre a lista de arquivos, pois todos os arquivos grandes são recolhidos.
Adicionamos um aviso visível na parte superior da página de comparação de solicitações de mesclagem para informar aos usuários que há um arquivo mesclado nesta seção. Dessa forma, você não perderá nenhuma alteração na solicitação de mesclagem durante a revisão.
и .
Recuperação automática do repositório de cluster Gitaly
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUITO, BRONZE, PRATA, OURO)
Anteriormente, quando o nó primário de um cluster Gitaly ficava offline, os repositórios desse nó eram marcados como somente leitura. Isso evitou a perda de dados em situações em que houve alterações no nó que ainda não haviam sido replicadas. Quando o nó voltou a ficar online, o GitLab não foi restaurado automaticamente e os administradores tiveram que iniciar manualmente o processo de sincronização ou aceitar a perda de dados. Outras situações, como a falha de uma tarefa de replicação em um nó secundário, também podem resultar em repositórios obsoletos ou somente leitura. Nesse caso, o repositório permaneceu obsoleto até que ocorresse a próxima operação de gravação, que iniciaria o trabalho de replicação.
Para resolver este problema agora agenda um trabalho de replicação quando detecta um repositório desatualizado em um nó e a versão mais recente do repositório em outro. Este trabalho de replicação mantém o repositório atualizado automaticamente, eliminando a necessidade de restaurar dados manualmente. A recuperação automática também garante que os nós secundários sejam atualizados rapidamente se uma tarefa de replicação falhar, em vez de aguardar pela próxima operação de gravação. Como muitos clusters Gilaly armazenam um grande número de repositórios, isso reduz significativamente o tempo que os administradores e engenheiros de confiabilidade gastam na recuperação de dados após um erro.
Além disso, o reparo automático inicia a replicação de repositórios em qualquer novo nó Gitaly adicionado ao cluster, eliminando o trabalho manual ao adicionar novos nós.
и .
Marcar uma tarefa pendente como concluída na página de design
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUITO, BRONZE, PRATA, OURO)
A comunicação eficaz no GitLab é baseada em listas de tarefas. Se você for mencionado em um comentário, é fundamental poder pular para uma tarefa e começar a fazer algo ou marcá-la como concluída. Também é importante poder atribuir uma tarefa a si mesmo quando precisar trabalhar em algo ou voltar a fazê-lo mais tarde.
Anteriormente, não era possível adicionar tarefas ou marcá-las como concluídas ao trabalhar com designs. Isso prejudicou seriamente a eficiência da comunicação entre as equipes de produto, uma vez que as tarefas são um elemento crítico do fluxo de trabalho do GitLab.
Na versão 13.4, os designs acompanham os comentários dos tickets no uso de tarefas, o que torna o trabalho com eles mais consistente e eficiente.
и .
Guia de solução de problemas aprimorado para CI/CD
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUITO, BRONZE, PRATA, OURO)
Melhoramos o guia de solução de problemas do CI/CD do GitLab com mais informações sobre problemas comuns que você pode encontrar. Esperamos que a documentação aprimorada seja um recurso valioso para ajudá-lo a instalar e executar o CI/CD do GitLab de maneira rápida e fácil.
и .
As solicitações de mesclagem não saem mais da fila de mesclagem
(PREMIUM, ULTIMATE, PRATA, OURO)
Anteriormente, as solicitações de mesclagem podiam sair da fila de mesclagem acidentalmente devido a comentários tardios. Se uma solicitação de mesclagem já estivesse na fila e alguém adicionasse um comentário a ela que criasse uma nova discussão não resolvida, a solicitação de mesclagem seria considerada inelegível para uma mesclagem e sairia da fila. Agora, depois que uma solicitação de mesclagem é adicionada à fila de mesclagem, novos comentários podem ser adicionados sem medo de interromper o processo de mesclagem.
и .
Exibindo o valor de cobertura de código para uma tarefa em uma solicitação de mesclagem
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUITO, BRONZE, PRATA, OURO)
Os desenvolvedores devem ser capazes de ver o valor da cobertura do código após a conclusão do pipeline, mesmo em cenários complexos, como a execução de um pipeline com vários trabalhos que precisam ser analisados para calcular o valor da cobertura. Anteriormente, o widget de solicitação de mesclagem mostrava apenas a média desses valores, o que significava que você tinha que navegar até a página do trabalho e voltar à solicitação de mesclagem para obter valores de cobertura intermediários. Para economizar seu tempo e essas etapas extras, fizemos o widget exibir o valor médio de cobertura, suas alterações entre as ramificações de destino e de origem e uma dica de ferramenta que mostra o valor de cobertura para cada trabalho com base no qual a média foi calculada.
и .
Removendo pacotes do registro de pacotes ao visualizar um grupo
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUITO, BRONZE, PRATA, OURO)
O registro de pacotes GitLab é um local para armazenar e distribuir pacotes em diferentes formatos. Quando você tem muitos pacotes em seu projeto ou grupo, você precisa identificar rapidamente os pacotes não utilizados e removê-los para evitar que pessoas os baixem. Você pode remover pacotes do seu registro via ou por meio da interface do usuário do registro de pacotes. No entanto, até agora não era possível remover pacotes ao visualizar um grupo por meio da IU. Como resultado, você tinha que remover pacotes desnecessários por projeto, o que era ineficiente.
Agora você pode remover pacotes ao visualizar o registro de pacotes de um grupo. Basta acessar a página de registro de pacotes do grupo, filtrar os pacotes por nome e remover aqueles que você não precisa.
и .
Dimensionando pacotes Conan para o nível do projeto
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUITO, BRONZE, PRATA, OURO)
Você pode usar o repositório Conan no GitLab para publicar e distribuir dependências C/C++. No entanto, os pacotes anteriores só podiam ser dimensionados para o nível da instância, já que o nome do pacote Conan só podia ter no máximo 51 caracteres. Se você quisesse publicar um pacote de um subgrupo, por exemplo gitlab-org/ci-cd/package-stage/feature-testing/conan, era quase impossível de fazer.
Agora você pode reduzir os pacotes do Conan até o nível do projeto, facilitando a publicação e distribuição das dependências dos seus projetos.
и .
Suporte para novos gerenciadores de pacotes e linguagens para verificação de dependências
(FULTIMADO, OURO)
Estamos entusiasmados em adicionar verificações de dependência para projetos de código C, C++, C# e .Net que usam gerenciadores de pacotes NuGet 4.9+ ou Conan à nossa lista . Agora você pode ativar a verificação de dependências como parte do estágio Seguro para verificar vulnerabilidades conhecidas em dependências adicionadas por meio de gerenciadores de pacotes. As vulnerabilidades encontradas serão exibidas em sua solicitação de mesclagem junto com seu nível de gravidade, para que você saiba antes de executar a mesclagem quais riscos a nova dependência acarreta. Você também pode configurar seu projeto para exigir para dependências com vulnerabilidades com níveis de severidade crítico (Crítico), alto (Alto) ou desconhecido (Desconhecido).
и .
Notificações ao alterar a configuração da solicitação de mesclagem para 'Mesclar quando o pipeline for concluído com sucesso'
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUITO, BRONZE, PRATA, OURO)
Anteriormente, ao definir as configurações de solicitação de mesclagem Mesclar quando o pipeline terminar (Mesclar quando o pipeline for bem-sucedido, MWPS) nenhuma notificação por e-mail foi enviada. Você tinha que verificar manualmente o status ou aguardar uma notificação de mesclagem. Com esta versão, temos o prazer de apresentar contribuições de usuários , que resolveu esse problema adicionando notificações automáticas a todos os inscritos em uma solicitação de mesclagem quando um revisor altera a configuração de mesclagem para MWPS.
и .
Criação de clusters EKS com uma versão do Kubernetes especificada pelo usuário
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUITO, BRONZE, PRATA, OURO)
Os usuários do GitLab agora podem escolher a versão do Kubernetes que será fornecida pelo EKS; você pode escolher entre as versões 1.14–1.17.
и .
Criação de incidentes como tipos de ticket
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUITO, BRONZE, PRATA, OURO)
Nem todo problema que surge aciona alertas imediatamente: os usuários relatam interrupções e os membros da equipe investigam problemas de desempenho. Os incidentes agora são um tipo de ticket, para que suas equipes possam criá-los rapidamente como parte do fluxo de trabalho normal. Clique Nova tarefa de qualquer lugar no GitLab e em campo tipo selecionar O incidente.
и .
Mencionando alertas do GitLab no Markdown
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUITO, BRONZE, PRATA, OURO)
Melhoramos os alertas do GitLab adicionando um novo tipo de menção especificamente para eles no GitLab Markdown, tornando mais fácil compartilhar e mencionar alertas. Usar ^alert#1234mencionar o alerta em qualquer campo Markdown: em incidentes, tickets ou solicitações de mesclagem. Isso também ajudará você a identificar trabalhos criados a partir de alertas, em vez de tickets ou solicitações de mesclagem.
и .
Visualizando a carga de alerta por incidente
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUITO, BRONZE, PRATA, OURO)
A descrição do alerta contém informações essenciais para solução de problemas e recuperação, e essas informações devem ser facilmente acessíveis para que você não precise alternar entre ferramentas ou guias enquanto trabalha para resolver um incidente. Os incidentes criados a partir de alertas exibem a descrição completa do alerta na guia Detalhes do alerta.
Pesquisa avançada 75% mais rápida
(STARTER, PREMIUM, ULTIMATE, BRONZE, PRATA, OURO)
O GitLab, como um aplicativo único, tem a capacidade única de agilizar a descoberta de conteúdo em todo o seu fluxo de trabalho DevOps. No GitLab 13.4, a pesquisa avançada retorna resultados 75% mais rápido quando , como em GitLab.com.
и .
Visualizando projetos excluídos para administradores
(CORE, STARTER, PREMIUM, FINAL)
Havia uma opção para adiar a exclusão do projeto . Porém, anteriormente não era possível visualizar todos os projetos aguardando exclusão em um só lugar. Os administradores de instâncias de usuários do GitLab agora podem visualizar todos os projetos de exclusão pendentes em um só lugar, junto com botões para restaurar facilmente esses projetos.
Esse recurso oferece aos administradores maior controle sobre a exclusão de projetos, coletando todas as informações relevantes em um só lugar e fornecendo a capacidade de desfazer ações de exclusão indesejadas.
Obrigado para esse recurso!
и .
Adicionado suporte para regras de envio de grupo à API
(STARTER, PREMIUM, ULTIMATE, BRONZE, PRATA, OURO)
Anteriormente, as regras de push de grupo só podiam ser configuradas visitando cada grupo individualmente por meio da IU do GitLab e aplicando essas regras. Agora você pode gerenciar essas regras por meio de uma API para oferecer suporte às suas ferramentas personalizadas e à automação do GitLab.
и .
Revogação de tokens de acesso pessoal para armazenamento de credenciais autogerenciado
(FINAL)
Fornece aos administradores as informações necessárias para gerenciar credenciais de usuário para sua instância do GitLab. Como as organizações focadas em conformidade variam no rigor de suas políticas de gerenciamento de credenciais, adicionamos um botão que permite aos administradores revogar opcionalmente o token de acesso pessoal (PAT) de um usuário. Os administradores agora podem revogar facilmente PATs potencialmente comprometidos. Esse recurso é útil para organizações que desejam opções de conformidade mais flexíveis para minimizar interrupções para seus usuários.
и .
Arquivo de configuração para o editor de site estático
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUITO, BRONZE, PRATA, OURO)
No GitLab 13.4, apresentamos uma nova maneira de personalizar o editor de site estático. Embora o arquivo de configuração não salve nem receba nenhuma configuração nesta versão, estamos preparando as bases para futuras personalizações do comportamento do editor. Em versões futuras adicionaremos ao arquivo .gitlab/static-site-editor.yml parâmetros para instalação em que , substituindo as configurações de sintaxe do Markdown e outras configurações do editor.
и .
Editando a parte introdutória de um arquivo usando um editor de site estático
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUITO, BRONZE, PRATA, OURO)
Front Matter é uma maneira flexível e conveniente de definir variáveis de página em arquivos de dados para processamento pelo gerador de site estático. Normalmente é usado para definir o título da página, modelo de layout ou autor, mas pode ser usado para passar qualquer tipo de metadados ao gerador ao renderizar a página em HTML. Incluída no topo de cada arquivo de dados, a parte introdutória normalmente é formatada como YAML ou JSON e requer sintaxe consistente e precisa. Os usuários não familiarizados com regras de sintaxe específicas podem inserir inadvertidamente marcações inválidas, o que, por sua vez, pode causar problemas de formatação ou até mesmo falhas de compilação.
O modo de edição WYSIWYG do editor de site estático já remove a introdução do editor para evitar esses erros de formatação. Porém, isso evita que você altere os valores armazenados nesta parte sem retornar à edição no modo fonte. No GitLab 13.4, você pode acessar qualquer campo e editar seu valor em uma interface familiar baseada em formulários. Quando o botão é pressionado configurações (Configurações) será aberto um painel mostrando um campo de formulário para cada chave definida no início. Os campos são preenchidos com o valor atual e editar qualquer um deles é tão simples quanto inseri-lo no formulário web. Editar a introdução dessa forma evita sintaxe complexa e oferece controle total sobre o conteúdo, ao mesmo tempo que garante que o resultado final seja formatado de forma consistente.
и .
GitLab para Jira e DVCS Connector agora está no Core
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUITO, BRONZE, PRATA, OURO)
Para usuários do Jira no GitLab: и permitem que você exiba informações sobre confirmações do GitLab e solicitações de mesclagem diretamente no Jira. Combinado com nossa integração integrada ao Jira, você pode alternar facilmente entre os dois aplicativos enquanto trabalha.
Anteriormente, esses recursos estavam disponíveis apenas em nosso plano Premium, mas agora estão disponíveis para todos os usuários!
и .
Votação majoritária para transações do cluster Gitaly (beta)
(CORE, STARTER, PREMIUM, FINAL)
Um cluster Gitaly permite replicar repositórios Git para vários nós “quentes” do Gitaly. Isso aumenta a tolerância a falhas, eliminando pontos únicos de falha. , introduzido no GitLab 13.3, faz com que as alterações sejam transmitidas para todos os nós Gitaly no cluster, mas apenas os nós Gitaly que votam de acordo com o nó primário salvam as alterações no disco. Se todos os nós de réplica não concordarem, apenas uma cópia da alteração será armazenada no disco, criando um único ponto de falha até que a replicação assíncrona seja concluída.
A votação majoritária melhora a tolerância a falhas, exigindo o consentimento da maioria dos nós (não todos) antes de salvar as alterações no disco. Se esse recurso de alternância estiver ativado, a gravação deverá ser bem-sucedida em vários nós. Os nós dissidentes são sincronizados automaticamente usando replicação assíncrona dos nós que formaram um quorum.
и .
Suporte de esquema personalizado para validação JSON no Web IDE
(PREMIUM, ULTIMATE, PRATA, OURO)
Projetos onde as pessoas escrevem configurações em JSON ou YAML geralmente estão sujeitos a problemas porque é fácil cometer um erro de digitação e quebrar alguma coisa. É possível escrever ferramentas de inspeção para detectar esses problemas no pipeline de CI, mas usar um arquivo de esquema JSON pode ser útil para fornecer documentação e dicas.
Os participantes do projeto podem definir em seu repositório o caminho para um esquema personalizado em um arquivo .gitlab/.gitlab-webide.yml, que especifica o esquema e o caminho para os arquivos a serem verificados. Ao carregar um arquivo específico no Web IDE, você verá feedback e validação adicionais para ajudá-lo a criar o arquivo.
и .
Limite de ramificação do gráfico acíclico direcionado (DAG) aumentado para 50
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUITO, BRONZE, PRATA, OURO)
Se você estiver usando transportadores (Gráfico Acíclico Direcionado (DAG)), você pode descobrir que há um limite de 10 trabalhos que um trabalho pode especificar em needs:, Muito duro. Na versão 13.4, o limite padrão foi aumentado de 10 para 50 para permitir redes mais complexas de relacionamentos entre trabalhos em seus pipelines.
Se você for administrador de uma instância personalizada do GitLab, poderá aumentar ainda mais esse limite configurando um recurso de alternância, embora não ofereçamos suporte oficial para isso.
и .
Comportamento melhorado needs para tarefas perdidas
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUITO, BRONZE, PRATA, OURO)
Em alguns casos, um trabalho perdido em um pipeline pode ser considerado incorretamente bem-sucedido para dependências especificadas em needs, o que causou a execução de trabalhos subsequentes, o que não deveria ter acontecido. Este comportamento foi corrigido na versão 13.4 e needs agora lida corretamente com casos de tarefas perdidas.
и .
Fixe o último artefato da missão para evitar que ele seja excluído
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUITO, BRONZE, PRATA, OURO)
O GitLab agora bloqueia automaticamente o último trabalho bem-sucedido e artefato de pipeline em qualquer branch ativo, solicitação de mesclagem ou tag para evitar que seja excluído após a expiração. Torna-se mais fácil definir regras de expiração mais agressivas para limpar artefatos antigos. Isso ajuda a reduzir o consumo de espaço em disco e garante que você sempre tenha uma cópia do artefato mais recente do pipeline.
и .
Guia CI/CD para otimização de pipeline
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUITO, BRONZE, PRATA, OURO)
Otimizar seu pipeline de CI/CD pode melhorar a velocidade de entrega e economizar dinheiro. Melhoramos nossa documentação para incluir um guia rápido para aproveitar ao máximo a otimização de seus pipelines.
и .
Relatório de teste classificado por status de teste
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUITO, BRONZE, PRATA, OURO)
é uma maneira fácil de ver os resultados de todos os testes em um pipeline. No entanto, com um grande número de testes, encontrar testes que falharam pode levar muito tempo. Outros problemas que podem dificultar o uso do relatório incluem a dificuldade de percorrer saídas de rastreamento longas e o arredondamento do tempo para zero para testes executados em menos de 1 segundo. Agora, por padrão, ao classificar um relatório de teste, ele primeiro coloca os testes com falha no início do relatório e depois classifica os testes por duração. Isso torna mais fácil encontrar falhas e testes longos. Além disso, as durações dos testes agora são exibidas em milissegundos ou segundos, tornando-os muito mais rápidos de ler, e problemas anteriores de rolagem também foram resolvidos.
и .
Limites no tamanho dos arquivos enviados para o registro do pacote
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUITO, BRONZE, PRATA, OURO)
Agora existem limites para o tamanho dos arquivos de pacote que podem ser carregados no registro de pacotes do GitLab. Foram adicionadas restrições para otimizar o desempenho do registro de pacotes e evitar abusos. Os limites variam dependendo do formato do pacote. Para GitLab.com, os tamanhos máximos de arquivo são:
- Conan: 250MB
- Maven: 3 GB
- NPM: 300MB
- NuGet: 250MB
- PyPI: 3 GB
Para instâncias personalizadas do GitLab, os padrões são os mesmos. No entanto, o administrador pode atualizar as restrições usando .
и .
Use CI_JOB_TOKEN para publicar pacotes PyPI
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUITO, BRONZE, PRATA, OURO)
Você pode usar o repositório PyPI do GitLab para criar, publicar e compartilhar pacotes Python junto com código-fonte e pipelines de CI/CD. No entanto, anteriormente não era possível autenticar no repositório usando uma variável de ambiente predefinida CI_JOB_TOKEN. Como resultado, você teve que usar suas credenciais pessoais para atualizar o repositório PyPI ou pode ter decidido não usar o repositório.
Agora é mais fácil usar GitLab CI/CD para publicar e instalar pacotes PyPI usando uma variável de ambiente predefinida CI_JOB_TOKEN.
и .
Perfis de scanner DAST mediante solicitação
(FULTIMADO, OURO)
Para a varredura DAST sob demanda que foi , os perfis do scanner DAST foram adicionados. Eles ampliam os recursos de configuração dessas verificações, permitindo criar rapidamente vários perfis para abranger vários tipos de verificação. Na versão 13.4, o perfil do rastreador inclui nativamente uma configuração de tempo limite do rastreador que define por quanto tempo o rastreador DAST deve ser executado enquanto tenta descobrir todas as páginas de um site rastreado. O perfil também inclui uma configuração de tempo limite do site de destino para definir quanto tempo o rastreador deve esperar até que um site se torne acessível antes de abortar o rastreamento se o site não responder com um código de status 200 ou 300. À medida que continuarmos a melhorar, esse recurso será adicionado ao perfil do scanner em versões futuras; parâmetros de configuração adicionais serão adicionados.
и .
Um arquivo de configuração de redirecionamento simples para páginas GitLab
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUITO, BRONZE, PRATA, OURO)
Se você usa GitLab Pages e deseja gerenciar melhor as alterações de URL, deve ter notado que não era possível gerenciar redirecionamentos em seu site GitLab Pages. O GitLab agora permite que você configure regras para redirecionar uma URL para outra no seu site Pages, adicionando um arquivo de configuração ao repositório. Este recurso é possível graças à contribuição de Kevin Barnett (), nosso Eric Eastwood () e equipes do GitLab. Obrigado a todos pela sua contribuição.
и .
Estado do Terraform gerenciado pelo GitLab
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUITO, BRONZE, PRATA, OURO)
O acesso às versões anteriores do estado do Terraform é necessário tanto para conformidade quanto para depuração, se necessário. O suporte para versionamento do estado do Terraform gerenciado pelo GitLab é fornecido a partir do GitLab 13.4. O versionamento é habilitado automaticamente para novos arquivos de estado do Terraform. Os arquivos de estado existentes do Terraform serão em uma versão posterior.
и .
Detalhes importantes da notificação de incidentes
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUITO, BRONZE, PRATA, OURO)
Ao processar incidentes, você precisa determinar facilmente por quanto tempo um alerta ficou aberto e quantas vezes o evento foi acionado. Esses detalhes costumam ser essenciais para determinar o impacto no cliente e o que sua equipe deve abordar primeiro. No novo painel Detalhes do incidente, exibimos o horário de início do alerta, o número de eventos e um link para o alerta original. Essas informações estão disponíveis para incidentes gerados a partir de alertas.
и .
Configurando e editando o parâmetro de gravidade do incidente
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUITO, BRONZE, PRATA, OURO)
A dimensão Gravidade do Incidente permite que os socorristas e as partes interessadas determinem o impacto de uma interrupção, bem como o método e a urgência da resposta. À medida que sua equipe compartilha resultados durante a resolução e recuperação de incidentes, eles podem alterar essa configuração. Agora você pode editar a gravidade de um incidente na barra lateral direita da página Detalhes do Incidente, e a gravidade é exibida na lista de incidentes.
и .
Criação, edição e exclusão de regras de segurança de rede de contêineres
(FULTIMADO, OURO)
Este aprimoramento no Container Network Security Rule Editor permite que os usuários criem, editem e excluam facilmente suas regras diretamente da interface do usuário do GitLab. Os recursos do editor incluem .yaml para usuários experientes e um editor de regras com uma interface intuitiva para aqueles que são novos nas regras de rede. Você pode encontrar novas opções de gerenciamento de regras na seção Segurança e conformidade > Gerenciamento de ameaças > Regras (Segurança e conformidade > Gerenciamento de ameaças > Políticas).
и .
Suporte ao armazenamento de blobs do Azure
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUITO, BRONZE, PRATA, OURO)
Tanto o GitLab quanto o GitLab Runner agora suportam , facilitando a execução de serviços GitLab no Azure.
As instâncias do GitLab oferecem suporte ao Azure para todos os tipos de armazenamentos de objetos, incluindo arquivos LFS, artefatos de CI e . Para configurar o armazenamento de Blobs do Azure, siga as instruções de instalação ou .
Os processadores de trabalho do GitLab também oferecem suporte ao Azure para armazenamento . O armazenamento do Azure pode ser configurado usando a seção .
и .
Pacotes Omnibus ARM64 para Ubuntu e OpenSUSE
(CORE, STARTER, PREMIUM, FINAL)
Em resposta à crescente demanda por suporte para execução do GitLab na arquitetura ARM de 64 bits, temos o prazer de anunciar a disponibilidade do pacote oficial ARM64 Ubuntu 20.04 Omnibus. Muito obrigado a Zitai Chen e Guillaume Gardet pelas enormes contribuições que fizeram - seus pedidos de fusão desempenharam um papel fundamental nisso!
Para baixar e instalar o pacote para Ubuntu 20.04, acesse nosso e selecione Ubuntu.
и .
Suporte de autenticação de cartão inteligente para gráfico GitLab Helm
(PRÊMIO, FINAL)
Cartões inteligentes, como Common Access Cards (CAC), agora podem ser usados para autenticação em uma instância do GitLab implantada por meio do gráfico Helm. Os cartões inteligentes são autenticados em um banco de dados local usando certificados X.509. Com isso, o suporte a cartões inteligentes com gráfico Helm agora está alinhado com o suporte a cartões inteligentes disponível em implantações Omnibus.
и .
Notas de lançamento detalhadas e instruções de atualização/instalação podem ser lidas na postagem original em inglês: .
Estávamos trabalhando na tradução do inglês , , и .
Fonte: habr.com