O GitLab 11.10 vem com pipelines no painel de controle, pipelines para resultados combinados e sugestões de várias linhas em merge requests.
Informações convenientes sobre a funcionalidade dos pipelines em diferentes projetos
O GitLab continua a aumentar a transparência do ciclo de vida DevOps. Nesta versão, foi adicionado um resumo do status dos pipelines.
Isso é útil, mesmo se você estiver analisando o pipeline de um único projeto, mas especialmente valioso se , — o que geralmente acontece se você estiver usando microsserviços e quiser executar um pipeline para testar e entregar código de diferentes repositórios de projetos. Agora você vê imediatamente a funcionalidade , onde quer que estejam sendo executados.
Execução de pipelines para resultados combinados
Com o tempo, os branches de origem e destino se divergem, e pode haver situações em que individualmente funcionam, mas juntos não. Agora é possível . Assim, você detectará rapidamente erros que só se manifestariam durante a movimentação frequente de alterações entre os branches, o que significa que corrigirá mais rapidamente os erros do pipeline e usará de forma mais eficaz .
Aprimoramento adicional da colaboração
Com o GitLab 11.10, há ainda mais recursos para colaboração conveniente e fluxos de trabalho simplificados. No introduzimos sugestões em merge requests, onde o revisor podia sugerir uma alteração de uma linha em um comentário de merge request, e isso poderia ser commitado imediatamente a partir do thread de comentários. Nossos usuários gostaram disso, e pediram que expandíssemos esse recurso. Agora você pode sugerir , especificando quais linhas remover e quais adicionar.
Obrigado pelo seu feedback e sugestões!
E isso não é tudo…
Nesta versão, há tantos recursos incríveis, como , uma limpeza mais rigorosa , e a possibilidade de . Abaixo estão os detalhes de cada um deles.
O funcionário mais valioso deste mês () — Takuya Noguti
Neste mês, o funcionário mais valioso foi Takuya Noguti (). Takuya : corrigi bugs, finalizei pendências no backend e frontend e melhorei a interface do usuário. Obrigado!
Principais recursos do GitLab 11.10
Pipelines no painel de controle
PREMIUM, ULTIMATE, SILVER, GOLD
No painel de controle do GitLab são exibidas informações sobre projetos em toda a instância do GitLab. Você pode adicionar projetos individuais um por um e escolher qual projeto deseja visualizar.
Nesta versão, adicionamos ao painel de controle informações sobre os status dos pipelines. Agora, os desenvolvedores podem ver a saúde dos pipelines em todos os projetos necessários — em uma única interface.
Pipelines para resultados mesclados
PREMIUM, ULTIMATE, SILVER, GOLD
Normalmente, com o tempo, o branch de origem desvia do branch de destino, a menos que você esteja constantemente movendo alterações entre eles. Como resultado, os pipelines dos branches de origem e de destino ficam "verdes" e não há conflitos de mesclagem, mas ao mesclar ocorre uma falha devido à incompatibilidade das alterações.
Quando um pipeline de merge requests cria automaticamente um novo link que contém o resultado combinado da mesclagem dos branches de origem e destino, nós podemos iniciar um pipeline a partir desse link e garantir que o resultado combinado será funcional.
Se você estiver usando pipelines de merge requests (de qualquer forma) e utilizando runners privados do GitLab na versão 11.8 ou anterior, eles precisam ser atualizados para evitar problemas. . Isso não afeta os usuários de runners públicos do GitLab.
Sugestão de alterações em várias linhas
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Ao colaborar em merge requests, você frequentemente observa problemas e propõe soluções. A partir da versão 11.6 do GitLab, nós suportamos para uma única linha.
Na versão 11.10, nos comentários do diff de merge requests, é possível sugerir alterações para várias linhas, e qualquer usuário com permissões de gravação no branch de origem pode aceitá-las com um único clique. Com esse novo recurso, você pode evitar cópias e colagens, como nas versões anteriores.
Etiquetas em uma área
PREMIUM, ULTIMATE, SILVER, GOLD
Com etiquetas em uma área, as equipes podem aplicar etiquetas mutuamente exclusivas (na mesma área) a uma tarefa, merge request ou épico em cenários com campos personalizados ou estados personalizados do fluxo de trabalho. Elas são configuradas utilizando uma sintaxe especial com dois pontos no cabeçalho da etiqueta.
Suponha que você precise de um campo personalizado em tarefas para rastrear o sistema operacional da plataforma para a qual suas funções estão direcionadas. Cada tarefa deve se referir a uma única plataforma. É possível criar etiquetas platform::iOS, platform::Android, platform::Linux e outros conforme necessário. Se uma dessas etiquetas for aplicada a uma tarefa, outra etiqueta existente que começa com platform::.
Suponha que você tenha etiquetas workflow::development, workflow::review e workflow::deployed, que indicam o estado do fluxo de trabalho em sua equipe. Se uma tarefa já tiver uma etiqueta workflow::development, e o desenvolvedor quiser mover a tarefa para a fase workflow::review, ele simplesmente aplica uma nova etiqueta, e a antiga (workflow::development) é automaticamente removida. Esse comportamento já existe ao mover tarefas entre listas de etiquetas no quadro de tarefas que representa o fluxo de trabalho de sua equipe. Agora, os membros da equipe que não trabalham diretamente com o quadro de tarefas podem alterar o estado do fluxo de trabalho dentro das próprias tarefas.
Uma limpeza mais cuidadosa do registro de contêineres
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
No uso normal do registro de contêineres com pipelines de CI, você envia várias alterações separadas para uma única tag. Devido à implementação da distribuição do Docker, o comportamento padrão é manter todas as alterações no sistema, mas isso acaba ocupando muito espaço. Se você usar a opção -m com registry-garbage-collect, é possível remover rapidamente todas as alterações anteriores e liberar precioso espaço.
Compra de minutos adicionais do CI Runner
BRONZE, SILVER, GOLD
Usuários com planos pagos do GitLab.com (Gold, Silver, Bronze) agora podem comprar minutos adicionais do CI Runner. Antes, era necessário se manter dentro da cota prevista pelo plano. Com essa melhoria, é possível comprar minutos além da cota antecipadamente, evitando interrupções devido à parada dos pipelines.
Atualmente, 1000 minutos custam 8 dólares, e você pode comprar quantos quiser. Os minutos adicionais começarão a ser consumidos quando você esgotar toda a cota mensal, e o saldo dos minutos adicionais será transferido para o próximo mês. Na , queremos adicionar esse recurso também aos planos gratuitos.
Auto DevOps componível
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Com o Auto DevOps, as equipes adotam práticas modernas de DevOps quase sem esforço. A partir do GitLab 11.10, cada job no Auto DevOps é fornecido como um . Os usuários podem usar no GitLab CI para incluir estágios individuais do Auto DevOps e ao mesmo tempo utilizar seu arquivo personalizado gitlab-ci.yml. Assim, é possível incluir apenas os jobs necessários e aproveitar as atualizações no upstream.
Gerenciamento automático de membros de grupo no GitLab.com com SCIM
SILVER, GOLD
Anteriormente, o gerenciamento de associações em grupos no GitLab.com era feito manualmente. Agora, é possível usar SAML SSO e gerenciar a associação com SCIM, permitindo criar, excluir e atualizar usuários no GitLab.com.
Isso é especialmente útil para empresas com muitos usuários e fornecedores de identidade centralizados. Agora você pode ter uma única fonte de verdade, como o Azure Active Directory, e os usuários serão criados e excluídos automaticamente através do fornecedor de identidade, e não manualmente.
Login no GitLab.com através do fornecedor SAML
SILVER, GOLD
Antes, ao usar SAML SSO para grupos, o usuário precisava fazer login com as credenciais do GitLab e do fornecedor de identidade. Agora, é possível entrar diretamente via SSO como um usuário do GitLab vinculado ao grupo configurado.
Os usuários não precisarão fazer login duas vezes, tornando mais conveniente para as empresas usar SAML SSO para o GitLab.com.
Outras melhorias no GitLab 11.10
Diagrama de épicos subordinados
ULTIMATE, GOLD
Na versão anterior, adicionamos épicos subordinados (épicos de épicos) para facilitar o gerenciamento da estrutura de distribuição de tarefas. Os épicos subordinados aparecem na página do épico pai.
Nesta versão, a página do épico pai exibe o diagrama de épicos subordinados, permitindo que as equipes vejam a cronologia dos épicos subordinados e gerenciem as dependências de tempo.
Pop-ups de merge requests
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Nesta versão, apresentamos telas informativas que aparecem ao passar o cursor sobre o link do merge request. Anteriormente, mostrávamos apenas o título do merge request, agora mostramos também o status do merge request, o status do pipeline CI e um URL curto.
Em futuras versões, planejamos adicionar mais informações importantes, como , além de introduzir pop-ups para .
Filtragem de merge requests por branches de destino
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Os processos do Git para lançamento ou entrega de software geralmente envolvem vários branches de longo prazo — para correção de erros em versões anteriores (por exemplo, stable-11-9) ou transição de controle de qualidade para produção (por exemplo, integration), mas não é tão fácil encontrar merge requests para esses branches entre muitos merge requests abertos.
A lista de merge requests para projetos e grupos agora pode ser filtrada pela branch alvo do merge request, facilitando a busca pelo necessário.
Obrigado, Hiroyuki Sato ()!
Envio e merge com pipeline bem-sucedido
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Se utilizarmos o método de desenvolvimento baseado em trunk, devemos evitar branches de longa duração em favor de pequenas branches temporárias com um único proprietário. Pequenas alterações são frequentemente enviadas diretamente para a branch alvo, mas corremos o risco de quebrar a build.
Nesta versão, o GitLab suporta novos parâmetros de envio no Git para abrir automaticamente merge requests, definir a branch alvo e garantir merge com pipeline bem-sucedido a partir da linha de comando durante o envio para a branch.
Integração aprimorada com painéis de monitoramento externos
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
O GitLab pode se conectar a vários servidores Prometheus (no nível de ambiente, projeto e ), mas ter múltiplos pontos finais pode complicar o sistema ou não ser suportado pelos painéis de monitoramento padrão. Nesta versão, as equipes podem utilizar uma única API Prometheus, simplificando significativamente a integração com serviços como o Grafana.
Classificação de páginas Wiki pela data de criação
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
No Wiki do projeto, as equipes podem compartilhar documentação e outras informações importantes junto com o código-fonte e as tarefas. Nesta versão, a lista de páginas do Wiki pode ser classificada pela data de criação e título, facilitando a descoberta de conteúdos recentemente criados.
Monitoramento de recursos solicitados pelo cluster
ULTIMATE, GOLD
O GitLab ajuda a monitorar o cluster Kubernetes para aplicativos em desenvolvimento e em operação. A partir desta versão, monitore os recursos de CPU e memória solicitados pelo cluster para identificar potenciais problemas antes que se tornem críticos.
Visualização de métricas do balanceador de carga no painel do Grafana
CORE, STARTER, PREMIUM, ULTIMATE
É muito importante monitorar a operação da instância do GitLab. Anteriormente, fornecíamos painéis de controle padrão por meio da instância do Grafana integrada. A partir desta versão, incluímos painéis adicionais para monitorar os balanceadores de carga NGINX.
SAST para Elixir
ULTIMATE, GOLD
Continuamos expandindo o suporte a linguagens e aprofundando as verificações de segurança. Nesta versão, incluímos verificações de segurança para projetos em e projetos criados na .
Múltiplas solicitações em um gráfico
PREMIUM, ULTIMATE, SILVER, GOLD
No GitLab, é possível criar gráficos para visualizar as métricas coletadas. Muitas vezes — por exemplo, se você precisar ver o valor máximo ou médio de uma métrica — é desejável apresentar vários valores em um único gráfico. A partir desta versão, você tem essa possibilidade.
Resultados DAST no painel de segurança do grupo
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Adicionamos os resultados de testes dinâmicos de segurança de aplicativos (Dynamic Application Security Testing, DAST) ao painel de segurança do grupo, além de SAST, varredura de contêineres e varredura de dependências.
Adicionando metadados ao relatório de varredura de contêineres
ULTIMATE, GOLD
Nesta versão, o relatório de varredura de contêineres contém mais metadados - adicionamos o componente afetado (recurso Clair) aos metadados existentes: prioridade, identificador (com referência a mitre.org) e nível afetado (por exemplo, debian:8).
Adicionando tipo de relatório de métricas em merge requests
PREMIUM, ULTIMATE, SILVER, GOLD
O GitLab já fornece vários tipos de relatórios que podem ser incluídos diretamente em merge requests: desde relatórios sobre e na fase de revisão até e na fase de proteção.
E embora esses relatórios sejam importantes, informações básicas adequadas para diferentes cenários também são necessárias. No GitLab 11.10, fornecemos relatórios de métricas diretamente no merge request, que espera um simples par chave-valor. Assim, os usuários podem acompanhar as alterações ao longo do tempo, incluindo métricas personalizadas, e alterações nas métricas para um merge request específico. O uso de memória, testes de cargas especializadas e status de operação podem ser convertidos em métricas simples, que podem ser visualizadas diretamente nos merge requests junto com outros relatórios integrados.
Suporte a projetos Maven multimódulo para análise de dependências
ULTIMATE, GOLD
Nesta versão, projetos Maven multimódulo suportam a análise de dependências do GitLab. Anteriormente, se um submódulo tivesse uma dependência de outro submódulo do mesmo nível, ele não conseguia resolver o download do repositório central Maven. Agora, um projeto Maven multimódulo é criado com dois módulos e uma dependência entre os dois módulos. A dependência entre módulos do mesmo nível agora está disponível no repositório local Maven para que a compilation possa prosseguir.
Os usuários podem alterar o caminho de clonagem no CI
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Por padrão, o GitLab Runner clona o projeto em um caminho aninhado exclusivo em $CI_BUILDS_DIR. Mas para alguns projetos, como o Golang, o código precisa ser clonado em um diretório específico para que possa ser compilado.
No GitLab 11.10, introduzimos a variável GIT_CLONE_PATH, que permite especificar o caminho específico onde o GitLab Runner clona o projeto antes da execução da tarefa.
Máscara simples de variáveis protegidas nos logs
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
O GitLab oferece várias maneiras de e das variáveis no GitLab CI/CD. Mas as variáveis ainda podem acidental ou intencionalmente aparecer nos logs de compilação.
O GitLab leva a gestão de riscos e auditorias a sério e continua a adicionar recursos para conformidade. No GitLab 11.10, introduzimos a capacidade de mascarar alguns tipos de variáveis nos logs de rastreamento de jobs, adicionando um nível de proteção contra a exposição acidental do conteúdo dessas variáveis nos logs. Além disso, o GitLab agora muitas variáveis de tokens integradas.
Ativação e desativação do Auto DevOps a nível de grupo
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Com o Auto DevOps no projeto GitLab.com, você pode lidar com fluxos de trabalho DevOps modernos — desde a construção até a entrega — sem complicações.
A partir do GitLab 11.10, você pode ativar e desativar o Auto DevOps para todos os projetos em um único grupo.
Página de licenças simplificada e aprimorada
STARTER, PREMIUM, ULTIMATE
Para tornar mais conveniente e fácil gerenciar as chaves de licença, remodelamos o design da página de licenças no painel do administrador e destacamos os elementos mais importantes.
Atualização do seletor de rótulos para implantações do Kubernetes
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Nos painéis de implantação, são exibidas informações sobre todas as implantações do Kubernetes.
Nesta versão, mudamos a forma como os rótulos são correspondidos com as implantações. Agora estão disponíveis correspondências por app.example.com/app e app.example.com/env ou app. Isso evitará conflitos durante a filtragem e o risco de implantações incorretas relacionadas ao projeto.
Além disso, na versão GitLab 12.0, nós , sendo que a correspondência será possível apenas por app.example.com/app e app.example.com/env.
Criação dinâmica de recursos do Kubernetes
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
A integração do Kubernetes no GitLab permite o uso da função RBAC com uma conta de serviço e um namespace dedicado para cada projeto GitLab. A partir desta versão, para máxima eficiência, esses recursos serão criados apenas quando forem necessários para a implantação.
Durante a implantação do Kubernetes, o GitLab CI criará esses recursos antes da implantação.
Executores em grupos para clusters de nível de grupo
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Clusters de nível de grupo agora suportam a instalação do GitLab Runner. Executores do Kubernetes de nível de grupo são exibidos para projetos filhos como executores de grupo, marcados com rótulos cluster e kubernetes.
Contador de chamadas para funções Knative
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Funções implantadas com , agora mostram o número de chamadas recebidas para cada função. Para isso, é necessário instalar o Prometheus no cluster onde o Knative está instalado.
Controle de parâmetros git clean para jobs do GitLab CI/CD
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Por padrão, o GitLab Runner executa git clean durante o processo de descarregamento de código ao executar um job no GitLab CI/CD. A partir do GitLab 11.10, os usuários podem controlar os parâmetros passados ao comando git clean. Isso é conveniente para equipes com executores dedicados, bem como para equipes que constroem projetos a partir de grandes monorepositórios. Agora elas podem gerenciar o processo de descarregamento antes da execução dos scripts. A nova variável GIT_CLEAN_FLAGS por padrão tem o valor -ffdx e aceita todos os possíveis parâmetros do comando [git clean](https://git-scm.com/docs/git-clean).
Autenticação externa no Core
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Ambientes protegidos podem exigir um recurso de autenticação externo adicional para acessar o projeto. Adicionamos suporte para um nível de controle de acesso adicional em e recebemos muitos pedidos para abrir essa funcionalidade no Core. Estamos felizes em apresentar a autenticação externa e um nível adicional de segurança para instâncias do Core, já que esse recurso é necessário para participantes específicos.
A possibilidade de criar projetos em grupos no Core
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
O papel de Developer pode criar projetos em grupos , e agora isso é possível também no Core. A criação de projetos é uma capacidade-chave para o trabalho produtivo no GitLab, e com a inclusão dessa função no Core, ficou mais fácil para os participantes do projeto se envolverem em algo novo.
GitLab Runner 11.10
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Hoje lançamos o GitLab Runner 11.10! O GitLab Runner é um projeto de código aberto que é usado para executar jobs CI/CD e enviar os resultados de volta ao GitLab.
As mudanças mais interessantes:
- .
- .
- .
- .
- .
A lista completa de mudanças pode ser encontrada no changelog do GitLab Runner: .
Correção do retorno project_id no API de busca de blob no Elasticsearch
STARTER, PREMIUM, ULTIMATE
Corrigimos um erro na API de busca de blob no Elasticsearch, que incorretamente retornava 0 para project_id. Será necessário , para obter valores corretos project_id após a instalação desta versão do GitLab.
Melhorias do Omnibus
CORE, STARTER, PREMIUM, ULTIMATE
Fizemos as seguintes melhorias no Omnibus no GitLab 11.10:
- O GitLab 11.10 inclui , , cuja última versão traz um novo catálogo de integração para migração fácil de dados do Hipchat e muito mais. Esta versão inclui , e recomendamos a atualização.
- Nós , e agora ficou bem simples começar a monitorar a instância do GitLab.
- Adicionamos suporte para remoção de imagens de contêineres antigas do registro Docker.
- Atualizamos os ca-certs para 2019-01-23.
Melhorias de desempenho
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Continuamos melhorando o desempenho do GitLab a cada lançamento para instâncias do GitLab de qualquer tamanho. Algumas melhorias no GitLab 11.10:
- .
- .
- .
- .
- .
- .
- .
- .
Melhorias nos gráficos do GitLab
CORE, STARTER, PREMIUM, ULTIMATE
Fizemos as seguintes melhorias nos gráficos do GitLab:
- .
Recursos obsoletos
O GitLab Geo fornecerá armazenamento com hash no GitLab 12.0
O GitLab Geo requer para mitigar a concorrência nos 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 do Admin › 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.
Suporte ao Ubuntu 14.04
O GitLab 11.10 será a última versão com .
A Canonical anunciou o fim do suporte padrão ao Ubuntu 14.04 a partir de . Recomendamos que os usuários façam a transição para uma versão LTS suportada: Ubuntu 16.04 ou Ubuntu 18.04.
Data de remoção: 22 de maio de 2019
Limitação do número máximo de pipelines criados por um único envio
Anteriormente, o GitLab criava pipelines para HEAD cada branch no envio. Isso é conveniente para desenvolvedores que enviam várias alterações de uma vez (por exemplo, para um branch de recurso e para o branch develop).
mas ao enviar um repositório grande, onde há muitos branches ativos (como para movimentação, espelhamento ou ramificação), não é necessário criar um pipeline para cada branch. A partir do GitLab 11.10, nós criamos em um envio.
Data de remoção: 22 de maio de 2019
Caminhos legados obsoletos do código do GitLab Runner
A partir do GitLab 11.9, o GitLab Runner utiliza clonagem/chamada do repositório. Atualmente, o GitLab Runner usará o método antigo se o novo não for suportado. Para mais detalhes, consulte .
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 .
Na versão 11.3, o GitLab Runner passou a suportar ; isso levou a novas configurações para . No , uma tabela de alterações e instruções sobre como transitar para a nova configuração. Para mais detalhes, veja .
Esses caminhos estarão indisponíveis no GitLab 12.0. Como usuário, você não precisa alterar nada, apenas garantir que a instância do GitLab esteja funcionando 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 !
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 será iniciado com novos comandos. Isso se aplica apenas aos usuários que . Para mais detalhes, consulte .
Data de remoção: 22 de junho de 2019.
Remoção do mecanismo legado git clean do GitLab Runner
No GitLab Runner 11.10, configurar como o Runner executa o comando git clean. Além disso, a nova estratégia de limpeza remove o uso de git reset e coloca o comando git clean após a etapa de download.
Como essa alteração no comportamento pode afetar alguns usuários, preparamos um parâmetro FF_USE_LEGACY_GIT_CLEAN_STRATEGY. Se definido como verdadeiro, ele restaurará a estratégia de limpeza legado. Mais informações sobre o uso de parâmetros de funcionalidades no GitLab Runner podem ser encontradas .
No GitLab Runner 12.0, removeremos o suporte à estratégia de limpeza legado e a capacidade de restaurá-la usando o parâmetro de funcionalidade. Para mais informações, veja .
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.
Registro de alterações
Veja todas essas alterações no registro de alterações:
Instalação
Se você estiver configurando uma nova instalação do GitLab, visite .
Atualizar
Confira a .
Planos de assinatura do GitLab
O GitLab está disponível em duas opções: e .
: localmente ou na plataforma de nuvem preferida.
- Núcleo: para pequenas equipes, projetos pessoais ou uma versão de teste do GitLab por tempo ilimitado.
- Iniciante: para equipes que trabalham em um único escritório em vários projetos e precisam de suporte profissional.
- Premium: para equipes distribuídas que necessitam de recursos avançados, alta disponibilidade e suporte 24/7.
- Ultimate: para empresas que exigem uma estratégia robusta e implementação com segurança aprimorada e conformidade regulatória.
— GitLab.com: hospedado, gerenciado e administrado pelo GitLab por para desenvolvedores individuais e equipes.
- Gratuito: repositórios privados ilimitados e número ilimitado de colaboradores. Projetos privados têm acesso aos recursos do nível Gratuito, enquanto têm acesso aos recursos do nível Ouro.
- Bronze: para equipes que precisam de acesso a recursos avançados de fluxo de trabalho.
- Prata: para equipes que requerem capacidades DevOps mais robustas, conformidade e suporte rápido.
- Ouro: adequado para uma variedade de trabalhos CI/CD. Todos os projetos públicos podem usar os recursos do Gold gratuitamente, independente do plano.
Fonte: habr.com
