Se lanzó la versión 13.4 con el almacenamiento HashiCorp para variables CI, el Agente de Kubernetes y un centro de seguridad, así como funciones alternables en Starter
En GitLab siempre estamos pensando en cómo ayudar a los usuarios a reducir riesgos, aumentar la eficiencia y la velocidad de entrega en su plataforma favorita. Este mes hemos añadido varias novedades útiles que amplían las capacidades de seguridad, reducen el número de vulnerabilidades, mejoran la eficiencia, simplifican el uso de GitLab y ayudan a su equipo a entregar características aún más rápido. Esperamos que le sean útiles las características principales de esta versión, así como 53 nuevas características adicionales, añadidas en esta versión.
Mejoras en la seguridad
Cada mes nos esforzamos por añadir nuevas funciones a GitLab DevSecOps, y esta versión no es una excepción. durante la construcción y despliegue. Además, las organizaciones que desean mantener la división de responsabilidades en el despliegue de código ahora pueden . Este rol se adhiere al y permitirá validar solicitudes de fusión y desplegar código en entornos protegidos sin proporcionar acceso para modificar el código mismo.
Otra forma de reducir riesgos es mediante el nuevo . Los especialistas en operaciones pueden desplegar clústeres de Kubernetes desde GitLab sin tener que abrir el acceso a su clúster a toda la internet. También presentamos soporte automático para el control de versiones de nuevos archivos de estado de Terraform con para cumplir con los requisitos y facilitar la depuración. Y finalmente, el panel de seguridad en la instancia se ha convertido en un con informes de vulnerabilidades y configuraciones de seguridad.
Trabajo más cómodo y eficiente con GitLab
Hemos mejorado nuestra búsqueda global al añadir , lo que permite acceder fácilmente a los últimos tickets, grupos, proyectos, configuraciones y secciones de ayuda. Nos complace anunciar que en GitLab Pages para redirigir páginas y directorios específicos dentro del sitio, lo que permitirá a los usuarios desplegar sus sitios de manera más eficiente. Y para aquellos que desean obtener información ampliada sobre el despliegue, esta versión permite !
Contribuciones de código abierto
Presentamos , que añadió . Las marcas de cobertura de las pruebas unitarias del código modificado brindan a los desarrolladores una representación visual de la cobertura del código durante la revisión; esta información ayuda a acelerar las revisiones y reducir el tiempo de fusión y despliegue de un nuevo código. Además, y planeamos .
¡Y esto es solo el principio!
Como siempre, en el resumen general hay muy poco espacio, y hay muchas características interesantes en la versión 13.4. Aquí hay unas cuantas más:
- .
Si desea saber por adelantado qué esperar en la próxima versión, eche un vistazo a .
.
de este mes —
Fabio hizo una contribución significativa en — una función que ha sido muy esperada en la comunidad de GitLab. Este es un aporte realmente importante con cambios no triviales que requirieron una colaboración continua con miembros del equipo de GitLab y abarcó múltiples áreas del proyecto, como UX, frontend y backend.
Características principales de la versión GitLab 13.4
Utilice claves de HashiCorp Vault en trabajos de CI
(PREMIUM, ULTIMATE, SILVER, GOLD)
En la versión 12.10, GitLab introdujo la capacidad de recibir y pasar claves en tareas de CI mediante el controlador de tareas de GitLab (GitLab runner). Ahora estamos ampliando , agregando una nueva sintaxis secrets en el archivo .gitlab-ci.yml. Esto facilitará la configuración y el uso del almacenamiento de HashiCorp con GitLab.
y .
Presentamos el Agente de GitLab Kubernetes
(PREMIUM, ULTIMATE)
La integración de GitLab con Kubernetes ha permitido durante mucho tiempo desplegar en clústeres de Kubernetes sin necesidad de configuración manual. A muchos usuarios les ha gustado la facilidad de uso de esta combinación, mientras que otros se han encontrado con algunas dificultades. Para la integración actual, su clúster debe ser accesible desde Internet para que GitLab pueda acceder a él. Para muchas organizaciones, esto no es posible, ya que restringen el acceso a los clústeres por motivos de seguridad, cumplimiento normativo o regulaciones. Para sortear estas limitaciones, los usuarios han tenido que crear sus propias herramientas sobre GitLab, de lo contrario, no podrían hacer uso de esta función.
Hoy presentamos el Agente de Kubernetes de GitLab, una nueva forma de desplegar en clústeres de Kubernetes. El agente funciona dentro de su clúster, por lo que no necesitará abrirlo a toda Internet. El agente coordina el despliegue solicitando nuevos cambios a GitLab, en lugar de que GitLab envíe actualizaciones al clúster. Independientemente del método de GitOps que utilice, GitLab le será útil.
Tenga en cuenta que este es el primer lanzamiento del agente. Actualmente, nos hemos centrado en la configuración y gestión del despliegue a través del código para el Agente de Kubernetes de GitLab. Algunas funciones existentes de integración de Kubernetes, como los tableros de despliegue y las aplicaciones gestionadas por GitLab, aún no están soportadas. , que estas funcionalidades serán añadidas al agente en futuros lanzamientos, así como nuevas integraciones enfocadas en la seguridad y el cumplimiento normativo.
y .
Otorgue a los usuarios permisos para desplegar sin acceso al código
(PREMIUM, ULTIMATE, SILVER, GOLD)
Anteriormente, el sistema de permisos en GitLab no permitía dividir adecuadamente las responsabilidades en su equipo entre aquellos que se encargan de desarrollo y aquellos que se encargan de despliegue. Con el lanzamiento de GitLab 13.4, puede otorgar permiso para aprobar solicitudes de fusión para despliegues, así como para el despliegue real de código a personas que no escriben código, sin otorgarles acceso de mantenedor.
y .
Centro de Seguridad
(ULTIMATE, GOLD)
Anteriormente, la gestión de vulnerabilidades a nivel de instancia estaba limitada tanto en funcionalidad como en flexibilidad. La interfaz consistía en una sola página que combinaba detalles de vulnerabilidades, gráficos de métricas y configuraciones. No había mucho espacio para desarrollar estas funciones o utilizar otras herramientas de seguridad.
Hemos realizado cambios fundamentales en la gestión de seguridad y su transparencia en GitLab. El panel de seguridad de la instancia se ha transformado en un verdadero centro de seguridad. El cambio más significativo es la introducción de una nueva estructura de menú: en lugar de una sola página, ahora puedes ver por separado el panel de control de seguridad, el informe de vulnerabilidades y la sección de configuraciones. Aunque la funcionalidad no ha cambiado, esta división permitirá mejorar esta sección, lo que de otro modo sería difícil. También crea una base para agregar en el futuro otras capacidades relacionadas con la seguridad.
Ahora hay más espacio en la sección especial para el informe de vulnerabilidades para mostrar detalles importantes. Aquí se recopilan las vulnerabilidades que actualmente están en la lista de vulnerabilidades del proyecto. La transferencia de widgets con métricas de vulnerabilidades a una sección separada crea un panel de control de seguridad más conveniente. Ahora es un lienzo para futuras visualizaciones, no solo para la gestión de vulnerabilidades, sino también para cualquier métrica relacionada con la seguridad. Finalmente, el área de configuración separada crea un espacio común para todas las configuraciones de seguridad a nivel de instancia, no solo para la gestión de vulnerabilidades.
y .
Características alternables ahora en GitLab Starter
(STARTER, PREMIUM, ULTIMATE, BRONCE, PLATA, ORO)
En GitLab 11.4 se lanzó . En 12.2 introdujimos estrategias para ellas y , y en 13.1 añadimos y para diferentes entornos.
A principios de este año, GitLab se comprometió a al código abierto. En esta versión completamos la migración de características alternables al plan Starter y continuaremos su traslado a Core con . Estamos contentos de proporcionar esta oportunidad a más usuarios y queremos saber cómo las utilizarán.
y .
Navegación rápida desde la barra de búsqueda
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
A veces, al navegar por GitLab, quieres ir directamente a un proyecto específico en lugar de a la página de resultados de búsqueda.
Con el panel de búsqueda global, puedes acceder rápidamente a los últimos tickets, grupos, proyectos, configuraciones y secciones de ayuda. También puedes usar la tecla de acceso rápido /, para mover el cursor al panel de búsqueda y así navegar por GitLab de manera aún más eficiente!
y .
Visualización de la cobertura de código en los diffs de las solicitudes de fusión
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Al revisar una solicitud de fusión, puede ser difícil determinar si el código modificado está cubierto por pruebas unitarias. En su lugar, los revisores pueden depender de la cobertura general y requerir que esta aumente antes de aprobar la solicitud de fusión. Esto puede llevar a un enfoque desorganizado para escribir pruebas, lo que en realidad no mejora la calidad del código o su cobertura de pruebas.
Ahora, al ver el diff de una solicitud de fusión, verás una representación visual de la cobertura de código. Las nuevas anotaciones permitirán entender rápidamente si el código modificado está cubierto por una prueba unitaria, lo que ayudará a acelerar la revisión del código y el tiempo de fusión y despliegue del nuevo código.
Gracias ¡y Siemens por esta función!
y .
Más entornos y proyectos en el panel de entornos
(PREMIUM, ULTIMATE, SILVER, GOLD)
Desde el lanzamiento de GitLab 12.5, con el podías rastrear el estado de los entornos, pero no más de siete entornos en tres proyectos. Hemos mejorado este panel en la versión 13.4, dividiéndolo en páginas para ayudarte a mantener y gestionar tus entornos a gran escala. Ahora puedes ver más entornos en más proyectos.
y .
GitLab ha asumido la gestión del proveedor de GitLab Terraform
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Recientemente, y planeamos En el último mes, hemos aceptado 21 solicitudes de fusión y cerrado 31 tickets, incluidos algunos errores de larga data y funciones faltantes, como Puedes en la documentación de Terraform.
y .
Pruebas de fuzzing de API con especificaciones OpenAPI o un archivo HAR.
(ULTIMATE, GOLD)
Las pruebas de fuzzing de API son una excelente manera de buscar errores y vulnerabilidades en sus aplicaciones web y APIs que otros escáneres y métodos de prueba pueden pasar por alto.
Las pruebas de API con fuzzing en GitLab permiten proporcionar o de su aplicación y luego genera automáticamente datos de entrada aleatorios destinados a probar casos límites y encontrar errores. Los resultados se muestran inmediatamente en su canalización.
Esta es nuestra primera versión de pruebas de API con fuzzing, y nos encantaría saber lo que piensa. Para las pruebas de fuzzing, tenemos muchas , que basaremos en el lanzamiento de esta función.
y .
Vista previa de nuevos gráficos en el panel de métricas
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Antes, crear un gráfico en el panel de métricas en GitLab era una tarea complicada. Después de crear una métrica en el archivo YAML del panel, realizaba cambios en master, sin la posibilidad de verificar que el gráfico recién creado funcionara como lo necesitaba. A partir de esta versión, puede previsualizar los cambios mientras crea el gráfico, obteniendo una visión del resultado antes de enviar los cambios al archivo YAML del panel.
y .
Datos sobre la cobertura de código de pruebas en todos los proyectos del grupo
(PREMIUM, ULTIMATE, SILVER, GOLD)
Cuando gestiona una gran cantidad de proyectos en GitLab, necesita una fuente única de información sobre cómo cambia a lo largo del tiempo la cobertura de código en todos los proyectos. Anteriormente, mostrar esta información requería un trabajo manual tedioso y laborioso: tenía que descargar los datos de cobertura de código de pruebas de cada proyecto y combinarlos en una tabla.
En la versión 13.4, se introdujo la posibilidad de recopilar de manera rápida y sencilla en .csv todos los datos de cobertura de código de todos los proyectos del grupo o de una selección de proyectos. Esta función es MVC, seguida de la capacidad de .
y .
Soporte para nuevos lenguajes para pruebas de fuzzing completas
(ULTIMATE, GOLD)
Esta versión presenta soporte para varios nuevos lenguajes para pruebas de fuzzing dirigidas a una cobertura completa.
Ahora puede evaluar todas las capacidades de las pruebas de fuzzing en sus aplicaciones en Java, Rust y Swift y encontrar errores y vulnerabilidades que otros escáneres y métodos de prueba pueden pasar por alto.
y .
Alertas en la página principal de entornos
(PREMIUM, ULTIMATE, SILVER, GOLD)
La página de entornos muestra el estado general de sus entornos. En esta versión, hemos mejorado esta página añadiendo la visualización de alertas. Las alertas activadas junto con el estado de sus entornos le ayudarán a tomar medidas más rápidamente para solucionar problemas que puedan surgir.
y .
Los pipelines anidados ahora pueden ejecutar sus propios pipelines anidados
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Al utilizar pipelines anidados, ahora es posible ejecutar nuevos pipelines dentro de los pipelines secundarios. Un nivel adicional de profundidad puede ser útil si necesita flexibilidad para generar una cantidad variable de pipelines.
Antes, al utilizar pipelines anidados, cada pipeline secundario requería un disparador manual establecido en el pipeline primario. Ahora puede crear pipelines anidados que se inicien dinámicamente y ejecuten cualquier cantidad de nuevos pipelines anidados. Por ejemplo, si tiene un monorepo, puede generar dinámicamente el primer pipeline anidado que a su vez generará la cantidad necesaria de nuevos pipelines basándose en los cambios en la rama.
y .
Navegación mejorada entre pipelines primarios y anidados
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Antes, moverse entre pipelines primarios y anidados no era muy conveniente; necesitaba varios clics para llegar al pipeline deseado. También era difícil entender qué tarea había activado este pipeline. Ahora, ver las relaciones entre los pipelines primarios y anidados será mucho más fácil.
y .
Las tareas matriciales en paralelo muestran variables relevantes en el nombre de la tarea
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Si ha utilizado , puede haber notado que era difícil determinar qué variable matricial se usó para una tarea específica, ya que los nombres de las tareas se veían como matrix 1/4En la versión 13.4, verás valores relevantes de las variables que se han utilizado en esta tarea, en lugar del nombre genérico de la tarea. Por ejemplo, si tu objetivo es la depuración para la arquitectura x86, la tarea se llamará matrix: debug x86.
y .
Otras mejoras en GitLab 13.4
Conexión de cuenta de Atlassian
(CORE, STARTER, PREMIUM, ULTIMATE)
Los usuarios de GitLab ahora pueden conectar sus cuentas de GitLab a su cuenta de Atlassian Cloud. Esto permitirá iniciar sesión en GitLab con las credenciales de Atlassian y establecerá las bases para futuras mejoras en la integración y con otros productos de la línea Atlassian.
y .
Exportar la lista de todos los commits de fusión
(ULTIMATE, GOLD)
Las organizaciones que buscan cumplir con los requisitos necesitan una manera de mostrar a los auditores una visión integral de los componentes relacionados con cualquier cambio específico en producción. Dentro de GitLab, esto significa que necesitas reunir en un solo lugar todo: solicitudes de fusión, tickets, pipelines, análisis de seguridad y otros datos de commits. Hasta ahora, has tenido que recopilar esto manualmente en GitLab o configurar tus herramientas para recopilar información, lo que no era muy eficiente.
Ahora puedes recopilar y exportar estos datos programáticamente para cumplir con los requisitos de auditoría o realizar otros análisis. Para exportar la lista de todos los commits de fusión para el grupo actual, debes ir a y hacer clic en el botón Lista de todos los commits de fusión. El archivo resultante contendrá todos los commits de la solicitud de fusión, su autor, el ID de la solicitud de fusión relacionada, grupo, proyecto, confirmadores y otra información.
y .
Salida de la lista y gestión de tokens de acceso personal a través de API
(ULTIMATE, GOLD)
La gestión del acceso al espacio de nombres de GitLab es una parte crucial de la actividad de cumplimiento. Desde los principios de privilegios mínimos hasta la revocación del acceso por tiempo, pueden existir varios requisitos relacionados con los tokens de acceso personal en GitLab. Para facilitar la gestión y mantenimiento de todas estas credenciales de usuario dentro de tu espacio de nombres, hemos proporcionado la opción de listar todos los tokens de acceso personal y opcionalmente a través de la API.
Estas mejoras en la API de GitLab permiten a los usuarios listar y revocar sus propios tokens de acceso personal, y a los administradores, listar y revocar los tokens de sus usuarios. Ahora será más fácil para los administradores ver quién tiene acceso a su espacio de nombres, tomar decisiones sobre el acceso basado en los datos de los usuarios, así como revocar tokens de acceso personal que puedan haber sido comprometidos o que excedan las políticas de gestión de acceso de la empresa.
y .
Tickets relacionados y otras funciones ahora en GitLab Core
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Hace unos meses anunciamos un plan para . Al trabajar para cumplir esta promesa, hemos creado , y (en la localización rusa de GitLab, "tablero de discusión") disponibles en el plan Core. Esto se aplica solo a las relaciones del tipo "relacionado con", las relaciones del tipo "bloquea" y "es bloqueado" permanecen en los planes de pago.
y .
Mostrar el nombre de la rama de origen en la barra lateral de la solicitud de fusión
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Al revisar cambios de código, discusiones y confirmaciones de la solicitud de fusión, a menudo se desea hacer un checkout local de la rama para una revisión más profunda. Sin embargo, encontrar el nombre de la rama se vuelve cada vez más difícil a medida que se agrega más contenido a la descripción de la solicitud de fusión, y se tiene que desplazarse más hacia abajo en la página.
Hemos añadido el nombre de la rama en la barra lateral de la solicitud de fusión, lo que lo hace accesible en todo momento y elimina la necesidad de desplazarse por toda la página. Al igual que el enlace a la solicitud de fusión, la sección de la rama de origen contiene un conveniente botón de "copiar".
Gracias por su gran contribución al desarrollo de esta función!
y .
Indicación de archivos contraídos en las diferencias de la solicitud de fusión
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Las solicitudes de fusión que agregan cambios a varios archivos a veces colapsan las diferencias de archivos grandes para mejorar el rendimiento de la visualización. Cuando esto sucede, se puede pasar por alto un archivo durante la revisión, especialmente en solicitudes de fusión con un gran número de archivos. A partir de la versión 13.4, las solicitudes de fusión marcarán las diferencias que contienen archivos colapsados, lo que garantiza que no se perderán esos archivos en el proceso de revisión del código. Para mayor claridad, planeamos agregar resaltado de estos archivos en una futura entrega. Estén atentos a las actualizaciones en .
y .
Advertencia sobre la existencia de archivos colapsados en la diferencia de la solicitud de fusión
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
En la sección de diferencias de las solicitudes de fusión, los archivos grandes se colapsan para aumentar el rendimiento. Sin embargo, durante la revisión del código, algunos archivos pueden pasarse por alto cuando el revisor desplaza la lista de archivos, ya que todos los archivos grandes están colapsados.
Hemos añadido una advertencia visible en la parte superior de la página de diferencias de la solicitud de fusión para informar a los usuarios que hay un archivo colapsado en esta sección. Así, no se perderán ningún cambio en la solicitud de fusión durante la revisión.
y .
Restauración automática del repositorio del clúster Gitaly
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Anteriormente, cuando el nodo primario del clúster Gitaly se desconectaba, los repositorios en ese nodo se marcaban como de solo lectura. Esto prevenía la pérdida de datos en situaciones en las que había cambios en el nodo que aún no se habían replicado. Cuando el nodo se reconectaba, GitLab no se restauraba automáticamente, y los administradores tenían que iniciar manualmente el proceso de sincronización o aceptar la pérdida de datos. Otras situaciones, como la finalización fallida de una tarea de replicación en un nodo secundario, también podían llevar a repositorios desactualizados o de solo lectura. En este caso, el repositorio permanecía desactualizado hasta que se realizaba la siguiente operación de escritura que iniciaba la tarea de replicación.
Para abordar este problema Ahora planea una tarea de replicación cuando detecta un repositorio obsoleto en un nodo y la última versión del repositorio en otro. Esta tarea de replicación actualiza automáticamente el repositorio, eliminando la necesidad de restaurar los datos manualmente. La recuperación automática también asegura que los nodos secundarios se pongan al día rápidamente si la tarea de replicación falla, en lugar de esperar a la siguiente operación de escritura. Dado que muchos clústeres de Gitaly almacenan un gran número de repositorios, esto reduce significativamente el tiempo que los administradores y los ingenieros de confiabilidad dedican a recuperar datos tras un error.
Además, la reparación automática inicia la replicación de repositorios en cualquier nuevo nodo de Gitaly que se añada al clúster, lo que elimina el trabajo manual al añadir nuevos nodos.
y .
Marca la tarea to-do como completada en la página de diseño
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
La comunicación efectiva en GitLab se basa en listas de tareas to-do. Si se te menciona en un comentario, es crucial poder acceder a la tarea y comenzar a trabajar en ella o marcarla como ya completada. También es importante poder asignarte una tarea cuando necesitas trabajar en algo o volver a ello más tarde.
Antes no podías agregar tareas o marcarlas como completadas al trabajar con diseños. Esto interrumpía seriamente la efectividad de la comunicación entre los equipos de producto, ya que las tareas to-do son un elemento crítico del flujo de trabajo en GitLab.
En la versión 13.4, los diseños siguen los comentarios de los tickets en el uso de tareas, lo que hace que trabajar con ellos sea más consistente y efectivo.
y .
Guía mejorada para la resolución de problemas para CI/CD
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Hemos mejorado la guía de resolución de problemas para GitLab CI/CD, agregando información adicional sobre problemas comunes que puedes encontrar. Esperamos que la documentación mejorada sea un recurso valioso que te ayude a configurar y ejecutar GitLab CI/CD de manera rápida y sencilla.
y .
Las solicitudes de fusión ya no se eliminan de la cola de fusión
(PREMIUM, ULTIMATE, SILVER, GOLD)
Anteriormente, las solicitudes de fusión podrían eliminarse de la cola de fusión por accidente debido a comentarios tardíos. Si una solicitud de fusión ya estaba en la cola y alguien añadía un comentario que generaba una nueva discusión no resuelta, la solicitud de fusión se consideraba inapropiada para la fusión y se eliminaba de la cola. Ahora, después de que una solicitud de fusión se añade a la cola de fusión, se pueden añadir nuevos comentarios sin miedo a interrumpir el proceso de fusión.
y .
Mostrar en la solicitud de fusión el valor de cobertura de código para la tarea
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Los desarrolladores deben tener la capacidad de ver el valor de cobertura de código después de que se complete la tubería, incluso en escenarios complejos, como cuando la tubería tiene múltiples tareas que deben analizarse para calcular el valor de cobertura. Anteriormente, el widget de la solicitud de fusión mostraba solo el promedio de estos valores, lo que significaba que tenía que navegar a la página de la tarea y volver a la solicitud de fusión para obtener los valores intermedios de cobertura. Para ahorrarle tiempo y evitar estos pasos innecesarios, hemos presentado en el widget la visualización del promedio de cobertura, su cambio entre las ramas objetivo y base, y una sugerencia emergente que muestra el valor de cobertura para cada tarea, sobre la cual se calculó el promedio.
y .
Eliminación de paquetes del registro de paquetes al ver un grupo
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
El registro de paquetes de GitLab es un lugar para almacenar y distribuir paquetes en diferentes formatos. Cuando su proyecto o grupo tiene muchos paquetes, necesita identificar rápidamente los paquetes no utilizados y eliminarlos para que las personas no los descarguen. Puede eliminar paquetes de su registro a través de o a través de la interfaz de usuario del registro de paquetes. Sin embargo, hasta ahora no ha podido eliminar paquetes al ver un grupo a través de la interfaz de usuario. Como resultado, tuvo que eliminar los paquetes sobrantes uno por uno en cada proyecto, lo que era ineficiente.
Ahora puede eliminar paquetes al ver el registro de paquetes del grupo. Simplemente vaya a la página del registro de paquetes del grupo, filtre los paquetes por nombre y elimine todos los innecesarios.
y .
Escalado de paquetes de Conan a nivel de proyecto
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Puede utilizar el repositorio de Conan en GitLab para publicar y distribuir dependencias de C/C++. Sin embargo, anteriormente solo se podían escalar paquetes a nivel de instancia, ya que el nombre del paquete de Conan podía constar de un máximo de 51 caracteres. Si deseaba publicar un paquete de un subgrupo, por ejemplo, gitlab-org/ci-cd/package-stage/feature-testing/conan, era casi imposible hacerlo.
Ahora puede escalar paquetes de Conan a nivel de proyecto, lo que facilita la publicación y distribución de las dependencias de sus proyectos.
y .
Soporte para nuevos gestores de paquetes y lenguajes para el escaneo de dependencias
(ULTIMATE, GOLD)
Nos complace añadir escaneos de dependencias para proyectos con código en C, C++, C# y .Net que utilizan NuGet 4.9+ o gestores de paquetes de Conan, a nuestra lista . Ahora puede incluir el escaneo de dependencias como parte de la etapa Secure para verificar vulnerabilidades conocidas en las dependencias añadidas a través de los gestores de paquetes. Las vulnerabilidades encontradas se mostrarán en su merge request junto con el nivel de peligro, para que sepa antes de realizar el merge qué riesgos conlleva una nueva dependencia. También puede configurar su proyecto para que requiera para dependencias con vulnerabilidades de nivel crítico (Critical), alto (High) o desconocido (Unknown).
y .
Notificaciones al cambiar la configuración del merge request a ‘Merge cuando finalice la tubería’
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Anteriormente, al establecer la configuración del merge request Merge cuando el pipeline finalice (Merge When Pipeline Succeeds, MWPS) no se enviaba ninguna notificación por correo electrónico. Tenía que verificar manualmente el estado o esperar la notificación de finalización del merge. En esta versión, nos complace presentar la contribución del usuario , quien resolvió este problema al agregar el envío automático de notificaciones a todos los que están suscritos al merge request, cuando el revisor cambia la configuración de merge a MWPS.
y .
Creación de clústeres EKS con una versión de Kubernetes especificada por el usuario
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Los usuarios de GitLab ahora pueden elegir la versión de Kubernetes que se proporcionará con EKS; pueden elegir entre las versiones 1.14 a 1.17.
y .
Creación de incidentes como tipos de tickets
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
No todos los problemas que surgen activan inmediatamente el envío de notificaciones: los usuarios informan sobre fallos y los miembros del equipo se ocupan de los problemas de rendimiento. Ahora, los incidentes son un tipo de ticket, por lo que tus equipos podrán crearlos rápidamente dentro del flujo de trabajo habitual. Haz clic Nueva tarea desde cualquier lugar en GitLab, y en el campo Tipo selecciona Incidente.
y .
Mención de notificaciones de GitLab en Markdown
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Hemos mejorado las notificaciones de GitLab al agregar un nuevo tipo de mención específicamente para ellas en la versión de Markdown de GitLab, lo que facilita compartir y mencionar las notificaciones. Usa ^alert#1234, para mencionar una notificación en cualquier campo con formato Markdown: en incidentes, tickets o solicitudes de fusión. Esto también te ayudará a identificar las tareas que se crean a partir de notificaciones, en lugar de tickets o solicitudes de fusión.
y .
Visualización de la carga de notificaciones por incidentes
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
La descripción de la notificación contiene información crítica para diagnosticar fallos y recuperación, y esta información debe ser fácilmente accesible para que no tengas que cambiar de herramientas o pestañas al trabajar en la resolución de un incidente. Los incidentes generados a partir de notificaciones muestran la descripción completa de la notificación en la pestaña Detalles de la notificación.
Búsqueda avanzada 75% más rápida
(STARTER, PREMIUM, ULTIMATE, BRONCE, PLATA, ORO)
GitLab, como una única aplicación, tiene la oportunidad única de hacer que la búsqueda de contenido a través de todo el flujo de trabajo de DevOps sea rápida. En GitLab 13.4, la búsqueda avanzada proporciona resultados un 75% más rápido cuando está , como en GitLab.com.
y .
Visualización de proyectos eliminados para administradores
(CORE, STARTER, PREMIUM, ULTIMATE)
La capacidad de retrasar la eliminación de un proyecto se introdujo en 12.6 . Sin embargo, anteriormente no había forma de ver en un solo lugar todos los proyectos que estaban esperando ser eliminados. Ahora, los administradores de instancias de GitLab pueden ver todos los proyectos pendientes de eliminación en un solo lugar, junto con botones para restaurar fácilmente esos proyectos.
Esta funcionalidad permite a los administradores tener un mejor control sobre la eliminación de proyectos, recopilando toda la información necesaria en un solo lugar y proporcionando la posibilidad de cancelar acciones de eliminación no deseadas.
Gracias ¡gracias por esta función!
y .
Se ha añadido soporte para reglas de push en el API para grupos
(STARTER, PREMIUM, ULTIMATE, BRONCE, PLATA, ORO)
Antes, las reglas de push grupales solo podían configurarse visitando cada grupo individualmente a través de la interfaz de usuario de GitLab y aplicando esas reglas. Ahora puede gestionar estas reglas a través del API para soportar sus herramientas personalizadas y la automatización de GitLab.
y .
Revocación de tokens de acceso personal para la gestión de credenciales autogestionadas
(ULTIMATE)
proporciona a los administradores la información necesaria para gestionar las credenciales de los usuarios en su instancia de GitLab. Dado que las organizaciones basadas en el cumplimiento varían en la rigurosidad de sus políticas de gestión de credenciales, hemos añadido un botón que permite a los administradores revocar, si lo desean, el token de acceso personal del usuario (PAT). Ahora, los administradores pueden revocar fácilmente PAT potencialmente comprometidos. Esta función es útil para organizaciones que requieren opciones más flexibles para garantizar el cumplimiento y minimizar las distracciones para sus usuarios.
y .
Archivo de configuración para el editor de sitios estáticos
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
En GitLab 13.4, presentamos una nueva forma de configurar el editor de sitios estáticos. Aunque el archivo de configuración no guarda ni recibe parámetros en esta versión, estamos sentando las bases para la futura personalización del comportamiento del editor. En versiones posteriores, agregaremos al archivo .gitlab/static-site-editor.yml parámetros para establecer , donde , redefinición de la configuración de sintaxis de Markdown y otras configuraciones del editor.
y .
Edición de la sección introductoria del archivo con el editor de sitios estáticos
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
La sección introductoria (front matter) es una forma flexible y conveniente de definir variables de página en archivos de datos destinados a ser procesados por un generador de sitios estáticos. Se utiliza comúnmente para establecer el título de la página, la plantilla de diseño o el autor, pero puede utilizarse para pasar cualquier tipo de metadatos al generador al renderizar la página en HTML. Incluida en la parte superior de cada archivo de datos, la sección introductoria generalmente se formatea como YAML o JSON y requiere una sintaxis coherente y precisa. Los usuarios no familiarizados con las reglas de sintaxis específicas pueden introducir involuntariamente un marcado no válido, lo que puede causar problemas de formato o incluso fallos en la compilación.
El modo de edición WYSIWYG del editor de sitios estáticos ya elimina la sección introductoria del editor para prevenir estos errores de formato. Sin embargo, esto no le permite cambiar los valores almacenados en esta sección sin volver a la edición en modo de código fuente. En GitLab 13.4, puede acceder a cualquier campo y editar su valor en una interfaz familiar basada en formularios. Al hacer clic en el botón Configuraciones (Configura) se abrirá un panel que muestra un campo de formulario para cada clave definida al principio. Los campos se completan con el valor actual, y para editar cualquiera de ellos, simplemente tiene que ingresarlo en el formulario web. Esta edición de la sección introductoria ayuda a evitar complicaciones de sintaxis y le brinda control total sobre el contenido, asegurando un formato coherente del resultado final.
y .
GitLab para Jira y DVCS Connector ahora en Core
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Para los usuarios de Jira en GitLab: y permiten mostrar información sobre commits y merge requests de GitLab directamente en Jira. Junto con nuestra integración incorporada con Jira, puede navegar fácilmente entre las dos aplicaciones mientras trabaja.
¡Estas funciones solían estar disponibles solo en nuestro plan Premium, pero ahora están disponibles para todos los usuarios!
y .
Votación por mayoría para transacciones del clúster Gitaly (versión beta)
(CORE, STARTER, PREMIUM, ULTIMATE)
El clúster Gitaly permite replicar repositorios Git en varias nodos 'calientes' de Gitaly. Esto aumenta la disponibilidad al eliminar puntos únicos de fallo. , presentadas en GitLab 13.3, provocan la transmisión masiva de cambios a todos los nodos Gitaly en el clúster, pero solo los nodos Gitaly que votan de acuerdo con el nodo primario guardan cambios en disco. Si no hay consenso entre todos los nodos réplicas, solo una copia del cambio se guardará en disco, creando un punto único de fallo hasta que se complete la replicación asíncrona.
La votación por mayoría mejora la disponibilidad, requiriendo el consentimiento de la mayoría de los nodos (y no de todos) antes de guardar cambios en disco. Si esta opción habilitable está activada, la escritura deberá ejecutarse correctamente en varios nodos. Los nodos disidentes se sincronizan automáticamente mediante replicación asíncrona con aquellos nodos que formaron el quórum.
y .
Soporte para esquema personalizado para validación de JSON en Web IDE
(PREMIUM, ULTIMATE, SILVER, GOLD)
Los proyectos donde las personas escriben configuraciones en formato JSON o YAML a menudo enfrentan problemas, ya que es fácil cometer un error tipográfico y romper algo. Se pueden escribir herramientas de verificación que detecten estos problemas en la tubería CI, pero utilizar un archivo de esquema JSON puede ser útil para proporcionar documentación y sugerencias.
Los participantes del proyecto pueden definir en su repositorio la ruta al esquema personalizado en el archivo .gitlab/.gitlab-webide.yml, que especifica el esquema y la ruta a los archivos para la validación. Al cargar un archivo específico en Web IDE, se verá retroalimentación adicional y validación que ayudarán a crear el archivo.
y .
El límite de ramificación del grafo acíclico dirigido (DAG) se ha aumentado a 50
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Si utilizas tuberías (Directed Acyclic Graph (DAG)), es posible que hayas descubierto que el límite de 10 trabajos que una tarea puede especificar en needs:, demasiado severo. En la versión 13.4, el límite por defecto se aumentó de 10 a 50 para permitir redes de interrelaciones más complejas entre las tareas en sus pipelines.
Si usted es administrador de una instancia de GitLab, puede aumentar este límite aún más configurando una función opcional, aunque no ofrecemos soporte oficial para esto.
y .
Comportamiento mejorado needs para tareas omitidas
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
En algunos casos, una tarea omitida en el pipeline podría haberse considerado erróneamente exitosa para las dependencias especificadas en needs, lo que provocaba la ejecución de tareas subsiguientes, algo que no debía ocurrir. Este comportamiento se ha corregido en la versión 13.4, y needs ahora maneja correctamente los casos de tareas omitidas.
y .
Fije el último artefacto de la tarea para evitar su eliminación
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab ahora bloquea automáticamente el último artefacto de una tarea y un pipeline en cualquier rama activa, solicitud de fusión o etiqueta, para evitar su eliminación después de que expire. Es más fácil establecer reglas de expiración más agresivas para limpiar artefactos antiguos. Esto ayuda a reducir el consumo de espacio en disco y garantiza que siempre tenga una copia del último artefacto del pipeline.
y .
Guía de CI/CD para optimizar pipelines
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
La optimización del rendimiento del pipeline de CI/CD puede aumentar la velocidad de entrega y ahorrar dinero. Hemos mejorado nuestra documentación incluyendo una guía breve para maximizar el rendimiento de la optimización de sus pipelines.
y .
El informe de pruebas está clasificado por el estado de la prueba
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
— es una manera sencilla de ver los resultados de todas las pruebas en la canalización. Sin embargo, con un gran número de pruebas, encontrar las pruebas fallidas puede llevar mucho tiempo. Otros problemas que pueden dificultar el uso del informe incluyen dificultades para desplazarse por largas salidas de seguimiento y redondear el tiempo a cero para pruebas que tardan menos de 1 segundo. Ahora, por defecto, el informe de pruebas coloca primero las pruebas fallidas al comienzo del informe y luego ordena las pruebas por duración. Esto facilita la búsqueda de fallos y de pruebas largas. Además, la duración de las pruebas ahora se muestra en milisegundos o segundos, por lo que es mucho más rápido leerlas, y también se han resuelto los problemas anteriores con el desplazamiento.
y .
Limitaciones sobre el tamaño de archivos subidos al registro de paquetes
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Ahora hay limitaciones sobre el tamaño de los archivos de paquetes que se pueden subir al registro de paquetes de GitLab. Se han añadido estas limitaciones para optimizar el rendimiento del registro de paquetes y prevenir abusos. Las limitaciones dependen del formato del paquete. Para GitLab.com, los tamaños máximos de archivo son:
- Conan: 250MB
- Maven: 3GB
- NPM: 300MB
- NuGet: 250MB
- PyPI: 3GB
Para las instancias personalizadas de GitLab, los valores predeterminados son los mismos. Sin embargo, el administrador puede actualizar las limitaciones mediante .
y .
Usa CI_JOB_TOKEN para publicar paquetes PyPI
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Puedes utilizar el repositorio de GitLab PyPI para crear, publicar y compartir paquetes de Python junto con código fuente y canalizaciones CI/CD. Sin embargo, anteriormente no podías autenticarte en el repositorio utilizando una variable de entorno predefinida CI_JOB_TOKEN. Como resultado, tenías que utilizar tus credenciales personales para actualizar el repositorio PyPI, o quizá decidías no usar el repositorio en absoluto.
Ahora es más fácil usar GitLab CI/CD para publicar e instalar paquetes PyPI utilizando una variable de entorno predefinida CI_JOB_TOKEN.
y .
Perfiles del escáner DAST bajo demanda
(ULTIMATE, GOLD)
Para el escaneo DAST bajo demanda, que se , se han añadido perfiles de escáner DAST. Esto amplía las capacidades de configuración de este escaneo, permitiendo crear rápidamente múltiples perfiles para abarcar varios tipos de escáner. En la versión 13.4, el perfil del escáner incluye inicialmente un parámetro de tiempo de espera para el robot de búsqueda, que establece cuánto tiempo debe funcionar el robot DAST mientras intenta descubrir todas las páginas del sitio escaneado. El perfil también incluye un parámetro de tiempo de espera para el sitio objetivo, para establecer cuánto tiempo debe esperar el escáner hasta que el sitio esté disponible, antes de interrumpir el escaneo, si el sitio no responde con un código de estado 200 o 300. A medida que sigamos mejorando esta función en las próximas versiones, se agregarán parámetros de configuración adicionales al perfil del escáner.
y .
Archivo de configuración de redireccionamientos sencillo para GitLab Pages
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Si utilizas GitLab Pages y deseas gestionar mejor los cambios de URL, es posible que hayas notado que era imposible manejar redireccionamientos en tu sitio de GitLab Pages. GitLab ahora te permite configurar reglas para redirigir una URL a otra para tu sitio Pages, agregando un archivo de configuración en el repositorio. Esta función fue posible gracias a la participación de Kevin Barnett (), nuestro Eric Eastwood () y el equipo de GitLab. Gracias a todos por su contribución.
y .
Estado de Terraform gestionado por GitLab
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
El acceso a versiones anteriores del estado de Terraform es necesario tanto para cumplir con los requisitos como para la depuración cuando sea necesario. El soporte para la gestión de versiones del estado de Terraform gestionado por GitLab está disponible a partir de GitLab 13.4. La gestión de versiones se activa automáticamente para nuevos archivos de estado de Terraform. Los archivos de estado existentes de Terraform serán en una futura versión.
y .
Detalles importantes sobre las alertas de incidentes
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Al manejar incidentes, es fundamental poder determinar fácilmente cuánto tiempo estuvo abierto un aviso y cuántas veces se activó un evento. Estos detalles son a menudo cruciales para evaluar el impacto en el cliente y qué debe abordar su equipo como prioridad. En el nuevo panel de detalles del incidente, mostramos el tiempo de inicio de la alerta, la cantidad de eventos y un enlace al aviso original. Esta información está disponible para los incidentes que se generan a partir de alertas.
y .
Configuración y edición del parámetro de gravedad del incidente
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
El parámetro de 'gravedad del incidente' permite a los especialistas en respuesta y partes interesadas determinar las consecuencias de una interrupción, así como los métodos y la urgencia de la respuesta. A medida que su equipo comparte los resultados durante la resolución del incidente y la restauración del servicio, pueden modificar este parámetro. Ahora puede editar la gravedad del incidente en el panel lateral derecho de la página 'Detalles del incidente', y el nivel de gravedad se muestra en la lista de incidentes.
y .
Creación, edición y eliminación de reglas de seguridad de contenedores
(ULTIMATE, GOLD)
Esta mejora en el editor de reglas de seguridad de contenedores permite a los usuarios crear, editar y eliminar sus reglas fácilmente directamente desde la interfaz de usuario de GitLab. Las capacidades del editor incluyen el modo .yaml para usuarios avanzados y un editor de reglas con una interfaz intuitiva para aquellos que no están familiarizados con las reglas de red. Puede encontrar nuevas capacidades de gestión de reglas en la sección Seguridad y Cumplimiento > Gestión de Amenazas > Políticas (Security & Compliance > Threat Management > Policies).
y .
Soporte para almacenamiento de blobs de Azure
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Tanto GitLab como GitLab Runner ahora admiten , lo que facilita la ejecución de servicios de GitLab en Azure.
Las instancias de GitLab son compatibles con Azure para todos los tipos de almacenamiento de objetos, incluidos los archivos LFS, artefactos de CI y . Para configurar el almacenamiento de blobs de Azure, siga las instrucciones de instalación o .
Los manejadores de trabajos de GitLab también admiten Azure para almacenamiento . Se puede configurar el almacenamiento de Azure a través de la sección .
y .
Paquetes Omnibus ARM64 para Ubuntu y OpenSUSE
(CORE, STARTER, PREMIUM, ULTIMATE)
En respuesta a la creciente demanda de soporte para ejecutar GitLab en arquitecturas ARM de 64 bits, nos complace anunciar la disponibilidad del paquete oficial ARM64 Ubuntu 20.04 Omnibus. Un gran agradecimiento a Zitai Chen y Guillaume Gardet por su valiosa contribución; sus solicitudes de fusión han sido clave en esto.
Para descargar e instalar el paquete para Ubuntu 20.04, visite nuestra y seleccione Ubuntu.
y .
Soporte para autenticación con tarjetas inteligentes en el Helm chart de GitLab
(PREMIUM, ULTIMATE)
Las tarjetas inteligentes, como las tarjetas de acceso común (CAC), ahora se pueden usar para la autenticación en una instancia de GitLab desplegada a través del Helm chart. Las tarjetas inteligentes se autentican en la base de datos local usando certificados X.509. Gracias a esto, el soporte para tarjetas inteligentes en el Helm chart ahora está alineado con el soporte disponible en los despliegues de Omnibus.
y .
Las notas de la versión detalladas y las instrucciones de actualización/instalación se pueden leer en el comentario original en inglés: .
El trabajo de traducción del inglés estuvo a cargo de , , y .
Fuente: habr.com
