Los gerentes de desarrollo necesitan una descripción clara y comprensible del estado de seguridad de la aplicación y el cumplimiento de los requisitos para sus proyectos. La versión de diciembre de GitLab lo ayudará a rastrear estos parámetros importantes de manera más efectiva.
Estado de seguridad del proyecto
En la versión 12.6, agregamos una nueva función al panel de seguridad del proyecto , que muestra una evaluación del estado de seguridad de sus proyectos. Por lo tanto, los gerentes de desarrollo podrán comprender rápidamente qué proyectos pueden estar en riesgo y brindar la atención necesaria a problemas específicos.
Auditoría mejorada con materiales de liberación
Casi todos los equipos empresariales deben documentar su trabajo y proporcionar evidencia de que cada versión cumple con todos los requisitos y procedimientos de la organización. A menudo, esto significa que la empresa tiene procesos manuales para mantener la documentación actual para que esté disponible para futuras verificaciones de cumplimiento. GitLab 12.6 simplifica el proceso de auditoría gracias al archivo con los materiales de lanzamiento , un objeto JSON que contiene enlaces a piedras de correo y tickets relacionados con el lanzamiento, lo que ayudará en futuras auditorías.
Gestione y distribuya eficazmente los recursos C / C ++
Muchos equipos están desarrollando activamente aplicaciones C y C ++ de alto rendimiento, y necesitan una herramienta para administrar y distribuir convenientemente archivos compilados y archivos binarios de proyectos. Con la versión 12.6, se ha vuelto más fácil trabajar con estos archivos tanto pública como privadamente, gracias a la integración con el popular repositorio de Conan . Ahora los desarrolladores podrán utilizar todas las ventajas de la colocación de código, canalizaciones automatizadas (en la localización rusa de las "líneas de ensamblaje" de GitLab) y los paquetes resultantes en una sola aplicación, lo que mejorará la eficiencia y la velocidad de desarrollo general.
¡Y aún más!
Estas fueron solo algunas de las nuevas características de la versión 12.6. Preste atención también al análisis de dependencias de proyectos Gradle en Java y soporte para squash-and-merge en las cadenas de solicitudes de fusión (en la localización rusa de "solicitudes de fusión" de GitLab).
El registro está abierto para la próxima conferencia de usuarios de GitLab Commit , que tendrá lugar el 14 de enero en San Francisco.
Lo invitamos a nuestras reuniones , a GitLab Commit y le pedimos que complete una encuesta sobre el lanzamiento (en inglés).
Fabio introdujo varias solicitudes de fusión importantes en 12.6: la capacidad de desactivar la notificación de grupo , mostrar la diferencia en la cobertura de prueba en la página de solicitud de fusión , agregar paginación en lanzamientos y soporte para Unify Circuit .
¡Gracias Fabio y todo el equipo de Siemens!
Características clave del lanzamiento de GitLab 12.6
Evaluación rápida de riesgos del proyecto con evaluaciones de seguridad
(ULTIMATE, GOLD) Etapa del ciclo DevOps: "Seguro"
Nos complace presentar una nueva función en el panel de seguridad del grupo: la evaluación de seguridad. Además de la lista existente de vulnerabilidades e historial, esta nueva parte del panel de seguridad muestra qué proyectos están actualmente en riesgo, para que pueda saltar inmediatamente a proyectos que requieren atención inmediata.
La vulnerabilidad de las vulnerabilidades detectadas afectará la evaluación resultante: de A a F. Los proyectos se agruparán de acuerdo con estas evaluaciones, lo que facilitará ver la distribución de proyectos sin problemas de seguridad actuales (grado A) a aquellos con al menos 1 vulnerabilidad crítica (grado F).
Documentación del panel de seguridad grupal y boleto original .
Administrar paquetes C / C ++ a través de Conan usando el registro de paquetes GitLab
(PREMIUM, ULTIMATE, SILVER, GOLD) Etapa del ciclo DevOps: "Paquete"
Para las compañías de software, es importante tener una forma simple y segura de administrar las dependencias. Las herramientas de administración de paquetes, como Conan para desarrolladores de C / C ++, proporcionan una forma estandarizada de distribuir bibliotecas y administrar sus versiones entre proyectos. En la versión 12.6, nos complace proporcionar soporte de repositorio de Conan integrado directamente en GitLab. Simplemente proporcione la dirección del servidor remoto de Conan al registro de paquetes de GitLab, e inmediatamente puede descargar, instalar y eliminar paquetes, así como publicar sus bibliotecas.
Documentación sobre el uso de Conan y el boleto original .
Filtrar tickets y fusionar solicitudes de lanzamiento
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Etapa del ciclo DevOps: "Release"
Planear y administrar lanzamientos no es tarea fácil. Es por eso que es tan importante la capacidad de encontrar entradas rápidamente y fusionar solicitudes relacionadas con el lanzamiento. En 12.6, agregamos el filtrado de tickets y solicitudes de fusión por nombre de lanzamiento, lo que lo ayudará a encontrar rápidamente tickets relacionados y solicitudes de fusión.
Buscar documentación y boleto original .
Cree automáticamente materiales de lanzamiento para auditoría
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Etapa del ciclo DevOps: "Release"
En muchas empresas, cuando se lanzan nuevos cambios, es necesario documentar el cumplimiento de todos los procesos y ajustes necesarios en el ciclo de vida del desarrollo de software. A menudo, este proceso es ineficiente y requiere mucho tiempo. A partir de 12.6, la colección Evidence apareció en las versiones de GitLab, donde encontrará una instantánea de todos los metadatos de la versión en formato JSON. Esta instantánea se puede utilizar para procesos de revisión y confirmación de cumplimiento, por ejemplo, para auditoría.
Documentación de los materiales de lanzamiento y el boleto original .
Historial combinado de confirmación de fusión y fusión en la cadena de solicitud de fusión
(PREMIUM, ULTIMATE, SILVER, GOLD) Etapa del ciclo DevOps: "Release"
Squash-and-Merge le permite recopilar todos los commits de su solicitud de fusión en uno para que tenga un historial ordenado en la rama predeterminada, y hacerlo sin perder todo el historial de commits. En esta versión, agregamos soporte de squash a las solicitudes de cadena de fusión que ejecutan la compilación en función del resultado de la solicitud de fusión antes de que se complete, asegurándose de que la rama maestra permanezca verde. La combinación de estas dos características proporcionará una rama maestra en funcionamiento y un historial unificado de confirmaciones.
Documentación sobre transportadores basada en la solicitud de fusión y el boleto original .
Ver la configuración de seguridad y cumplimiento en un solo lugar
(ULTIMATE, GOLD) Etapa del ciclo DevOps: "Seguro"
Nos complace presentar una nueva forma de ver los escaneos de seguridad desde la barra de navegación izquierda. En la sección
Tenga en cuenta que esta es solo la primera iteración (MVC) de esta función, por lo que todavía no está disponible una configuración más compleja, por ejemplo, no puede habilitar o deshabilitar los escaneos desde esta pantalla.
Solicitud de documentación de verificación de seguridad y boleto original .
Trabaja de manera más eficiente con Circuit
(CORE, ARRANQUE, PREMIUM, ULTIMATE, FREE, BRONZE, PLATA, ORO) "Activación"
Unify Circuit es un sistema de comunicación y colaboración utilizado por muchas organizaciones. Al igual que con otras integraciones de alertas de GitLab, ahora puede configurar enlaces web para enviar alertas específicas a una conversación de Circuit. Los enlaces en las alertas lo llevarán a su proyecto en GitLab, eliminando la necesidad de cambiar a su cliente de correo electrónico para obtener actualizaciones sobre la actividad en GitLab.
Gracias a Fabio Huser por esta contribución .
Documentación del circuito y boleto original
Otras mejoras en GitLab 12.6
Requisitos para nuevas contraseñas de usuario
(CORE, STARTER, PREMIUM, ULTIMATE) Etapa del ciclo DevOps: "Administrar"
Las organizaciones necesitan una forma de asegurar sus instancias de GitLab de acuerdo con los procedimientos y reglamentos internos. Parte de este trabajo es la seguridad de contraseña. GitLab actualizó recientemente sus guías de contraseñas basadas en el NIST SP 800-63B . En esta publicación, NIST recomienda establecer la longitud de la contraseña y los requisitos de complejidad, pero no recomienda la rotación de la contraseña o los requisitos de complejidad específicos (por ejemplo, un cierto número de caracteres especiales).
En base a esto, GitLab presenta una nueva configuración en el panel de administración: la longitud mínima de la contraseña , que se aplicará a las nuevas contraseñas, es decir, actuará en nuevas cuentas o al cambiar la contraseña. Con esto, GitLab se volverá más seguro y las organizaciones podrán administrar la política de contraseñas en sus instancias, asegurando el cumplimiento de los requisitos internos.
Documentación sobre la limitación de la longitud de las contraseñas y el ticket original .
Requisito de actualización de token personal
(ULTIMATE) Etapa del ciclo DevOps: "Administrar"
Las organizaciones centradas en la seguridad siempre han usado cambios regulares de credenciales para limitar el tiempo de acceso al sistema en caso de que los datos se vean comprometidos. Aunque las pautas de organizaciones como NIST ya no recomiendan cambios periódicos, seguimos agregando la posibilidad de personalizar el requisito de actualizaciones periódicas de tokens personales . Esto puede ser necesario debido a la falta inicial de protección de dos factores, los requisitos del usuario o la importancia de cambiar para algunos marcos que aseguran el cumplimiento de estándares, como PCI .
Gracias a esta característica, el administrador de la instancia puede configurar la vida útil de los tokens de acceso personal generados. La aplicación del límite expirará automáticamente todos los tokens actuales, deberán regenerarse y la vida útil especificada se aplicará a los nuevos tokens. Cuando caduque, el token deberá generarse nuevamente.
Documentación para limitar la vida útil de los tokens y el boleto original .
Protección de datos del proyecto con eliminación reversible
(PREMIUM, ULTIMATE, SILVER, GOLD) Etapa del ciclo DevOps: "Administrar"
Hasta ese momento, eliminar un proyecto a través de una interfaz de usuario o API era inmediato e irreversible, sin la capacidad de recuperar datos. Esto podría conducir a la pérdida involuntaria de datos, lo que sería un escenario peor para los desarrolladores.
Para mitigar los riesgos con la versión 12.6, presentamos una eliminación reversible del proyecto. En lugar de eliminar inmediatamente un proyecto o grupo, se marcarán para su eliminación y se eliminarán después del número configurado de días de eliminación reversible. Por defecto, esto sucederá después de 7 días. Si desea dejar la eliminación inmediata, cambie el valor de este parámetro a 0.
Documentación sobre el período de eliminación reversible y el boleto original .
Vista previa de las especificaciones de OpenAPI
(NÚCLEO, ARRANQUE, PREMIUM, ULTIMATE, FREE, BRONZE, PLATA, ORO) Etapa del ciclo DevOps: "Crear"
La especificación OpenAPI (anteriormente Swagger) es un estándar popular para crear interfaces RESTful. Sin embargo, leer el código fuente de YAML no es tan fácil. En el lanzamiento de GitLab 12.6, al visualizar el archivo openapi.yml u otro archivo compatible, la vista previa de la especificación se dibujará de la misma forma que en Swagger.
¡Gracias a Roger Meier y Siemens por esta contribución !
Vista previa de la documentación para las especificaciones de OpenAPI y el boleto original .
Navegación simplificada entre pestañas en solicitudes de fusión
(NÚCLEO, ARRANQUE, PREMIUM, ULTIMATE, FREE, BRONZE, PLATA, ORO) Etapa del ciclo DevOps: "Crear"
La interfaz de solicitud de fusión es donde se revisa, prueba y discute el código, pero esta interfaz se puede sobrecargar fácilmente. Las descripciones de solicitudes de fusión, las canalizaciones y los resultados del análisis de seguridad pueden empujar las pestañas hacia abajo en la página, lo que dificulta su acceso.
En la nueva versión de GitLab, la navegación de solicitud de fusión ahora está por encima de la descripción, y puede ir directamente a los cambios. También agrupamos la descripción y los widgets en la pestaña Descripción general , lo que facilitará la navegación a través de la solicitud de fusión. Por favor envíe sus comentarios sobre esta actualización aquí .
Fusionar la solicitud de documentación y un ticket original .
Eliminar ramificaciones mientras se restringe la visibilidad del proyecto
(NÚCLEO, ARRANQUE, PREMIUM, ULTIMATE, FREE, BRONZE, PLATA, ORO) Etapa del ciclo DevOps: "Crear"
Las ramas simplifican el trabajo en cualquier proyecto. Realiza una copia del proyecto principal en el que puede trabajar y luego crea una solicitud de fusión para realizar los cambios en el proyecto.
Anteriormente, cuando la visibilidad del proyecto raíz en la red de sucursales cambiaba a limitada, la visibilidad de todas las sucursales también se limitaba. Esto podría llevar al hecho de que todas las bifurcaciones de un proyecto público se cierran repentinamente si limita la visibilidad del proyecto raíz.
En GitLab 12.6, en lugar de cambiar la visibilidad de todos los proyectos, el proyecto raíz simplemente se elimina de la red de sucursales, dejando sin cambios todos los demás proyectos, lo que equivale a eliminar el proyecto raíz.
Documentación sobre la restricción de visibilidad y el boleto original .
Configurar CI fuera del repositorio
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Etapa del ciclo DevOps: "Verificar"
.gitlab-ci.yml la capacidad de establecer la ruta a .gitlab-ci.yml como una URL arbitraria, lo que le permite almacenar la configuración de CI fuera del repositorio que está creando actualmente. Ahora, para configurar múltiples repositorios de la misma manera, simplemente puede proporcionar un enlace al mismo .gitlab-ci.yml externo .gitlab-ci.yml . La eficiencia aumenta debido al hecho de que en lugar de admitir muchas configuraciones separadas, es suficiente actualizar solo un archivo de configuración. Los usuarios que usan servicios que generan dinámicamente un archivo de configuración también se beneficiarán de esta característica.
También le permite proteger la configuración de cambios no autorizados, ya que el archivo de configuración se puede almacenar en el proyecto con una restricción de acceso más restrictiva. Hemos actualizado nuestra documentación agregando información sobre cómo hacer esto.
Documentación sobre la configuración de la ruta al archivo de configuración de CI y el ticket original .
El registro NPM ahora admite la instalación de dependencias
(PREMIUM, ULTIMATE, SILVER, GOLD) Etapa del ciclo DevOps: "Paquete"
Nos complace informarle que a partir de GitLab 12.6, el registro NPM admite la instalación de dependencias de paquetes. Anteriormente, el npm install no funcionaba si la versión del paquete no estaba incluida en el comando. Además, este comando no admitía la instalación de dependencias de paquetes porque no admitíamos los metadatos de NPM requeridos, como las dependencias y las etiquetas.
Con esta versión, la instalación de GitLab npm install funcionará como se esperaba. A continuación, planeamos trabajar para agregar dependencias y etiquetas a la interfaz de usuario del registro de paquetes .
Documentación de metadatos del registro NPM y ticket original .
El contenedor oficial de GitLab con AWS preinstalado
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Etapa del ciclo DevOps: "Release"
Interactuar con uno de los proveedores de servicios en la nube más grandes, como AWS, Azure o GCP, es un componente clave de muchas canalizaciones. Sin embargo, antes de poder automatizar las operaciones en la nube, debe configurar su entorno con todas las herramientas que necesita. Tenía que hacer esto usted mismo antes, pero a partir de la versión 12.6, GitLab proporcionará una imagen oficial de AWS Docker que le permitirá ejecutar comandos aws desde sus canalizaciones de CI / CD. Puede acceder a muchos servicios de AWS utilizando la imagen de Docker, que el equipo de GitLab mantiene y actualiza.
Una imagen oficial es también el primer paso para admitir las implementaciones de AWS en EC2 . Uno de nuestros planes globales es agregar soporte nativo para implementaciones en la nube de varios proveedores . Esperamos ver a la comunidad contribuir al desarrollo de soporte para proveedores de nube adicionales. Para hacer esto, puede usar este modelo de imágenes preensambladas con scripts incluidos, que se almacena en el registro oficial de GitLab Cloud Deploy .
Documentación de implementación en la nube y ticket original .
Advertencia de fuera de cola
(PREMIUM, ULTIMATE, SILVER, GOLD) Etapa del ciclo DevOps: "Release"
Cuando los usuarios seleccionan la opción "Fusionar inmediatamente" para sus solicitudes de fusión, todas las solicitudes de fusión en la cola se retrasan. Los usuarios pueden no ser conscientes de que esto está sucediendo y pueden inadvertidamente interferir entre sí. Ahora, aunque todavía permitimos que las solicitudes de fusión urgentes se salgan de turno, como una línea de defensa adicional, hemos agregado una advertencia que explica que esta acción afectará otras solicitudes de fusión.
Combinar la documentación de la cadena y el boleto original .
Configurar el espacio de nombres de Kubernetes para cada entorno
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Etapa de bucle DevOps: "Configurar"
Cuando utiliza la integración de GitLab con Kubernetes, obtiene un espacio de nombres generado automáticamente que sirve como objetivo de implementación para GitLab CI / CD. Esto facilita comenzar con Kubernetes. Sin embargo, si ya tiene un clúster con un conjunto existente de espacios de nombres, lo más probable es que desee especificar uno de estos espacios de nombres como destino para implementar GitLab.
Con GitLab 12.6, puede establecer un espacio de nombres personalizado para cada entorno de CI en un .gitlab-ci.yml , que le permite implementar en espacios que existían incluso antes de conectar su clúster Kubernetes a GitLab. De forma predeterminada, esta función está disponible solo para clústeres sin autogestión, pero admite entornos dinámicos (por ejemplo, para su uso en aplicaciones de revisión).
Documentación de configuración de implementación de Kubernetes y ticket original .
Eliminación de caché de clúster para admitir sincronización
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Etapa de bucle DevOps: "Configurar"
A menudo tenemos que realizar acciones en los clústeres de Kubernetes directamente, por ejemplo, para la resolución de problemas o el ajuste fino. Cambiar los recursos de Kubernetes directamente en el clúster puede conducir a la finalización de la sincronización de GitLab con el clúster, y dejará de volver a crear los recursos, ya que supondrá que ya existen.
A partir de GitLab 12.6, aparecerá una opción para borrar la memoria caché local del espacio de nombres y las cuentas de servicio en la integración de Kubernetes, lo que permitirá que el próximo trabajo de CI los vuelva a crear si es necesario.
Documentación de limpieza de caché de clúster y ticket original .
Instalar aplicaciones Kubernetes usando la plantilla CI
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Etapa de bucle DevOps: "Configurar"
La instalación de aplicaciones Kubernetes con GitLab CI proporciona una excelente manera de personalizar sus gráficos Helm antes de la instalación. Para simplificar el inicio, hemos agregado una plantilla de CI con todas las aplicaciones compatibles actualmente. Además, creamos un ejemplo de un proyecto de administración de clúster que contiene todo lo que necesita para comenzar. Simplemente importe y copie este proyecto para obtener todas las últimas versiones de las aplicaciones compatibles.
Documentación de instalación a través de GitLab CI y el ticket original .
Integración mejorada entre el seguimiento de errores y la gestión de tickets
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Etapa de bucle de DevOps: "Monitor"
Los errores de clasificación pueden ser un trabajo lento, que a menudo involucra a varios miembros de su equipo. Un participante puede identificar el error como crítico y crear un ticket para solucionarlo. Comenzando con GitLab 12.6 desde la página con información detallada, por error, puede ir al ticket abierto para ello. Por lo tanto, será obvio de inmediato si necesita crear un ticket para este error.
Si todavía no hay un ticket, puede crearlo rápidamente a partir del error generado desde la página de error.
Documentación en la página de información de errores y el ticket original .
Bucle DevOps: "Monitor"] ( https://about.gitlab.com/stages-devops-lifecycle/monitor/ )
Gestionar Centinela a través de GitLab
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Etapa de bucle de DevOps: "Monitor"
Si usa el seguimiento de errores de GitLab, entonces probablemente sea importante que se integre con Sentry, la herramienta de seguimiento de errores más popular. Comenzando con GitLab 12.6, si no puede usar el proyecto Sentry en Sentry.io, puede implementar Sentry directamente en el clúster de Kubernetes adjunto a su proyecto o grupo. Esto simplifica enormemente comenzar con el seguimiento de errores en GitLab.
Documentación para instalar Sentry a través de GitLab CI y el ticket original .
Acceso a registros de hogar en la pestaña de operaciones
(ULTIMATE, GOLD) Etapa del ciclo DevOps: "Monitor"
Anteriormente, no había una manera fácil de ir directamente a ver los registros de sus hogares. Para hacer esto, tenía que ir a la pestaña Entornos en el elemento Operaciones , seleccionar el entorno deseado y hacer clic en el que se encuentra debajo. Ahora, en GitLab 12.6, navegar por los registros del hogar ahora es más fácil que nunca. Haga clic en la pestaña Registros de pod en Operaciones .
Documentación de registro de hogar de Kubernetes , boleto original y epopeya original .
Mejora del escaneo de dependencias para proyectos de Python
(ULTIMATE, GOLD) Etapa del ciclo DevOps: "Seguro"
Si sus dependencias de Python no están almacenadas en requirements.txt , sino en algún otro archivo, entonces, comenzando con GitLab 12.6, puede establecer el archivo de dependencia a través de la variable PIP_REQUIREMENTS_FILE .
Documentación de variables disponibles y el ticket original .
Soporte SAST para el marco React (JavaScript)
(ULTIMATE, GOLD) Etapa del ciclo DevOps: "Seguro"
Si tiene proyectos escritos utilizando el marco JavaScript React, ahora puede usar nuestros escaneos SAST para buscar problemas de seguridad.
Documentación de los idiomas y marcos compatibles y el ticket original .
Escaneo de dependencias para proyectos Scala usando el administrador de paquetes sbt
(ULTIMATE, GOLD) Etapa del ciclo DevOps: "Seguro"
En GitLab 12.6, agregamos soporte para Scala con el administrador de paquetes sbt en el escaneo de dependencias. Ahora puede escanear proyectos en Scala para buscar posibles vulnerabilidades.
Documentación de idiomas admitidos y gestores de paquetes y el ticket original .
Posibilidad de editar ganchos web grupales
(CORE, ARRANQUE, PREMIUM, ULTIMATE, FREE, BRONZE, PLATA, ORO) "Activación"
Los ganchos web grupales ahora se pueden editar. Anteriormente, solo podía crearlos y eliminarlos, por lo que para cambiarlos tenía que eliminar un enlace web existente y crear uno nuevo. En esta versión, agregamos la capacidad de editar enlaces web a través de la interfaz de usuario, lo que le ahorrará tiempo y esfuerzo al trabajar con ellos.
Documentación sobre configuraciones de grupo avanzadas , ticket original y solicitud de fusión .
Comentarios desactivados en las entradas de Jira
(CORE, ARRANQUE, PREMIUM, ULTIMATE, FREE, BRONZE, PLATA, ORO) "Activación"
Cuando un usuario tiene habilitada la integración de GitLab con Jira , los comentarios se publican en Jira cuando se produce actividad en GitLab. Esta actualización permitirá a los usuarios deshabilitar estos comentarios para una integración específica en la página de configuración.
Esto será conveniente para los usuarios que no desean ver comentarios, pero desean agregar automáticamente tickets de Jira a los proyectos de GitLab. Además, hay posibles escenarios de uso en los que hay usuarios de Jira que no deberían tener acceso a la actividad en el repositorio debido a su confidencialidad. En ambos casos, deberá ajustar el contenido de estos mensajes.
Documentación para deshabilitar los comentarios sobre los tickets de Jira , el ticket original y la solicitud de fusión .
Ordenar miembros del grupo por usuarios agregados directamente
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Etapa de bucle de DevOps: "Administrar"
Hay dos formas de acceder a un proyecto o grupo privado:
a) puede ser agregado a un proyecto o grupo específico directamente
b) puede heredar el acceso de un grupo superior .
GitLab 12.6 facilitó la comprensión de cómo un usuario obtuvo acceso a un proyecto o grupo, gracias a un filtro para ordenar la tabla de participantes por usuarios agregados directamente o por usuarios con derechos heredados.
Esto es especialmente útil para grupos con usuarios externos o instancias que usan grupos para notificar a los equipos .
Documentación sobre usuarios con derechos de acceso heredados y el ticket original .
SSH
(ULTIMATE) DevOps: "Manage"
GitLab . , , . , , .
, MVC PAT SSH. , , . , , .
.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) DevOps: "Plan"
. , , -.
@fh1ch Siemens!
, - .
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) DevOps: "Create"
: , - . . , .
GitLab 12.1 , , . GitLab 12.6 ( ) objects/info/alternates , .
Brian Kabiro !
.
-
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) DevOps: "Create"
, «Merge» , , ( ). . GitLab 12.6 - , .
- .
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD) DevOps: "Verify"
GitLab 12.0 , - .
GitLab 12.6 , .
.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) DevOps: "Verify"
, . ( ) , , .
.
API
(PREMIUM, ULTIMATE, SILVER, GOLD) DevOps: "Package"
GitLab API , , . API , , .
GitLab 12.6 API, .
API .
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) DevOps: "Release"
GitLab 12.6 API GitLab. .
.
(PREMIUM, ULTIMATE, SILVER, GOLD) DevOps: "Release"
userID . staging ( ), , , .
.
Kubernetes
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) DevOps: "Configure"
, , , ( , , . .) . , .
GitLab , .
.
Auto DevOps
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) DevOps: "Configure"
Auto DevOps Helm chart. .gitlab/auto-deploy-values.yaml , Auto DevOps . HELM_UPGRADE_EXTRA_ARGS .
Auto DevOps .
Cloud Run Anthos Kubernetes GKE
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) DevOps: "Configure"
Kubernetes GitLab GKE «Cloud Run on Anthos» . GKE Knative, Istio HTTP, Cloud Run . - , GitLab Serverless Knative .
. Cloud Run Anthos GitLab 12.4, - . , .
.
Knative 0.9
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) DevOps: "Configure"
GitLab 12.6 Knative GitLab 0.9. Knative. Knative Serving API v1 , beta alpha - . API, .
.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) DevOps: "Monitor"
. , , . GitLab 12.6 .
.
/
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) DevOps: "Monitor"
, — , . GitLab 12.6, Sentry GitLab, , .
.
PHP
(ULTIMATE, GOLD) DevOps: "Secure"
PHP , (License Compliance). , . PHP, composer ( composer.lock ).
.
Gradle- Java
(ULTIMATE, GOLD) DevOps: "Secure"
Gradle Java .
.
SAST Kubernetes
(ULTIMATE, GOLD) DevOps: "Secure"
Kubernetes , , kubesec .
SAST .
SAST
(ULTIMATE, GOLD) DevOps: "Secure"
, , SAST, .
SAST .
- CI
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) "Enablement"
CI, . Jenkins, Packagist, Team City, DroneCI, Buildkite Bamboo. , .
, , , , . , ( !).
CI , - .
GitLab Puma ( )
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) "Enablement"
GitLab , Unicorn Puma . Puma , GitLab 30%.
Puma , , Puma 13.0. .
Puma .
release notes / : GitLab 12.6 released with Security Scorecard and Release Evidence .
cattidourden , maryartkey , ainoneko rishavant .