Detecção rápida de vazamento de segredos
Uma pequena falha pode parecer insignificante — acidentalmente enviar credenciais para um repositório público. No entanto, as consequências podem ser graves. Assim que um invasor obtiver sua senha ou chave de API, ele assumirá sua conta, bloqueando você e utilizando seu dinheiro de forma fraudulenta. Além disso, há um efeito dominó: o acesso a uma conta pode abrir portas para outras. As apostas são altas, por isso é extremamente importante detectar vazamentos de segredos o mais rápido possível.
Nesta versão, apresentamos a opção como parte de nossa funcionalidade SAST. Cada commit é escaneado numa tarefa de CI/CD em busca de segredos. Se houver um segredo, o desenvolvedor recebe um aviso na solicitação de mesclagem. Ele revoga imediatamente as credenciais vazadas e cria novas.
Garantindo um gerenciamento de mudanças adequado
À medida que a organização cresce e se torna mais complexa, manter consistência entre as diferentes partes se torna cada vez mais difícil. Quanto mais usuários o aplicativo tiver e maior for a receita, mais sérias serão as consequências de mesclar um código incorreto ou inseguro. Para muitas organizações, garantir um processo de revisão adequado antes da mesclagem do código é uma exigência rigorosa, uma vez que os riscos são muito altos.
No GitLab 11.9, há mais controle e uma estrutura mais eficaz — graças . Anteriormente, para obter aprovação, bastava indicar uma pessoa ou grupo (cada membro poderia conceder a aprovação). Agora, é possível adicionar várias regras, de modo que a solicitação de mesclagem exija aprovação de pessoas específicas ou até mesmo de vários membros de um grupo específico. Além disso, a funcionalidade Code Owners agora está integrada às regras de aprovação, facilitando a identificação da pessoa que concedeu a aprovação.
Isso permite que as organizações implementem processos de aprovação complexos, mantendo ao mesmo tempo a simplicidade do aplicativo GitLab, onde tarefas, código, pipelines e dados de monitoramento são visíveis e acessíveis para tomada de decisões e aceleração do processo de aprovação.
O ChatOps agora é de código aberto
O GitLab ChatOps é uma ferramenta eficaz de automação que permite executar qualquer trabalho de CI/CD e consultar seu status diretamente em aplicativos de chat como Slack e Mattermost. , ChatOps era parte da assinatura GitLab Ultimate. Com base na e , às vezes movemos recursos para baixo e nunca para cima.
No caso do ChatOps, percebemos que essa funcionalidade poderia ser útil para todos, e que a participação da comunidade poderia beneficiar a própria funcionalidade.
No GitLab 11.9, nós , e assim, agora está disponível gratuitamente para uso no GitLab Core auto-hospedado e no GitLab.com, além de estar aberto para a comunidade.
E muito mais!
Este lançamento traz tantas funcionalidades incríveis: por exemplo, , e , — mal podemos esperar para falar sobre eles!
O funcionário mais valioso () deste mês foi reconhecido como Marcel Amirault ()
Marcel constantemente nos ajudou a melhorar a documentação do GitLab. Ele para aumentar a qualidade e a usabilidade dos nossos documentos. Domo arigato [muito obrigado (jap.) — nota do tradutor] Marcel, nós realmente apreciamos isso!
Principais funcionalidades adicionadas no lançamento do GitLab 11.9
Detecção de segredos e credenciais no repositório
(ULTIMATE, GOLD)
Os desenvolvedores às vezes inadvertidamente enviam segredos e credenciais para repositórios remotos. Se outras pessoas tiverem acesso a essa fonte, ou se o projeto for aberto, informações confidenciais podem ser expostas e utilizadas por invasores para acessar recursos, como ambientes de implantação.
O GitLab 11.9 tem um novo teste — “Detecção de Segredos”. Ele escaneia o conteúdo do repositório em busca de chaves de API e outras informações que não deveriam estar aqui. O GitLab exibe os resultados em um relatório SAST no widget de merge request, relatórios de pipelines e nos painéis de segurança.
Se você já conectou o SAST para seu aplicativo, não precisa fazer nada, apenas aproveite os benefícios dessa nova funcionalidade. Ela também está inclusa na configuração padrão.
Regras de resolução de merge requests
Fase do ciclo DevOps: Release
A revisão de código é um elemento essencial de cada projeto bem-sucedido, mas nem sempre está claro quem deve ser responsável pela revisão das mudanças. Muitas vezes, é desejável a participação de revisores de diferentes equipes: a equipe de desenvolvedores, a equipe de interação com os usuários e a equipe de produção.
As regras de aprovação permitem aprimorar o processo de interação entre as partes envolvidas na revisão de código: elas definem o círculo de responsáveis autorizados e o número mínimo de aprovações. As regras de aprovação são exibidas no widget de merge request, permitindo designar rapidamente o próximo revisor.
No GitLab 11.8, as regras de aprovação estavam desativadas por padrão. A partir da versão GitLab 11.9, elas estão disponíveis por padrão. No GitLab 11.3, introduzimos a opção para designar os membros da equipe responsáveis por códigos específicos dentro do projeto. A função Code Owners está integrada às regras de aprovação, tornando sempre fácil encontrar as pessoas necessárias para revisar as mudanças.
Movendo o ChatOps para o Core
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Originalmente introduzido no GitLab Ultimate 10.6, o ChatOps foi transferido para o GitLab Core. O GitLab ChatOps oferece a possibilidade de executar jobs do GitLab CI através do Slack usando o recurso de .
Estamos abrindo o código-fonte deste recurso de acordo com nosso . Usando-o mais, a comunidade poderá contribuir mais.
Auditoria de configurações de funções
Fase do ciclo DevOps: Release
Operações como adicionar, remover ou alterar as configurações de funcionalidades agora são registradas no log de auditoria do GitLab, permitindo que você veja o que e quando foi alterado. Aconteceu um incidente e você precisa verificar o que foi modificado recentemente? Ou você apenas precisa verificar, no âmbito da auditoria, como as configurações das funcionalidades foram alteradas? Agora isso é muito fácil.
Correção de vulnerabilidades em merge requests
(ULTIMATE, GOLD)
Para corrigir rapidamente vulnerabilidades no código, o processo deve ser simples. É importante simplificar a correção de segurança, permitindo que os desenvolvedores se concentrem em suas obrigações diretas. No GitLab 11.7, nós , mas ele precisava ser baixado, aplicado localmente e, em seguida, as mudanças teriam que ser transferidas para o repositório remoto.
No GitLab 11.9, esse processo foi automatizado. Corrija vulnerabilidades sem sair da interface da web do GitLab. O merge request é criado diretamente na janela de informações sobre vulnerabilidades, e essa nova ramificação já conterá a correção. Após verificar se o problema foi resolvido, adicione a correção à ramificação principal, se o pipeline estiver em ordem.
Exibição dos resultados da varredura de containers no painel de segurança do grupo
(ULTIMATE, GOLD)
O painel de segurança do grupo permite que os especialistas se concentrem nas questões mais relevantes para o trabalho, fornecendo uma visão clara e detalhada de todas as possíveis vulnerabilidades que podem afetar as aplicações. Por isso, é importante que o painel contenha todas as informações necessárias em um só lugar e permita que os usuários examinem os dados em detalhes antes de corrigir as vulnerabilidades.
No GitLab 11.9, os resultados da varredura de containers foram adicionados ao painel, além dos já existentes resultados de SAST e varredura de dependências. Agora, toda a visão está em um só lugar, independentemente da fonte do problema.
Modelos CI/CD para jobs de segurança
(ULTIMATE, GOLD)
As funcionalidades de segurança do GitLab estão se desenvolvendo muito rapidamente e exigem atualizações constantes para manter a eficiência e a proteção do código. Alterar a definição de jobs é complicado ao gerenciar vários projetos. E entendemos também: ninguém quer correr o risco de usar a versão mais recente do GitLab sem ter certeza de sua plena compatibilidade com a instância atual do GitLab.
É exatamente por essa razão que introduzimos no GitLab 11.7 um novo mecanismo de definição de jobs utilizando .
A partir do GitLab 11.9, ofereceremos modelos integrados para todos os security jobs: por exemplo, sast e dependency_scanning, — compatíveis com a versão correspondente do GitLab.
Inclua-os diretamente em sua configuração, e eles serão atualizados juntamente com o sistema a cada nova atualização do GitLab. As configurações do pipeline permanecerão as mesmas.
A nova forma de definição de security jobs é oficial e não suporta quaisquer outras definições de jobs anteriores ou trechos de código. É recomendável atualizar a definição o mais rápido possível para utilizar a nova palavra-chave
template. O suporte a qualquer outra sintaxe pode ser removido no GitLab 12.0 ou em outras versões futuras.
Outras melhorias no GitLab 11.9
Resposta ao comentário
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
No GitLab, existem discussões sobre tópicos. Até agora, o usuário que escreve o comentário inicial deve decidir desde o início se precisa de uma discussão.
Nós enfraquecemos essa restrição. Pegue qualquer comentário no GitLab (sobre tarefas, merge requests e épicos) e responda a ele, iniciando assim a discussão. Assim, as equipes interagem de forma mais organizada.
Modelos de projetos para .NET, Go, iOS e Pages
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Para facilitar a criação de novos projetos pelos usuários, oferecemos vários novos modelos de projetos:
- Inicial , incluindo um aplicativo básico com CI.
- Modelo pronto para uso, combinando e GitLab CI/CD.
- , pronto para customização inicial no GitLab. Observe que, como para compilar o iOS é necessário um runner dedicado MacOS, será necessário fornecer seu próprio servidor de construção, se desejar usá-lo com GitLab CI/CD.
- estão configurados para trabalhar com Netlify.
Exija aprovação de merge requests dos Code Owners
Fase do ciclo DevOps: Release
Nem sempre é óbvio quem aprova o merge request.
Agora, o GitLab suporta a exigência de aprovação do merge request, dependendo dos arquivos que a solicitação altera, utilizando . Code Owners são designados através de um arquivo chamado CODEOWNERS, o formato é semelhante a gitattributes.
O suporte à designação automática de Code Owners como responsáveis pela aprovação do merge request foi adicionado ainda na .
Movendo arquivos no Web IDE
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Agora, ao renomear um arquivo ou diretório, ele pode ser movido do Web IDE para o repositório em um novo caminho.
Etiquetas em ordem alfabética
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
As etiquetas do GitLab são incrivelmente versáteis, e as equipes constantemente encontram novas aplicações para elas. Portanto, os usuários frequentemente adicionam muitas etiquetas a uma tarefa, merge request ou épico.
No GitLab 11.9, simplificamos um pouco o uso de etiquetas. Nas tarefas, merge requests e épicos, as etiquetas exibidas na barra lateral estão dispostas em ordem alfabética. Isso se aplica à visualização da lista desses objetos.
Comentários rápidos ao filtrar ações por tarefa
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Recentemente, introduzimos uma função que permite aos usuários filtrar o feed de atividades por tarefas, merge requests ou épicos, o que possibilita focar apenas em comentários ou observações do sistema. Essa configuração é mantida para cada usuário no sistema, e pode ocorrer que o usuário não perceba que, ao visualizar uma tarefa vários dias depois, está vendo um feed filtrado. Ele pode achar que não é possível deixar um comentário.
Aprimoramos essa interação. Agora, os usuários podem rapidamente alternar para um modo que permite deixar comentários sem precisar rolar o feed de volta para o topo. Isso se aplica a tarefas, merge requests e épicos.
Alteração da ordem de épicos filhos
(ULTIMATE, GOLD)
Recentemente, lançamos , permitindo o uso de épicos de épicos (além das tarefas filhas dos épicos).
Agora é possível alterar a ordem dos épicos filhos arrastando-os, assim como é feito com as tarefas filhas. As equipes podem usar a ordem para refletir prioridade ou estabelecer a sequência de execução das tarefas.
Mensagens do sistema personalizadas no cabeçalho e rodapé na web e no e-mail
(CORE, STARTER, PREMIUM, ULTIMATE)
Anteriormente, adicionamos um recurso que permite mensagens do cabeçalho e rodapé personalizados aparecerem em cada página do GitLab. Foi bem recebido, e as equipes o utilizam para compartilhar informações importantes: por exemplo, mensagens do sistema relacionadas ao seu instância do GitLab.
Estamos feliz em lançar essa funcionalidade no Core, para que agora mais pessoas possam usá-la. Além disso, permitimos que os usuários optem por exibir as mesmas mensagens em todos os e-mails enviados através do GitLab, para manter a consistência com outro ponto de contato do usuário com o GitLab.
Filtro por tarefas confidenciais
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Tarefas confidenciais são uma ferramenta útil para as equipes, permitindo que discussões fechadas sobre temas delicados ocorram dentro de um projeto aberto. Em particular, elas são ideais para trabalhar em vulnerabilidades de segurança. Até agora, gerenciar tarefas confidenciais não era muito fácil.
No GitLab 11.9, a lista de tarefas do GitLab agora pode ser filtrada por tarefas confidenciais ou não confidenciais. Isso se aplica também à busca de tarefas pela API.
Agradecemos a contribuição de Robert Schilling ()!
Edição de domínio Knative após a implementação
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Especificar um domínio personalizado ao instalar o Knative permite servir diferentes aplicações/funções serverless com um endpoint único.
Agora a integração do Kubernetes no GitLab permite alterar/atualizar o domínio personalizado após o deploy do Knative no cluster Kubernetes.
Verificação do formato do certificado CA do Kubernetes
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Ao adicionar um cluster Kubernetes existente, o GitLab agora verifica se o certificado CA inserido tem um formato PEM válido. Isso elimina possíveis erros na integração do Kubernetes.
Expansão da ferramenta de comparação de merge requests para todo o arquivo
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Ao visualizar as alterações em um merge request, agora é possível expandir a ferramenta de comparação para cada arquivo, mostrando o arquivo completo para maior contexto e deixar comentários em linhas inalteradas.
Executar trabalhos específicos em merge requests apenas ao alterar determinados arquivos
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
No GitLab 11.6, foi adicionada a capacidade de definir para trabalhos em pipelines, permitindo que os usuários executem tarefas específicas apenas ao criar um merge request.
Agora estamos expandindo essa funcionalidade: foi adicionada a lógica de conexão , e os usuários podem executar trabalhos específicos apenas para merge requests e apenas ao alterar determinados arquivos.
Agradecemos a contribuição de Hiroyuki Sato ()!
Monitoramento automático do GitLab com Grafana
(CORE, STARTER, PREMIUM, ULTIMATE)
Grafana agora faz parte do nosso pacote Omnibus, facilitando a compreensão do funcionamento de sua instância.
Configure grafana['enable'] = true em gitlab.rb, e a Grafana estará disponível em: https://your.gitlab.instance/-/grafana. Em breve também pronto para uso.
Visualização de épicos primários na barra lateral de épicos
(ULTIMATE, GOLD)
Recentemente, apresentamos , permitindo o uso de épicos dos épicos.
No GitLab 11.9, simplificamos o mecanismo de visualização dessa relação. Agora é visível não apenas o épico pai do épico especificado, mas toda a árvore de épicos na barra lateral direita. É possível ver se esses épicos estão fechados ou não, e você pode até acessar diretamente a eles.
Link para nova tarefa a partir de tarefa movida e fechada
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
No GitLab, é fácil mover uma tarefa para outro projeto através da barra lateral ou de uma ação rápida. Nos bastidores, a tarefa existente é encerrada e uma nova tarefa é criada no projeto de destino com todos os dados copiados, incluindo notas de sistema e atributos da barra lateral. É um recurso excelente.
Considerando que existe uma nota de sistema sobre a movimentação, os usuários, ao visualizarem uma tarefa encerrada, ficam confusos: não conseguem entender que a tarefa foi encerrada por causa da movimentação.
Nesta versão, indicamos diretamente no ícone na parte superior da página da tarefa encerrada que ela foi movida, e também incluímos um link embutido para a nova tarefa, para que qualquer um que acesse a antiga possa rapidamente ir para a nova.
Integração do YouTrack
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
O GitLab integra-se com muitos sistemas externos de rastreamento de tarefas, facilitando para as equipes usar o GitLab para outras funções enquanto mantém a ferramenta de gerenciamento de tarefas que escolheram.
Nesta versão, adicionamos a capacidade de integração do YouTrack da JetBrains.
Agradecemos a contribuição de Kotau Yauhen ()!
Redimensionamento da árvore de arquivos de merge request
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Agora, ao visualizar as alterações do merge request, é possível redimensionar a árvore de arquivos para exibir nomes de arquivos longos ou economizar espaço em telas pequenas.
Navegação para os últimos painéis de tarefas
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
Os painéis de tarefas são muito úteis, e as equipes criam vários painéis para cada projeto e grupo. Recentemente, adicionamos um painel de busca para filtrar rapidamente todos os painéis que você está interessado.
No GitLab 11.9, também introduzimos a seção Recente no menu suspenso. Assim, você pode rapidamente acessar os painéis com os quais você interagiu recentemente.
Capacidade dos desenvolvedores de criar branches protegidas
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Branches protegidas não permitem mover ou mesclar código não revisado. No entanto, se a ninguém for permitido mover branches protegidas, então ninguém pode criar uma nova branch protegida: por exemplo, uma branch de lançamento.
No GitLab 11.9, os desenvolvedores podem criar branches protegidas a partir de branches já protegidas através do GitLab ou da API. O uso do Git para mover a nova branch protegida ainda é limitado – para não criar acidentalmente novas branches protegidas.
Deduplicação de objetos Git para branches abertas (Beta)
(CORE, STARTER, PREMIUM, ULTIMATE)
O branch permite que qualquer pessoa participe de projetos de código aberto: sem permissão de gravação, apenas copiando o repositório para um novo projeto. Armazenar cópias completas de repositórios Git frequentemente ramificados não é eficiente. Agora, com o Git alternativas os branches compartilham objetos comuns do projeto pai no pool de objetos, a fim de reduzir os requisitos de armazenamento em disco.
Pools de objetos para branches são criados apenas para projetos abertos, se um repositório hash estiver conectado. Pools de objetos são habilitados com o parâmetro da função object_pools.
Filtragem da lista de merge requests por aprovadores designados
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
A revisão de código é uma prática comum para qualquer projeto de sucesso, mas pode ser difícil para o revisor acompanhar os merge requests.
No GitLab 11.9, a lista de merge requests é filtrada pelo aprovador designado. Assim, você pode encontrar merge requests atribuídos a você como revisor.
Agradecemos pela contribuição de Glavin Wiechert ()!
Atalhos para o próximo e o arquivo anterior no merge request
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Ao revisar as alterações em um merge request, você pode mudar rapidamente entre os arquivos usando ]ou j para ir para o próximo arquivo e [ ou k para voltar ao arquivo anterior.
Simplificação .gitlab-ci.yml para projetos serverless
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Criado a partir da funcionalidade GitLab CI, o template serverless gitlab-ci.yml foi significativamente simplificado. Para introduzir novas funcionalidades nas versões futuras, não é necessário modificar este arquivo.
Suporte a nomes de host Ingress
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Durante o deploy do controlador Kubernetes Ingress, algumas plataformas retornam um endereço IP (por exemplo, GKE do Google), enquanto outras retornam um nome DNS (por exemplo, EKS da AWS).
Nossa integração Kubernetes agora suporta ambos os tipos de endpoints para exibição na seção clusters do projeto.
Agradecemos pela contribuição de Aaron Walker ()!
Restrição de acesso ao JupyterHub apenas para participantes do grupo/projeto
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Fazer o deploy do JupyterHub usando a integração do GitLab com Kubernetes é uma excelente maneira de manter e usar o Jupyter Notebook em grandes grupos. Também é útil controlar o acesso a eles ao transferir dados confidenciais ou pessoais.
No GitLab 11.9, o acesso às instâncias do JupyterHub implantadas através do Kubernetes está restrito aos participantes do projeto com nível de acesso "desenvolvedor" (via grupo ou projeto).
Intervalos de tempo personalizáveis para o esquema do painel de segurança
(ULTIMATE, GOLD)
O painel de segurança do grupo inclui um esquema de vulnerabilidades para revisão do status de segurança atual dos projetos do grupo. Isso é muito útil para diretores de segurança para configurar processos e entender o funcionamento da equipe.
No GitLab 11.9, agora é possível selecionar o intervalo de tempo desse esquema de vulnerabilidades. Por padrão, isso é os últimos 90 dias, mas pode-se definir um intervalo de 60 ou 30 dias, dependendo do nível de detalhamento necessário.
Isso não afeta os dados nos contadores ou na lista, apenas nos pontos de dados exibidos no esquema.
Adição de job de build Auto DevOps para tags
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
A etapa de build automática do Auto DevOps cria a build do seu aplicativo usando o Dockerfile do projeto ou o pacote de build do Heroku.
No GitLab 11.9, a imagem Docker obtida embutida no pipeline de tags recebe um nome semelhante aos nomes tradicionais das imagens usando o tag do commit em vez do SHA do commit.
Obrigado pela contribuição de Aaron Walker!
Atualização do Code Climate para a versão 0.83.0
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
GitLab usa para verificar como as alterações afetam o estado do seu código e do projeto.
No GitLab 11.9, atualizamos o motor para a versão mais recente (), para fornecer os benefícios de suporte a uma linguagem adicional e análise estática para a Qualidade do Código do GitLab.
Obrigado pela contribuição do membro da equipe GitLab Core, Takuya Noguchi ()!
Escalonamento e rolagem do painel de métricas
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Ao investigar anomalias de desempenho, muitas vezes é útil dar uma olhada mais de perto em partes específicas de uma determinada métrica.
Com o GitLab 11.9, os usuários poderão escalar períodos de tempo específicos no painel de métricas, rolar todo o intervalo de tempo e também retornar facilmente à visualização do intervalo de tempo original. Isso permite uma exploração fácil e rápida dos eventos necessários.
SAST para TypeScript
(ULTIMATE, GOLD)
— é uma linguagem de programação relativamente nova baseada em .
No GitLab 11.9, a funcionalidade de Teste de Segurança Estático de Aplicações (SAST) analisa e detecta vulnerabilidades no código TypeScript, exibindo-as no widget de merge request, no nível do pipeline e no painel de segurança. A definição do trabalho atual sast não precisa ser alterada e também está automaticamente ativada em .
SAST para projetos Maven multicomponente
(ULTIMATE, GOLD)
Os projetos Maven são frequentemente organizados de maneira a agrupar em um único repositório. Anteriormente, o GitLab não conseguia escanear corretamente esses projetos, e os desenvolvedores e especialistas em segurança não recebiam relatórios sobre vulnerabilidades.
O GitLab 11.9 oferece suporte ampliado à funcionalidade SAST para essa configuração específica de projeto, permitindo testá-los quanto a vulnerabilidades em seu estado original. Graças à flexibilidade dos analisadores, a configuração é definida automaticamente, e você não precisa alterar nada para visualizar os resultados em aplicativos Maven multicomponente. Como de costume, melhorias semelhantes também estão disponíveis no âmbito de .
GitLab Runner 11.9
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Hoje também lançamos o GitLab Runner 11.9! O GitLab Runner é um projeto de código aberto utilizado para executar tarefas CI/CD e enviar os resultados de volta ao GitLab.
Abaixo estão algumas alterações no GitLab Runner 11.9:
- .
- e .
- . Isso também .
- para suportar , que estarão disponíveis no GitLab 11.10.
- .
- .
- Movendo vários scripts — incluindo e — para Go.
- .
- .
- .
A lista completa de mudanças pode ser encontrada no changelog do GitLab Runner: .
Melhorias no esquema do GitLab
(CORE, STARTER, PREMIUM, ULTIMATE)
No gráfico do GitLab, foram feitas as seguintes melhorias:
- Adicionada a suporte ao Google Cloud Memorystore.
- As configurações de Cron job , pois são utilizados por vários serviços.
- O registro foi atualizado para a versão 2.7.1.
- Foi adicionado um novo parâmetro que garante a compatibilidade do registro GitLab com versões do Docker anteriores a 1.10. Para ativá-lo, defina
registry.compatibility.schema1.enabled: true.
Melhoria de desempenho
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Continuamos a melhorar o desempenho do GitLab a cada lançamento para instâncias de GitLab de qualquer tamanho. Aqui estão algumas melhorias no GitLab 11.9:
- .
- .
- .
- .
Melhorias do Omnibus
(CORE, STARTER, PREMIUM, ULTIMATE)
O GitLab 11.9 trouxe as seguintes melhorias no Omnibus:
- O GitLab 11.9 inclui , , cuja última versão inclui MFA para Team Edition, maior desempenho das imagens e muito mais. Esta versão também inclui ; recomenda-se a atualização.
- Foi adicionado um novo parâmetro que garante a compatibilidade do registro GitLab com versões do Docker anteriores a 1.10. Para ativá-lo, defina
registry['compatibility_schema1_enabled'] = true em gitlab.rb. - O registro do GitLab agora exporta métricas do Prometheus e é monitorado automaticamente pelo .
- Suporte adicionado ao Google Cloud Memorystore, que requer .
opensslatualizado para a versão 1.0.2r,nginx— para a versão 1.14.2,python— para a versão 3.4.9,jemalloc— para a versão 5.1.0,docutils— para a versão 0.13.1,gitlab-monitor— para a versão 3.2.0.
Recursos obsoletos
O GitLab Geo fornecerá armazenamento com hash no GitLab 12.0
O GitLab Geo requer para mitigar a concorrência (race condition) em nós secundários. Isso foi observado em .
No GitLab adicionamos esse requisito na documentação do Geo: .
No GitLab sudo gitlab-rake gitlab: geo: check verifica se o armazenamento com hash está ativado e se todos os projetos estão sendo migrados. Veja. . Se você estiver usando o Geo, execute esta verificação e migre o mais rápido possível.
No GitLab aviso permanentemente desativável será exibido na página Área Administrativa › Geo › Nós, se as verificações mencionadas acima não forem permitidas.
No GitLab O Geo usará os requisitos para armazenamento com hash. Veja. .
Data de remoção: 22 de junho de 2019.
Integração Hipchat
Hipchat . Além disso, na versão 11.9 .
Data de remoção: 22 de março de 2019.
Suporte ao CentOS 6 para o GitLab Runner com o executor Docker
O GitLab Runner não suporta o CentOS 6 quando usado com Docker no GitLab 11.9. Isso é resultado da atualização da biblioteca base do Docker, que não suporta mais o CentOS 6. Para mais detalhes, consulte .
Data de remoção: 22 de março de 2019.
Caminhos legados obsoletos do código do GitLab Runner
A partir do GitLab 11.9, o GitLab Runner utiliza de clonagem/chamada do repositório. Atualmente, o GitLab Runner usará o método antigo caso o novo não seja suportado.
No GitLab 11.0, alteramos a configuração do servidor de métricas para o GitLab Runner. metrics_server será removido em favor de listen_address na versão 12.0 do GitLab. Para mais detalhes, consulte . E mais informações em .
Na versão 11.3, o GitLab Runner passou a suportar , o que levou a novas configurações para . No uma tabela de alterações e instruções para migrar para a nova configuração. Para mais detalhes, consulte .
Esses caminhos não estão mais disponíveis no GitLab 12.0. Como usuário, você não precisa modificar nada, apenas certifique-se de que a instância do GitLab está operando com a versão 11.9+ ao atualizar para o GitLab Runner 12.0.
Data de remoção: 22 de junho de 2019.
Parâmetro obsoleto para a funcionalidade de ponto de entrada do GitLab Runner
No 11.4, o GitLab Runner introduziu o parâmetro de funcionalidade para corrigir problemas como e .
No GitLab 12.0, mudaremos para o comportamento correto como se o parâmetro de funcionalidade estivesse desativado. Para mais detalhes, consulte .
Data de remoção: 22 de junho de 2019.
Suporte obsoleto a distribuições Linux que atingiram o EOL para o GitLab Runner
Algumas distribuições Linux nas quais o GitLab Runner pode ser instalado já estão fora de manutenção.
No GitLab 12.0, o GitLab Runner não distribui mais pacotes para essas distribuições Linux. A lista completa das distribuições que não são mais suportadas pode ser encontrada em nosso . Agradecimentos a Javier Ardón () por sua !
Data de remoção: 22 de junho de 2019.
Remoção de comandos antigos do GitLab Runner Helper
Como parte dos esforços para suportar alguns comandos antigos, usados para .
No GitLab 12.0, o GitLab Runner é executado usando novos comandos. Isso se aplica apenas a usuários que substituem . Para mais detalhes, consulte .
Data de remoção: 22 de junho de 2019.
Os desenvolvedores podem excluir tags do Git no GitLab 11.10
Remover ou editar notas de versão para tags do Git em branches não protegidas historicamente foi restrito apenas a .
Como os desenvolvedores podem adicionar tags, bem como alterar e excluir branches não protegidas, eles devem ter a capacidade de remover tags do Git. No GitLab 11.10 em nosso modelo de permissões para melhorar o fluxo de trabalho e ajudar os desenvolvedores a usarem as tags de forma mais eficiente.
Se desejar manter essa restrição para colaboradores e proprietários, use .
Data de remoção: 22 de abril de 2019.
Suporte ao Prometheus 1.x no Omnibus GitLab
A partir do GitLab , a versão embutida do Prometheus 1.0 foi removida do Omnibus GitLab. No entanto, o formato das métricas não é compatível com a versão 1.0. As versões existentes podem ser atualizadas para a 2.0 e, se necessário, migrar dados .
Na versão do GitLab o Prometheus 2.0 será instalado automaticamente, caso não tenha havido atualizações anteriores. Os dados do Prometheus 1.0 serão perdidos, pois não são migrados.
Data de remoção: 22 de junho de 2019.
TLS v1.1
A partir do GitLab para aumentar a segurança. Isso elimina várias vulnerabilidades, incluindo Heartbleed, e torna o GitLab compatível com o padrão PCI DSS 3.1 logo após a instalação.
Para desativar imediatamente o TLS v1.1, defina nginx['ssl_protocols'] = "TLSv1.2" em gitlab.rband e execute gitlab-ctl reconfigure.
Data de remoção: 22 de junho de 2019.
Modelo OpenShift para instalar o GitLab
Oficial — o método recomendado para executar o GitLab no Kubernetes, incluindo .
para instalar o GitLab está obsoleto e não será mais suportado no .
Data de remoção: 22 de junho de 2019.
Definições anteriores de jobs de segurança
Com a introdução de todas as definições anteriores de jobs estão obsoletas e serão removidas no GitLab 12.0 ou posteriores.
Atualize as definições de jobs para usar a nova sintaxe e aproveitar todos os novos recursos de segurança disponíveis no GitLab.
Data de remoção: 22 de junho de 2019.
A seção Informações do Sistema no painel do administrador
O GitLab apresenta informações sobre sua instância do GitLab em admin/system_info, mas essas informações podem ser imprecisas.
Nós do painel do administrador no GitLab 12.0 e recomendamos usar .
Data de remoção: 22 de junho de 2019.
Fonte: habr.com
