A versión 13.4 lanzouse con almacenamento de HashiCorp para variables CI, axente de Kubernetes e centro de seguridade, así como funcións cambiables en Starter
En GitLab, sempre estamos pensando en como podemos axudar aos usuarios a reducir o risco, mellorar a eficiencia e mellorar a velocidade de entrega na túa plataforma favorita. Este mes engadimos moitas funcións novas útiles que amplían as capacidades de seguranza, reducen o número de vulnerabilidades, aumentan a eficiencia, simplifican o traballo con GitLab e axudan ao teu equipo a ofrecer funcións aínda máis rápido. Agardamos que che resulten útiles as funcións principais da versión Outras 53 novidades, engadido nesta versión.
Funcións de seguridade avanzadas
Tentamos engadir varias funcións novas a GitLab DevSecOps todos os meses, e esta versión non é unha excepción. no marco da montaxe e despregamento. Ademais, agora as organizacións que queiran admitir a separación das responsabilidades de implementación de código . Este papel corresponde e permitirache confirmar solicitudes de combinación (na localización rusa de GitLab "solicitudes de combinación") e despregar código en ambientes protexidos, sen proporcionar acceso para cambiar o propio código.
Outra forma de reducir os riscos é utilizar novos . Os equipos de operacións poden implantar clústeres de Kubernetes desde GitLab sen ter que expoñer o seu clúster a toda Internet. Tamén introducimos compatibilidade de control automático de versións para novos ficheiros de estado de Terraform para apoiar o cumprimento e a facilidade de depuración. Finalmente, converteuse no panel de seguridade da instancia con informes de vulnerabilidade e configuración de seguridade.
Traballo máis cómodo e eficiente con GitLab
Melloramos a nosa busca global para incluír , o que che permite navegar facilmente ata os últimos tickets, grupos, proxectos, configuracións e temas de axuda. Estamos encantados de anunciar que as páxinas de GitLab para redirixir páxinas e directorios individuais dentro do sitio, o que permitirá aos usuarios implementar os seus sitios de forma máis eficiente. E para aqueles que queiran recibir información ampliada sobre a implantación, esta versión permite !
Contribucións de código aberto
Nós representamos que engadín . As marcas na cobertura das probas unitarias do código modificado dan aos desenvolvedores unha idea clara da cobertura do código durante a revisión; esta información axuda a acelerar as revisións e reducir o tempo de fusión e implantación de código novo. E nós tamén e planificar .
E isto é só o comezo!
Como sempre, hai moi pouco espazo na visión xeral, pero hai moitas funcións interesantes na versión 13.4. Aquí tes algúns máis:
- .
Se queres saber de antemán o que che espera seguinte solta, bótalle un ollo .
.
este mes -
Fabio contribuíu significativamente в - unha característica que se agardaba durante moito tempo na comunidade de GitLab. Esta é unha contribución verdadeiramente importante con cambios non triviais que requirían unha colaboración constante cos membros do equipo de GitLab e afectaron a moitas áreas do proxecto como UX, front-end e back-end.
Características principais da versión 13.4 de GitLab
Use as chaves de HashiCorp Vault nos traballos de CI
(PREMIUM, ULTIMATE, PRATA, OURO)
Na versión 12.10, GitLab introduciu a posibilidade de recibir e transferir claves a traballos de CI mediante o manejador de traballos de GitLab (GitLab runner). Agora estamos ampliando , engadindo nova sintaxe secrets para arquivar .gitlab-ci.yml. Isto facilitará a configuración e o uso do repositorio de HashiCorp con GitLab.
и .
Presentamos GitLab Kubernetes Agent
(PREMIUM, ULTIMATE)
A integración de GitLab con Kubernetes permitiu durante moito tempo a súa implantación en clústeres de Kubernetes sen necesidade de configurar manualmente. A moitos usuarios gustoulles a facilidade de uso deste paquete, mentres que outros atoparon algunhas dificultades. Para a integración actual, o seu clúster debe ser accesible desde Internet para que GitLab acceda a el. Para moitas organizacións, isto non é posible porque restrinxen o acceso aos clústeres por razóns de seguridade, cumprimento ou normativas. Para sortear estas restricións, os usuarios necesitaban construír as súas ferramentas enriba de GitLab, se non, non poderían usar esta función.
Hoxe presentamos o GitLab Kubernetes Agent, unha nova forma de implementar nos clústeres de Kubernetes. O axente execútase dentro do seu clúster, polo que non é necesario expoñelo a toda Internet. O axente coordina o despregamento solicitando novos cambios a GitLab, en lugar de enviar actualizacións ao clúster. Non importa o método de GitOps que uses, GitLab tenche cuberto.
Teña en conta que esta é a primeira versión do axente. O noso foco actual para GitLab Kubernetes Agent é configurar e xestionar as implementacións mediante código. Algunhas funcións de integración de Kubernetes existentes, como placas de implantación e aplicacións xestionadas por GitLab, aínda non son compatibles. que estas capacidades engadiranse ao axente en futuras versións, así como novas integracións centradas na seguridade e o cumprimento.
и .
Dálles aos usuarios permisos de implementación sen acceso ao código
(PREMIUM, ULTIMATE, PRATA, OURO)
Anteriormente, o sistema de permisos de GitLab dificultaba a división adecuada das responsabilidades dentro do teu equipo entre os responsables do desenvolvemento e os responsables da implantación. Co lanzamento de GitLab 13.4, pode dar permiso para aprobar solicitudes de combinación para a súa implantación, así como para implementar realmente código a persoas que non escriben o código, sen darlles dereitos de acceso de mantedor (na localización rusa de GitLab "mantedor" ).
и .
Centro de Seguridade
(ÚLTIMO, OURO)
Anteriormente, a xestión de vulnerabilidades a nivel de instancia estaba limitada tanto en funcións como en flexibilidade. A interface era unha única páxina que combinaba detalles de vulnerabilidades, gráficos de métricas e configuración. Non hai moito espazo para desenvolver estas funcións ou usar outras de seguranza.
Fixemos cambios fundamentais na forma en que xestionamos a seguridade e a transparencia en GitLab. O panel de seguridade da instancia transformouse nun centro de seguridade completo. O cambio máis importante é a introdución dunha nova estrutura de menú: en lugar dunha páxina, agora ves o panel de seguridade, o informe de vulnerabilidade e a sección de configuración por separado. Aínda que a funcionalidade non cambiou, dividila en partes permitirá melloras nesta sección que doutro xeito serían difíciles. Isto tamén prepara o escenario para engadir outras capacidades relacionadas coa seguridade no futuro.
A sección dedicada Informe de vulnerabilidade agora ten máis espazo para mostrar detalles importantes. Aquí están as vulnerabilidades que están actualmente na lista de vulnerabilidades do proxecto. Mover widgets con métricas de vulnerabilidade a unha sección separada crea un cómodo panel de control de seguranza. Agora é un lenzo para visualizacións futuras, non só para a xestión de vulnerabilidades, senón para calquera métrica relacionada coa seguridade. Finalmente, unha área de configuración separada crea un espazo común para todas as configuracións de seguridade a nivel de instancia, non só para a xestión de vulnerabilidades.
и .
As funcións cambiables agora están en GitLab Starter
(INICIO, PREMIUM, ULTIMATE, BRONCE, PRATA, OURO)
Lanzouse GitLab 11.4 . En 12.2 introducimos estratexias para eles и , e en 13.1 engadiron и para diferentes ambientes.
A principios deste ano, GitLab asumiu un compromiso en código aberto. Nesta versión, completamos a migración das funcións intercambiables ao plan Starter e seguiremos migrándoas a Core desde . Estamos encantados de ofrecer esta función a máis usuarios e queremos saber como a usas.
и .
Navegación rápida desde a barra de busca
(CORE, INICIO, PREMIUM, ULTIMATE, GRATIS, BRONCE, PRATA, OURO)
Ás veces, cando navegas por GitLab queres ir directamente a un proxecto específico en lugar da páxina de resultados da busca.
Usando a barra de busca global, pode navegar rapidamente ata os últimos tickets, grupos, proxectos, configuracións e temas de axuda. Incluso pode usar unha tecla de acceso rápido /para mover o cursor á barra de busca para navegar por GitLab de forma aínda máis eficiente.
и .
Mostrando a cobertura do código nas diferenzas das solicitudes de combinación
(CORE, INICIO, PREMIUM, ULTIMATE, GRATIS, BRONCE, PRATA, OURO)
Ao revisar unha solicitude de combinación, pode ser difícil determinar se o código modificado está cuberto por probas unitarias. Pola contra, os revisores poden confiar na cobertura global e solicitar que se incremente antes de aprobar unha solicitude de fusión. Isto pode levar a un enfoque casual para escribir probas, que en realidade non mellorará a calidade do código nin a cobertura das probas.
Agora, ao ver unha diferenza de solicitude de combinación, verá unha visualización visual da cobertura do código. As novas marcas permitiranche comprender rapidamente se o código modificado está cuberto por unha proba unitaria, o que axudará a acelerar a revisión do código e o tempo de fusión e implantación de código novo.
Grazas e Siemens para esta función!
и .
Máis ambientes e proxectos no panel Ambientes
(PREMIUM, ULTIMATE, PRATA, OURO)
Desde o lanzamento de GitLab 12.5 usando podería supervisar o estado dos ambientes, pero non máis de sete ambientes en tres proxectos. Melloramos este panel na versión 13.4 paxinandoo para axudarche a manter e xestionar os teus ambientes a escala. Agora podes ver máis ambientes en máis proxectos.
и .
GitLab toma o control do provedor de GitLab Terraform
(CORE, INICIO, PREMIUM, ULTIMATE, GRATIS, BRONCE, PRATA, OURO)
Recentemente nós e planificar . Durante o último mes, aceptamos 21 solicitudes de combinación e pechamos 31 tickets, incluídos algúns erros de longa data e funcións que faltan, como ... Podes na documentación de Terraform.
и .
Probas de API fuzzing con especificacións OpenAPI ou ficheiro HAR
(ÚLTIMO, OURO)
As probas de fuzzing de API son unha boa forma de atopar erros e vulnerabilidades nas túas aplicacións web e API que outros escáneres e métodos de proba poden perder.
As probas de fuzzing da API en GitLab permítenche proporcionar ou a súa aplicación e despois xera automaticamente datos de entrada aleatorios deseñados para probar casos extremos e atopar erros. Os resultados son visibles inmediatamente dentro da túa canalización.
Esta é a nosa primeira versión de proba de fuzz de API e gustaríanos saber o que pensas. Temos máis en stock para probas de fuzz , que basearemos no lanzamento desta función.
и .
Previsualiza os novos gráficos no panel de métricas
(CORE, INICIO, PREMIUM, ULTIMATE, GRATIS, BRONCE, PRATA, OURO)
Anteriormente, crear un gráfico no panel de métricas en GitLab non era unha tarefa sinxela. Despois de crear a métrica no ficheiro YAML do panel de control, fixeches cambios en master, sen poder verificar que o gráfico recén creado funciona exactamente como precisa. A partir desta versión, podes previsualizar os cambios mentres creas o gráfico, tendo unha idea do resultado antes de enviar os cambios ao ficheiro YAML do panel.
и .
Datos sobre a cobertura de código por probas para todos os proxectos do grupo
(PREMIUM, ULTIMATE, PRATA, OURO)
Cando xestionas un gran número de proxectos en GitLab, necesitas unha única fonte de información sobre como cambia a cobertura do código co paso do tempo en todos os proxectos. Antes, mostrar esta información requiría un traballo manual tedioso e lento: había que descargar os datos de cobertura de código de cada proxecto e combinalos nunha táboa.
Na versión 13.4, fíxose posible montar facilmente e rapidamente .csv arquivo con todos os datos sobre a cobertura do código para todos os proxectos do grupo ou para unha selección de proxectos. Esta característica é MVC, seguirá a capacidade .
и .
Soporte para novos idiomas para probas completas de fuzz
(ÚLTIMO, OURO)
Esta versión presenta soporte para varios idiomas novos para probas fuzz destinadas a unha cobertura total.
Agora podes avaliar as capacidades completas das probas fuzzing nas túas aplicacións Java, Rust e Swift e atopar erros e vulnerabilidades que outros escáneres e métodos de proba poden perder.
и .
Alertas na páxina principal do contorno
(PREMIUM, ULTIMATE, PRATA, OURO)
A páxina Entornos mostra o estado xeral dos seus ambientes. Nesta versión melloramos esta páxina engadindo a visualización de alertas. As alertas activadas xunto co estado dos teus ambientes axudaranche a tomar medidas rapidamente para corrixir as situacións que xurdan.
и .
As canalizacións aniñadas agora poden executar as súas propias canalizacións aniñadas
(CORE, INICIO, PREMIUM, ULTIMATE, GRATIS, BRONCE, PRATA, OURO)
Usando canalizacións aniñadas, agora é posible executar novas canalizacións dentro de canalizacións fillas. O nivel extra de profundidade pode ser útil se necesitas flexibilidade para xerar un número variable de canalizacións.
Anteriormente, cando se usaban canalizacións aniñadas, cada canalización filla requiría que se definise manualmente un traballo de activación na canalización principal. Agora podes crear canalizacións aniñadas que lanzarán dinámicamente calquera número de canalizacións aniñadas novas. Por exemplo, se tes un monorepositorio, podes xerar dinámicamente o primeiro subtubo, que creará o número necesario de novas canalizacións en función dos cambios na rama.
и .
Navegación mellorada entre canalizacións principais e aniñadas
(CORE, INICIO, PREMIUM, ULTIMATE, GRATIS, BRONCE, PRATA, OURO)
Anteriormente, navegar entre as canalizacións principais e aniñadas non era moi cómodo: necesitaba moitos clics para chegar á canalización desexada. Tampouco foi doado descubrir que traballo comezou o gasoduto. Agora será moito máis doado ver as conexións entre as canalizacións principais e aniñadas.
и .
Os traballos de matriz paralela mostran variables relevantes no título do posto
(CORE, INICIO, PREMIUM, ULTIMATE, GRATIS, BRONCE, PRATA, OURO)
Se usaches , quizais teña notado que era difícil determinar que variable matricial se utilizaba para un traballo en particular, xa que os nomes dos traballos parecían matrix 1/4. Na versión 13.4, verá os valores das variables relevantes que se usaron nese traballo en lugar do nome xenérico do traballo. Por exemplo, se o teu obxectivo é depurar a arquitectura x86, chamaríase ao traballo matrix: debug x86.
и .
Outras melloras en GitLab 13.4
Conectando unha conta de Atlassian
(CORE, STARTER, PREMIUM, ULTIMATE)
Os usuarios de GitLab agora poderán conectar as súas contas de GitLab á súa conta de Atlassian Cloud. Isto permitirache iniciar sesión en GitLab coas túas credenciais de Atlassian e tamén sentará as bases para futuras melloras de integración. e con outros produtos da liña Atlassian.
и .
Exportando unha lista de todos os compromisos de combinación
(ÚLTIMO, OURO)
As organizacións centradas no cumprimento necesitan unha forma de mostrar aos auditores unha visión holística dos compoñentes asociados a calquera cambio da produción. En GitLab, isto significa recoller todo nun só lugar: solicitudes de combinación, tickets, canalizacións, análises de seguranza e outros datos de confirmación. Ata agora, tiñas que recollelo manualmente en GitLab ou configurar as túas ferramentas para recoller a información, o que non era moi eficiente.
Agora podes recoller e exportar estes datos mediante programación para cumprir os requisitos de auditoría ou realizar outras análises. Para exportar unha lista de todos os compromisos de combinación para o grupo actual, cómpre ir a e fai clic no botón Lista de todos os compromisos de combinación. O ficheiro resultante conterá todos os commits da solicitude de fusión, o seu autor, ID da solicitude de fusión asociada, grupo, proxecto, confirmadores e outra información.
и .
Lista e xestiona tokens de acceso persoal a través da API
(ÚLTIMO, OURO)
Xestionar o acceso ao espazo de nomes de GitLab é unha parte importante dos esforzos de cumprimento. Desde os principios do mínimo privilexio ata a desactivación do acceso temporizado, pode haber varios requisitos asociados aos tokens de acceso persoal en GitLab. Para facilitar o mantemento e a xestión de todas estas credenciais de usuario no teu espazo de nomes, ofrecemos a posibilidade de enumerar todos os tokens de acceso persoais e, opcionalmente, mediante API.
Estas melloras na API de GitLab permiten aos usuarios enumerar e revogar os seus propios tokens de acceso persoais, e aos administradores listar e revogar os tokens dos seus usuarios. Agora será máis fácil para os administradores ver quen ten acceso ao seu espazo de nomes, tomar decisións de acceso en función dos datos dos usuarios e revogar os tokens de acceso persoais que puidesen estar comprometidos ou que quedan fóra das políticas de xestión de acceso da empresa.
и .
Os problemas relacionados e outras funcións están agora en GitLab Core
(CORE, INICIO, PREMIUM, ULTIMATE, GRATIS, BRONCE, PRATA, OURO)
Hai uns meses anunciamos un plan para . Traballando para cumprir esta promesa, fixemos , и (na localización rusa de GitLab "taboleiro de discusión") dispoñible no plan Core. Isto só se aplica ás relacións "vinculadas a"; as relacións "bloqueadas" e "bloqueadas" permanecen nos plans de pago.
и .
Mostrando o nome da rama de orixe na barra lateral da solicitude de combinación
(CORE, INICIO, PREMIUM, ULTIMATE, GRATIS, BRONCE, PRATA, OURO)
Cando se revisan os cambios de código, as discusións e as solicitudes de combinación, adoita ser desexable facer unha verificación local da rama para unha revisión máis profunda. Non obstante, atopar o nome do fío faise cada vez máis difícil a medida que se engade máis contido á descrición da solicitude de combinación e tes que desprazarte máis abaixo na páxina.
Engadimos o nome da rama á barra lateral da solicitude de combinación, facéndoa accesible en calquera momento e eliminando a necesidade de desprazarse por toda a páxina. Do mesmo xeito que a ligazón á solicitude de combinación, a sección da rama de orixe contén un cómodo botón "copiar".
Grazas pola túa enorme contribución ao desenvolvemento desta función!
и .
Indicación da presenza de ficheiros contraídos nas diferenzas de solicitude de combinación
(CORE, INICIO, PREMIUM, ULTIMATE, GRATIS, BRONCE, PRATA, OURO)
As solicitudes de combinación que engaden cambios a varios ficheiros ás veces contraen as diferenzas de ficheiros grandes para mellorar o rendemento da renderización. Cando isto ocorre, é posible omitir accidentalmente un ficheiro durante a revisión, especialmente nas solicitudes de combinación cunha gran cantidade de ficheiros. A partir da versión 13.4, as solicitudes de combinación marcarán as diferenzas que conteñan ficheiros dobrados, polo que non perderás estes ficheiros durante a revisión do código. Para unha maior claridade, pensamos engadir elementos destacados a estes ficheiros nunha versión futura. Estade atentos ás novidades .
и .
Aviso sobre a presenza de ficheiros contraídos na diferenza dunha solicitude de combinación
(CORE, INICIO, PREMIUM, ULTIMATE, GRATIS, BRONCE, PRATA, OURO)
Na sección de diferenzas de solicitudes de combinación, os ficheiros grandes están contraídos para mellorar o rendemento. Non obstante, ao revisar o código, algúns ficheiros poden perderse cando o revisor se despraza pola lista de ficheiros, xa que todos os ficheiros grandes están contraídos.
Engadimos un aviso visible na parte superior da páxina de diferenzas de solicitude de combinación para informar aos usuarios de que nesta sección hai un ficheiro combinado. Deste xeito, non perderás ningún cambio na solicitude de combinación durante a revisión.
и .
Recuperación automática do repositorio do clúster de Gitaly
(CORE, INICIO, PREMIUM, ULTIMATE, GRATIS, BRONCE, PRATA, OURO)
Anteriormente, cando o nodo principal dun clúster de Gitaly estaba fóra de liña, os repositorios nese nodo estaban marcados como de só lectura. Isto evitou a perda de datos en situacións nas que había cambios no nodo que aínda non foran replicados. Cando o nodo volveu estar en liña, GitLab non se restaurou automaticamente e os administradores tiveron que iniciar manualmente o proceso de sincronización ou aceptar a perda de datos. Outras situacións, como a falla dun traballo de replicación nun nodo secundario, tamén poden producir repositorios obsoletos ou de só lectura. Neste caso, o repositorio permaneceu obsoleto ata que se produciu a seguinte operación de escritura, que iniciaría o traballo de replicación.
Para resolver este problema agora programa un traballo de replicación cando detecta un repositorio desactualizado nun nodo e a última versión do repositorio noutro. Este traballo de replicación mantén o repositorio actualizado automaticamente, eliminando a necesidade de restaurar os datos manualmente. A recuperación automática tamén garante que os nodos secundarios se actualicen rapidamente se un traballo de replicación falla, en lugar de esperar á seguinte operación de escritura. Dado que moitos clústeres de Gilaly almacenan un gran número de repositorios, isto reduce significativamente o tempo que os administradores e os enxeñeiros de fiabilidade dedican a recuperar datos despois dun erro.
Ademais, a reparación automática inicia a replicación dos repositorios en calquera novo nodo de Gitaly engadido ao clúster, eliminando o traballo manual ao engadir novos nodos.
и .
Marque unha tarefa pendente como completada na páxina de deseño
(CORE, INICIO, PREMIUM, ULTIMATE, GRATIS, BRONCE, PRATA, OURO)
A comunicación eficaz en GitLab baséase en listas de tarefas. Se se che menciona nun comentario, é fundamental poder ir a unha tarefa e comezar a facer algo ou marcala como completada. Tamén é importante poder asignarche unha tarefa cando necesites traballar en algo ou volver a el máis tarde.
Anteriormente, non podías engadir tarefas nin marcalas como completadas cando traballabas con deseños. Isto interrompeu seriamente a eficiencia da comunicación entre os equipos de produtos, xa que as tarefas pendentes son un elemento crítico do fluxo de traballo de GitLab.
Na versión 13.4, os deseños están ao día cos comentarios dos tickets ao usar tarefas, o que fai que traballar con elas sexa máis consistente e eficiente.
и .
Guía de solución de problemas mellorada para CI/CD
(CORE, INICIO, PREMIUM, ULTIMATE, GRATIS, BRONCE, PRATA, OURO)
Melloramos a guía de solución de problemas para GitLab CI/CD con máis información sobre os problemas comúns que podes atopar. Agardamos que a documentación mellorada sexa un recurso valioso para axudarche a poñer en marcha GitLab CI/CD de xeito rápido e sinxelo.
и .
As solicitudes de combinación xa non saen da cola de combinación
(PREMIUM, ULTIMATE, PRATA, OURO)
Anteriormente, as solicitudes de combinación podían saír da cola de combinación por accidente debido a comentarios tardíos. Se xa se atopaba unha solicitude de combinación na cola e alguén lle engade un comentario que crease unha nova discusión sen resolver, a solicitude de combinación non se consideraría apta para unha combinación e quedaría fóra da cola. Agora, despois de engadir unha solicitude de fusión á cola de fusión, pódense engadir novos comentarios sen medo a interromper o proceso de fusión.
и .
Mostrando o valor de cobertura do código para un traballo nunha solicitude de combinación
(CORE, INICIO, PREMIUM, ULTIMATE, GRATIS, BRONCE, PRATA, OURO)
Os desenvolvedores deberían poder ver o valor de cobertura do código despois de que se complete a canalización, mesmo en escenarios complexos, como a execución dunha canalización con varios traballos que deben ser analizados para calcular o valor de cobertura. Anteriormente, o widget de solicitude de combinación só mostraba a media destes valores, o que significaba que tiñas que navegar ata a páxina do traballo e volver á solicitude de combinación para obter valores de cobertura intermedios. Para aforrarche tempo e estes pasos adicionais, fixemos que o widget mostrase o valor medio de cobertura, os seus cambios entre as ramas de destino e de orixe e unha información sobre ferramentas que mostra o valor de cobertura para cada traballo en función do cal se calculou a media.
и .
Eliminando paquetes do rexistro de paquetes ao ver un grupo
(CORE, INICIO, PREMIUM, ULTIMATE, GRATIS, BRONCE, PRATA, OURO)
O rexistro de paquetes de GitLab é un lugar para almacenar e distribuír paquetes en diferentes formatos. Cando tes moitos paquetes no teu proxecto ou grupo, cómpre identificar rapidamente os paquetes non utilizados e eliminalos para evitar que a xente os descargue. Pode eliminar paquetes do seu rexistro mediante ou a través da interface de usuario do rexistro de paquetes. Non obstante, ata agora non podías eliminar paquetes ao ver un grupo a través da IU. Como resultado, tivo que eliminar paquetes innecesarios por proxecto, o que era ineficiente.
Agora podes eliminar paquetes ao ver o rexistro de paquetes dun grupo. Simplemente vai á páxina de rexistro de paquetes do grupo, filtra os paquetes polo nome e elimina os que non necesites.
и .
Escalar paquetes de Conan a nivel de proxecto
(CORE, INICIO, PREMIUM, ULTIMATE, GRATIS, BRONCE, PRATA, OURO)
Podes usar o repositorio de Conan en GitLab para publicar e distribuír dependencias de C/C++. Non obstante, anteriormente os paquetes só podían escalar ao nivel de instancia, xa que o nome do paquete Conan só podía ter un máximo de 51 caracteres. Se queres publicar un paquete dun subgrupo, por exemplo gitlab-org/ci-cd/package-stage/feature-testing/conan, era case imposible de facer.
Agora podes escalar os paquetes de Conan ata o nivel do proxecto, facilitando a publicación e a distribución das dependencias dos teus proxectos.
и .
Soporte para novos xestores de paquetes e idiomas para a exploración de dependencias
(ÚLTIMO, OURO)
Estamos encantados de engadir análises de dependencia para proxectos de código C, C++, C# e .Net que usan xestores de paquetes NuGet 4.9+ ou Conan á nosa lista . Agora podes activar a exploración de dependencias como parte da fase segura para comprobar se hai vulnerabilidades coñecidas nas dependencias engadidas a través dos xestores de paquetes. As vulnerabilidades atopadas mostraranse na túa solicitude de fusión xunto co seu nivel de gravidade, para que saibas antes de executar a fusión cales son os riscos que comporta a nova dependencia. Tamén pode configurar o seu proxecto para requirir para dependencias con vulnerabilidades con niveis de gravidade crítico (crítico), alto (alto) ou descoñecido (descoñecido).
и .
Notificacións ao cambiar a configuración da solicitude de combinación a "Combinar cando a canalización se complete correctamente"
(CORE, INICIO, PREMIUM, ULTIMATE, GRATIS, BRONCE, PRATA, OURO)
Anteriormente, ao establecer a configuración da solicitude de combinación Combina cando remate a canalización (Merge When Pipeline Succeeds, MWPS) non se enviou ningunha notificación por correo electrónico. Tiveches que comprobar manualmente o estado ou esperar unha notificación de combinación. Con esta versión temos o pracer de presentar as contribucións dos usuarios , que resolveu este problema engadindo notificacións automáticas a todos os subscritos a unha solicitude de combinación cando un revisor cambia a configuración de combinación a MWPS.
и .
Creación de clústeres EKS cunha versión de Kubernetes especificada polo usuario
(CORE, INICIO, PREMIUM, ULTIMATE, GRATIS, BRONCE, PRATA, OURO)
Os usuarios de GitLab agora poden escoller a versión de Kubernetes que proporcionará EKS; pode escoller entre as versións 1.14–1.17.
и .
Creación de incidencias como tipos de ticket
(CORE, INICIO, PREMIUM, ULTIMATE, GRATIS, BRONCE, PRATA, OURO)
Non todos os problemas que xurden activan alertas de inmediato: os usuarios informan de interrupcións e os membros do equipo investigan problemas de rendemento. Agora os incidentes son un tipo de ticket, polo que os teus equipos poden crealos rapidamente como parte do seu fluxo de traballo normal. Fai clic Nova tarefa desde calquera lugar de GitLab e no campo Tipo seleccionar Incidente.
и .
Mencionando alertas de GitLab en Markdown
(CORE, INICIO, PREMIUM, ULTIMATE, GRATIS, BRONCE, PRATA, OURO)
Melloramos as alertas de GitLab engadindo un novo tipo de mención específicamente para elas en GitLab Markdown, facilitando compartir e mencionar alertas. Use ^alert#1234para mencionar a alerta en calquera campo Markdown: en incidencias, tickets ou solicitudes de combinación. Isto tamén axudarache a identificar traballos que se crean a partir de alertas en lugar de tickets ou solicitudes de combinación.
и .
Visualización da carga de alerta por incidencia
(CORE, INICIO, PREMIUM, ULTIMATE, GRATIS, BRONCE, PRATA, OURO)
A descrición da alerta contén información fundamental para a resolución de problemas e a recuperación, e esta información debería ser facilmente accesible para que non teñas que cambiar de ferramenta ou pestana mentres traballas para resolver un incidente. Os incidentes creados a partir de alertas mostran a descrición completa da alerta na pestana Detalles da alerta.
Busca avanzada un 75% máis rápida
(INICIO, PREMIUM, ULTIMATE, BRONCE, PRATA, OURO)
GitLab, como unha única aplicación, ten a capacidade única de facer descubrimento de contido en todo o teu fluxo de traballo DevOps rapidamente. En GitLab 13.4, a busca avanzada devolve resultados un 75 % máis rápido , como en GitLab.com.
и .
Visualización de proxectos eliminados para administradores
(CORE, STARTER, PREMIUM, ULTIMATE)
Houbo unha opción para aprazar a eliminación do proxecto . Non obstante, anteriormente non era posible ver todos os proxectos en espera de eliminación nun só lugar. Os administradores de instancias de usuarios de GitLab agora poden ver todos os proxectos de eliminación pendentes nun só lugar, xunto con botóns para restaurar facilmente eses proxectos.
Esta función ofrece aos administradores un maior control sobre a eliminación do proxecto ao recoller toda a información relevante nun só lugar e ofrecer a posibilidade de desfacer accións de eliminación non desexadas.
Grazas para esta función!
и .
Engadiuse compatibilidade con regras push de grupo á API
(INICIO, PREMIUM, ULTIMATE, BRONCE, PRATA, OURO)
Anteriormente, as regras de inserción de grupos só se podían configurar visitando cada grupo individualmente a través da IU de GitLab e aplicando esas regras. Agora podes xestionar estas regras mediante unha API para admitir as túas ferramentas personalizadas e a automatización de GitLab.
и .
Revogando tokens de acceso persoal para o almacenamento de credenciais autoxestionados
(ÚLTIMO)
Ofrece aos administradores a información que necesitan para xestionar as credenciais dos usuarios para a súa instancia de GitLab. Dado que as organizacións centradas no cumprimento varían no rigor das súas políticas de xestión de credenciais, engadimos un botón que permite aos administradores revogar opcionalmente o token de acceso persoal (PAT) dun usuario. Agora os administradores poden revogar facilmente as PAT potencialmente comprometidas. Esta función é útil para as organizacións que queren opcións de cumprimento máis flexibles para minimizar a interrupción dos seus usuarios.
и .
Ficheiro de configuración para o editor de sitios estáticos
(CORE, INICIO, PREMIUM, ULTIMATE, GRATIS, BRONCE, PRATA, OURO)
En GitLab 13.4, presentamos unha nova forma de personalizar o editor de sitios estáticos. Aínda que o ficheiro de configuración non garda nin recibe ningunha configuración nesta versión, estamos sentando as bases para a personalización futura do comportamento do editor. En próximas versións engadirémolo ao ficheiro .gitlab/static-site-editor.yml parámetros para a instalación , sobre o que , anulando a configuración de sintaxe de Markdown e outras configuracións do editor.
и .
Edición da parte introdutoria dun ficheiro mediante un editor de sitio estático
(CORE, INICIO, PREMIUM, ULTIMATE, GRATIS, BRONCE, PRATA, OURO)
Front matter é un xeito flexible e cómodo de definir variables de páxina en ficheiros de datos para procesar o xerador de sitios estáticos. Normalmente úsase para definir o título da páxina, o modelo de deseño ou o autor, pero pódese usar para pasar calquera tipo de metadatos ao xerador ao renderizar a páxina en HTML. Incluída na parte superior de cada ficheiro de datos, a parte introdutoria adoita ter un formato YAML ou JSON e require unha sintaxe consistente e precisa. Os usuarios que non estean familiarizados con regras de sintaxe específicas poden introducir marcas non válidas sen querer, o que á súa vez pode causar problemas de formato ou mesmo erros na compilación.
O modo de edición WYSIWYG do editor de sitios estáticos xa elimina a introdución do editor para evitar estes erros de formato. Non obstante, isto impide que cambie os valores almacenados nesta parte sen volver á edición no modo fonte. En GitLab 13.4, pode acceder a calquera campo e editar o seu valor nunha interface familiar baseada en formularios. Cando se preme o botón Configuración (Configuración) abrirase un panel que mostra un campo de formulario para cada clave definida ao principio. Os campos enchense co valor actual, e editar calquera deles é tan sinxelo como introducilo no formulario web. Editar a introdución deste xeito evita unha sintaxe complexa e dáche un control total sobre o contido ao tempo que garante que o resultado final teña un formato coherente.
и .
GitLab para Jira e DVCS Connector agora está no Core
(CORE, INICIO, PREMIUM, ULTIMATE, GRATIS, BRONCE, PRATA, OURO)
Para usuarios de Jira en GitLab: и permítenche mostrar información sobre as confirmacións de GitLab e as solicitudes de combinación directamente en Jira. Combinado coa nosa integración integrada de Jira, podes moverte facilmente entre as dúas aplicacións mentres traballas.
Estas funcións antes só estaban dispoñibles no noso plan Premium, pero agora están dispoñibles para todos os usuarios.
и .
Votación maioritaria para as transaccións do clúster de Gitaly (beta)
(CORE, STARTER, PREMIUM, ULTIMATE)
Un clúster de Gitaly permítelle replicar repositorios Git en varios nodos de Gitaly "cálidos". Isto aumenta a tolerancia a fallos eliminando puntos únicos de falla. , introducido en GitLab 13.3, fai que os cambios se transmitan a todos os nodos de Gitaly do clúster, pero só os nodos de Gitaly que votan de acordo co nodo principal gardan os cambios no disco. Se todos os nodos de réplica non están de acordo, só se almacenará unha copia do cambio no disco, creando un único punto de fallo ata que se complete a replicación asíncrona.
A votación maioritaria mellora a tolerancia ás fallas ao esixir o consentimento da maioría dos nodos (non de todos) antes de gardar os cambios no disco. Se esta función de alternancia está activada, a escritura debería ter éxito en varios nodos. Os nós disidentes sincronízanse automaticamente mediante a replicación asíncrona dos nós que formaron quórum.
и .
Compatibilidade con esquemas personalizados para validación JSON en Web IDE
(PREMIUM, ULTIMATE, PRATA, OURO)
Os proxectos nos que a xente escribe configuracións en JSON ou YAML adoitan ter problemas porque é fácil cometer erros tipográficos e romper algo. É posible escribir ferramentas de inspección para detectar estes problemas na canalización de CI, pero usar un ficheiro de esquema JSON pode ser útil para proporcionar documentación e suxestións.
Os participantes do proxecto poden definir no seu repositorio o camiño a un esquema personalizado nun ficheiro .gitlab/.gitlab-webide.yml, que especifica o esquema e o camiño aos ficheiros que se van comprobar. Cando cargues un ficheiro específico no IDE web, verás comentarios e validacións adicionais para axudarche a crear o ficheiro.
и .
O límite de ramificación do gráfico acíclico dirixido (DAG) aumentou a 50
(CORE, INICIO, PREMIUM, ULTIMATE, GRATIS, BRONCE, PRATA, OURO)
Se está a usar cintas transportadoras (Gráfico acíclico dirixido (DAG)), pode descubrir que hai un límite de 10 traballos que un traballo pode especificar en needs:, moi duro. Na versión 13.4, o límite predeterminado aumentou de 10 a 50 para permitir redes máis complexas de relacións entre os traballos das túas canalizacións.
Se es administrador dunha instancia de GitLab personalizada, pode aumentar aínda máis este límite configurando unha función de alternancia, aínda que non ofrecemos soporte oficial para iso.
и .
Mellora do comportamento needs por tarefas perdidas
(CORE, INICIO, PREMIUM, ULTIMATE, GRATIS, BRONCE, PRATA, OURO)
Nalgúns casos, un traballo perdido nunha canalización podería considerarse incorrectamente exitoso para as dependencias especificadas en needs, o que provocou que se executasen traballos posteriores, o que non debería ocorrer. Este comportamento foi corrixido na versión 13.4 e needs agora xestiona correctamente os casos de tarefas perdidas.
и .
Fixa o último artefacto da misión para evitar que se elimine
(CORE, INICIO, PREMIUM, ULTIMATE, GRATIS, BRONCE, PRATA, OURO)
Agora GitLab bloquea automaticamente o último traballo exitoso e o artefacto da canalización en calquera rama activa, solicitude de combinación ou etiqueta para evitar que se elimine despois da súa expiración. É máis fácil establecer regras de caducidade máis agresivas para limpar artefactos antigos. Isto axuda a reducir o consumo de espazo en disco e garante que sempre tes unha copia do artefacto máis recente da canalización.
и .
Guía CI/CD para a optimización de tuberías
(CORE, INICIO, PREMIUM, ULTIMATE, GRATIS, BRONCE, PRATA, OURO)
A optimización da túa canalización CI/CD pode mellorar a velocidade de entrega e aforrar cartos. Melloramos a nosa documentación para incluír unha guía rápida para sacar o máximo proveito da optimización das túas canalizacións.
и .
Informe de proba ordenado por estado da proba
(CORE, INICIO, PREMIUM, ULTIMATE, GRATIS, BRONCE, PRATA, OURO)
é un xeito sinxelo de ver os resultados de todas as probas nunha canalización. Non obstante, cunha gran cantidade de probas, atopar probas erradas pode levar moito tempo. Outros problemas que poden dificultar o uso do informe inclúen a dificultade para desprazarse polas saídas de trazo longo e o redondeo do tempo a cero para as probas que se executan en menos de 1 segundo. Agora, de forma predeterminada, ao ordenar un informe de proba, primeiro coloca as probas fallidas ao comezo do informe e, a continuación, ordena as probas por duración. Isto fai máis doado atopar fallos e probas longas. Ademais, agora a duración das probas móstranse en milisegundos ou segundos, o que fai que sexa moito máis rápida de ler, e tamén se resolveron problemas de desprazamento anteriores.
и .
Límites no tamaño dos ficheiros cargados no rexistro de paquetes
(CORE, INICIO, PREMIUM, ULTIMATE, GRATIS, BRONCE, PRATA, OURO)
Agora hai límites no tamaño dos ficheiros de paquetes que se poden cargar no rexistro de paquetes de GitLab. Engadíronse restricións para optimizar o rendemento do rexistro de paquetes e evitar o abuso. Os límites varían segundo o formato do paquete. Para GitLab.com, os tamaños máximos dos ficheiros son:
- Conan: 250 MB
- Maven: 3 GB
- NPM: 300 MB
- NuGet: 250 MB
- PyPI: 3 GB
Para instancias personalizadas de GitLab, os valores predeterminados son os mesmos. Non obstante, o administrador pode actualizar as restricións usando .
и .
Use CI_JOB_TOKEN para publicar paquetes PyPI
(CORE, INICIO, PREMIUM, ULTIMATE, GRATIS, BRONCE, PRATA, OURO)
Podes usar o repositorio PyPI de GitLab para crear, publicar e compartir paquetes de Python xunto co código fonte e canalizacións CI/CD. Non obstante, anteriormente non se podía autenticar no repositorio mediante unha variable de ambiente predefinida CI_JOB_TOKEN. Como resultado, tivo que usar as súas credenciais persoais para actualizar o repositorio de PyPI, ou quizais decidiu non usar o repositorio en absoluto.
Agora é máis doado usar GitLab CI/CD para publicar e instalar paquetes PyPI usando unha variable de ambiente predefinida CI_JOB_TOKEN.
и .
Perfís de escáner DAST baixo petición
(ÚLTIMO, OURO)
Para a exploración DAST baixo demanda que foi , engadíronse perfís de escáner DAST. Amplían as capacidades de configuración destas exploracións, o que lle permite crear rapidamente varios perfís para cubrir varios tipos de exploración. Na versión 13.4, o perfil do rastrexador inclúe de forma nativa unha configuración de tempo de espera do rastrexador que establece o tempo que debe executarse o rastrexador DAST mentres tenta descubrir todas as páxinas dun sitio rastrexado. O perfil tamén inclúe unha configuración de tempo de espera do sitio de destino para establecer canto tempo debe esperar o rastrexador para que un sitio sexa accesible antes de abortar a exploración se o sitio non responde cun código de estado 200 ou 300. A medida que seguimos mellorando, esta función será engadirase ao perfil do escáner en versións futuras; engadiranse parámetros de configuración adicionais.
и .
Un ficheiro de configuración de redirección sinxelo para GitLab Pages
(CORE, INICIO, PREMIUM, ULTIMATE, GRATIS, BRONCE, PRATA, OURO)
Se usas GitLab Pages e queres xestionar mellor os cambios de URL, quizais teñas notado que non era posible xestionar as redireccións no teu sitio de GitLab Pages. GitLab agora permíteche configurar regras para redirixir un URL a outro para o teu sitio de Páxinas engadindo un ficheiro de configuración ao repositorio. Esta función é posible grazas á contribución de Kevin Barnett (), o noso Eric Eastwood () e equipos de GitLab. Grazas a todos pola vosa entrada.
и .
Estado de Terraform xestionado por GitLab
(CORE, INICIO, PREMIUM, ULTIMATE, GRATIS, BRONCE, PRATA, OURO)
O acceso a versións anteriores do estado de Terraform é necesario tanto para o cumprimento como para a depuración se é necesario. O soporte para o estado de versión de Terraform xestionado por GitLab ofrécese a partir de GitLab 13.4. A versión está habilitada automaticamente para os novos ficheiros de estado de Terraform. Os ficheiros de estado de Terraform existentes serán nun lanzamento posterior.
и .
Detalles de notificación de incidentes importantes
(CORE, INICIO, PREMIUM, ULTIMATE, GRATIS, BRONCE, PRATA, OURO)
Ao procesar incidentes, debes poder determinar facilmente canto tempo estivo aberta unha alerta e cantas veces se disparou o evento. Estes detalles adoitan ser críticos para determinar o impacto no cliente e o que o seu equipo debe abordar primeiro. No novo panel Detalles do incidente, mostramos a hora de inicio da alerta, o número de eventos e unha ligazón á alerta orixinal. Esta información está dispoñible para as incidencias que se xeran a partir de alertas.
и .
Configurar e editar o parámetro de gravidade do incidente
(CORE, INICIO, PREMIUM, ULTIMATE, GRATIS, BRONCE, PRATA, OURO)
A dimensión Gravidade do incidente permite aos respondedores e ás partes interesadas determinar o impacto dunha interrupción, así como o método e a urxencia da resposta. Como o teu equipo comparte os resultados durante a resolución e a recuperación de incidentes, pode cambiar esta configuración. Agora podes editar a gravidade dun incidente na barra lateral dereita da páxina Detalles do incidente, e a gravidade móstrase na lista de incidentes.
и .
Creación, edición e eliminación de regras de seguridade de rede de contedores
(ÚLTIMO, OURO)
Esta mellora do Editor de regras de seguranza de Container Network permite aos usuarios crear, editar e eliminar facilmente as súas regras directamente desde a interface de usuario de GitLab. As características do editor inclúen .yaml para usuarios experimentados e un editor de regras cunha interface intuitiva para aqueles que non coñecen as regras de rede. Podes atopar novas opcións de xestión de regras na sección Seguridade e cumprimento > Xestión de ameazas > Regras (Seguridade e cumprimento > Xestión de ameazas > Políticas).
и .
Soporte de almacenamento de blobs de Azure
(CORE, INICIO, PREMIUM, ULTIMATE, GRATIS, BRONCE, PRATA, OURO)
Tanto GitLab como GitLab Runner agora son compatibles , facilitando a execución dos servizos de GitLab en Azure.
As instancias de GitLab admiten Azure para todo tipo de almacéns de obxectos, incluídos ficheiros LFS, artefactos CI e . Para configurar o almacenamento de Azure Blob, siga as instrucións de instalación ou .
Os procesadores de traballos de GitLab tamén admiten Azure para o almacenamento . O almacenamento de Azure pódese configurar mediante a sección .
и .
Paquetes Omnibus ARM64 para Ubuntu e OpenSUSE
(CORE, STARTER, PREMIUM, ULTIMATE)
En resposta á crecente demanda de soporte para executar GitLab en arquitectura ARM de 64 bits, temos o pracer de anunciar a dispoñibilidade do paquete oficial ARM64 Ubuntu 20.04 Omnibus. Moitas grazas a Zitai Chen e Guillaume Gardet polas enormes contribucións que fixeron: as súas solicitudes de fusión xogaron un papel fundamental nisto!
Para descargar e instalar o paquete para Ubuntu 20.04, vai ao noso e selecciona Ubuntu.
и .
Soporte de autenticación de tarxeta intelixente para o gráfico GitLab Helm
(PREMIUM, ULTIMATE)
As tarxetas intelixentes, como as tarxetas de acceso común (CAC), agora pódense usar para autenticarse nunha instancia de GitLab implantada a través do gráfico Helm. As tarxetas intelixentes autentícanse nunha base de datos local mediante certificados X.509. Con isto, a compatibilidade con tarxetas intelixentes co gráfico Helm está agora en liña coa compatibilidade con tarxetas intelixentes dispoñible nas implementacións de Omnibus.
и .
As notas de versión detalladas e as instrucións de actualización/instalación pódense atopar na publicación orixinal en inglés: .
Estivemos traballando na tradución do inglés , , и .
Fonte: www.habr.com