Detección rápida de filtraciones de secretos
Parece ser un pequeño error: transmitir accidentalmente credenciales a un repositorio compartido. Sin embargo, las consecuencias pueden ser graves. Una vez que un atacante obtenga tu contraseña o clave de API, tomará control de tu cuenta, te bloqueará y usará tu dinero de manera engañosa. Además, puede haber un efecto dominó: el acceso a una cuenta abre el acceso a otras. Las apuestas son altas, por lo que es crucial enterarse de una filtración de secretos lo antes posible.
En esta versión presentamos la opción dentro de nuestra funcionalidad SAST. Cada commit se escanea en la tarea CI/CD en busca de secretos. Si hay un secreto, el desarrollador recibe una advertencia en la solicitud de fusión. En ese momento, revoca las credenciales filtradas y crea nuevas.
Aseguramiento de una gestión de cambios adecuada
A medida que crece y se complica, es cada vez más difícil mantener la coherencia entre las diferentes partes de la organización. Cuantos más usuarios haya en la aplicación y mayor sea el ingreso, más serias serán las consecuencias de fusionar código incorrecto o inseguro. Para muchas organizaciones, garantizar un proceso de revisión adecuado antes de la fusión del código es un requisito crítico, ya que los riesgos son muy altos.
En GitLab 11.9 hay más control y una estructura más eficiente, gracias a . Anteriormente, para obtener aprobación, solo era necesario indicar a una persona o grupo (cada miembro del cual podía otorgar la aprobación). Ahora se pueden agregar múltiples reglas para que la solicitud de fusión requiera aprobación de personas específicas o incluso de varios miembros de un grupo específico. Además, las reglas de aprobación están integradas con la función Code Owners, que permite identificar fácilmente a la persona que otorgó la aprobación.
Esto permite a las organizaciones implementar procesos de aprobación complejos mientras mantienen la simplicidad de la única aplicación GitLab, donde tareas, código, pipelines y datos de monitoreo son visibles y accesibles para la toma de decisiones y la aceleración del proceso de aprobación.
ChatOps ahora tiene código abierto
GitLab ChatOps es una herramienta de automatización efectiva que permite realizar cualquier trabajo CI/CD y solicitar su estado directamente en aplicaciones de chat como Slack y Mattermost. , ChatOps formaba parte de la suscripción GitLab Ultimate. Basándonos en y , a veces trasladamos características hacia abajo y nunca hacia arriba.
En el caso de ChatOps, entendimos que esta funcionalidad podría ser útil para todos y que la participación de la comunidad podría beneficiar la propia función.
En GitLab 11.9 abrimos , y así, ahora está disponible gratuitamente para su uso en GitLab Core autogestionado y en GitLab.com, y es abierto para la comunidad.
¡Y mucho más!
En esta versión hay tantas características geniales disponibles, por ejemplo, , y , ¡que no podemos esperar para contarte sobre ellas!
El empleado más valioso () de este mes es Marcel Amirault ()
Marcel nos ha ayudado constantemente a mejorar la documentación de GitLab. Él para mejorar la calidad y usabilidad de nuestros documentos. Domo arigato [¡muchas gracias (jap.) — nota del traductor!] Marcel, ¡lo apreciamos sinceramente!
Funciones clave añadidas en la versión de GitLab 11.9
Detección de secretos y credenciales en el repositorio
(ULTIMATE, GOLD)
Los desarrolladores a menudo transmiten involuntariamente secretos y credenciales a repositorios remotos. Si otras personas tienen acceso a esta fuente, o si el proyecto es público, entonces la información confidencial se divulga y puede ser utilizada por los delincuentes para acceder a recursos como entornos de despliegue.
GitLab 11.9 tiene una nueva prueba — "Detección de Secretos". Escanea el contenido del repositorio en busca de claves API y otra información que no debería estar ahí. GitLab muestra los resultados en el informe SAST en el widget de la solicitud de fusión, en los informes de pipelines y en los paneles de seguridad.
Si ya has habilitado SAST para tu aplicación, no necesitas hacer nada más, solo aprovecha esta nueva característica. También está incluida en la configuración por defecto.
Reglas de fusión de solicitudes
(PREMIUM, ULTIMATE, SILVER, GOLD)
La revisión de código es un elemento esencial de cada proyecto exitoso, pero no siempre está claro quién debe llevar a cabo la revisión de los cambios. A menudo, es deseable la participación de revisores de diferentes equipos: el equipo de desarrollo, el equipo de interacción con el usuario, el equipo de producción.
Las reglas de autorización permiten optimizar el proceso de interacción entre las personas involucradas en la revisión de código: se determina el grupo de personas autorizadas y la cantidad mínima de autorizaciones. Las reglas de autorización se muestran en el widget de la solicitud de fusión, lo que permite designar rápidamente al siguiente revisor.
En GitLab 11.8, las reglas de autorización estaban desactivadas por defecto. A partir de la versión GitLab 11.9, están disponibles por defecto. En GitLab 11.3 introdujimos la opción para designar a los miembros del equipo responsables de códigos específicos dentro del proyecto. La función Code Owners está integrada en las reglas de autorización, por lo que siempre se pueden encontrar rápidamente las personas adecuadas para revisar los cambios.
Moviendo ChatOps a Core
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Inicialmente introducido en GitLab Ultimate 10.6, ChatOps se ha trasladado a GitLab Core. GitLab ChatOps ofrece la posibilidad de ejecutar tareas de GitLab CI a través de Slack utilizando la función de .
Abrimos el código fuente de esta función de acuerdo con nuestro . Cuanto más se utilice, más contribuirá la comunidad.
Auditoría de parámetros de funciones
(PREMIUM, ULTIMATE, SILVER, GOLD)
Operaciones como agregar, eliminar o modificar parámetros de funciones ahora se registran en el registro de auditoría de GitLab, lo que le permite ver qué y cuándo se modificó. ¿Hubo un accidente y necesita ver qué cambió recientemente? ¿O simplemente necesita auditar cómo se han modificado los parámetros de las funciones? Ahora es muy fácil hacerlo.
Eliminación de vulnerabilidades de las solicitudes de fusión
(ULTIMATE, GOLD)
Para abordar rápidamente las vulnerabilidades del código, el proceso debe ser simple. Es importante simplificar las correcciones de seguridad, permitiendo a los desarrolladores centrarse en sus tareas principales. En GitLab 11.7, , pero tenía que ser cargado, aplicado a nivel local y luego los cambios movidos al repositorio remoto.
En GitLab 11.9, este proceso está automatizado. Corrija las vulnerabilidades sin salir de la interfaz web de GitLab. La solicitud de fusión se crea directamente desde la ventana de información sobre vulnerabilidades, y esta nueva rama ya contendrá la solución. Después de verificar si el problema se ha resuelto, añada la corrección a la rama original, si la canalización está en orden.
Visualización de resultados de escaneo de contenedores en el panel de seguridad del grupo
(ULTIMATE, GOLD)
El panel de seguridad del grupo permite a los especialistas centrarse en los asuntos más importantes para el trabajo, proporcionando una visión clara y detallada de todas las posibles vulnerabilidades que podrían afectar a las aplicaciones. Por eso es importante que el panel contenga toda la información necesaria en un solo lugar y permita a los usuarios examinar los datos en detalle antes de abordar las vulnerabilidades.
En GitLab 11.9, los resultados del escaneo de contenedores se han añadido al panel de control, además de los resultados ya existentes de SAST y escaneo de dependencias. Ahora toda la revisión está en un solo lugar, sin importar la fuente del problema.
Plantillas de CI/CD para trabajos de seguridad
(ULTIMATE, GOLD)
Las funciones de seguridad de GitLab están evolucionando rápidamente y requieren actualizaciones constantes para mantener la eficiencia y protección del código. Cambiar la definición del trabajo es complicado cuando gestionas varios proyectos. Y entendemos que arriesgarse a usar la última versión de GitLab sin estar seguro de su plena compatibilidad con la instancia actual de GitLab no es algo que nadie quiera.
Es por esta razón que hemos presentado en GitLab 11.7 un nuevo mecanismo para definir trabajos mediante .
A partir de GitLab 11.9, ofreceremos plantillas integradas para todos los trabajos de seguridad: por ejemplo, sast y dependency_scanning, compatibles con la versión correspondiente de GitLab.
Inclúyelos directamente en tu configuración, y se actualizarán junto con el sistema en cada actualización a una nueva versión de GitLab. Las configuraciones de la canalización no cambian.
La nueva forma de definir trabajos de seguridad es oficial y no admite ninguna otra definición de trabajos anteriores o fragmentos de código. Se debe actualizar la definición lo antes posible para utilizar la nueva palabra clave
template. La compatibilidad con cualquier otra sintaxis puede eliminarse en GitLab 12.0 o en otras versiones futuras.
Otras mejoras en GitLab 11.9
Respuesta a comentario
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
En GitLab hay discusiones sobre temas. Hasta ahora, el usuario que escribe el comentario inicial tenía que decidir desde el principio si quería una discusión.
Hemos relajado esta restricción. Toma cualquier comentario en GitLab (sobre tareas, merge requests y épicos) y respóndelo, iniciando así la discusión. De esta manera, los equipos interactúan de manera más organizada.
Plantillas de proyectos para .NET, Go, iOS y Pages
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Para facilitar a los usuarios la creación de nuevos proyectos, ofrecemos varias nuevas plantillas de proyectos:
- Inicial , que incluye una aplicación básica con CI.
- Plantilla lista para usar que combina y GitLab CI/CD.
- , lista para la personalización inicial en GitLab. Ten en cuenta que, dado que se requiere un runner dedicado MacOS para compilar iOS, tendrás que proporcionar tu propio servidor de compilación si deseas usarlo con GitLab CI/CD.
- están configuradas para funcionar con Netlify.
Requiere aprobación de merge requests de los Code Owners
(PREMIUM, ULTIMATE, SILVER, GOLD)
No siempre es obvio quién aprueba un merge request.
Ahora GitLab admite la exigencia de aprobar el merge request, según los archivos que modifica la solicitud, mediante . Los Code Owners se asignan mediante un archivo llamado CODEOWNERS, el formato es similar a gitattributes.
El soporte para la designación automática de los Code Owners como responsables de aprobar el merge request se agregó en .
Mover archivos en Web IDE
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Ahora, al renombrar un archivo o carpeta, se puede mover desde Web IDE al repositorio en una nueva ruta.
Etiquetas en orden alfabético
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Las etiquetas de GitLab son increíblemente versátiles, y los equipos constantemente encuentran nuevas aplicaciones para ellas. En consecuencia, los usuarios a menudo añaden muchas etiquetas a una tarea, merge request o épico.
En GitLab 11.9 hemos simplificado un poco el uso de etiquetas. En tareas, merge requests y épicos, las etiquetas que se muestran en la barra lateral están en orden alfabético. Esto también se aplica a la visualización de la lista de estos objetos.
Comentarios rápidos al filtrar acciones por tarea
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Recientemente introdujimos una función que permite a los usuarios filtrar el feed de actividades por tareas, merge requests o épicas, lo que facilita centrarse únicamente en los comentarios o notas del sistema. Esta configuración se guarda para cada usuario en el sistema, y a veces puede suceder que un usuario no entienda que, al revisar una tarea varios días después, está viendo un feed filtrado. Puede parecerle que no es posible dejar un comentario.
Hemos mejorado esta interacción. Ahora los usuarios pueden cambiar rápidamente al modo que permite dejar comentarios sin tener que desplazarse de nuevo hasta la parte superior del feed. Esto se aplica a tareas, merge requests y épicas.
Cambio del orden de las épicas secundarias
(ULTIMATE, GOLD)
Recientemente lanzamos , que permiten utilizar épicas de épicas (además de las tareas secundarias de las épicas).
Ahora puedes cambiar el orden de las épicas secundarias simplemente arrastrándolas, al igual que con las tareas secundarias. Los equipos pueden usar el orden para reflejar prioridades o definir la secuencia de trabajo.
Mensajes del sistema personalizados en el encabezado y pie de página en la web y el correo electrónico
(CORE, STARTER, PREMIUM, ULTIMATE)
Anteriormente añadimos una función que permite que los mensajes del sistema personalizados en el encabezado y pie de página aparezcan en cada página en GitLab. Fue bien recibida y los equipos la utilizan para compartir información importante: por ejemplo, mensajes del sistema relacionados con su instancia de GitLab.
Estamos encantados de introducir esta función en Core, así que ahora más personas pueden usarla. Además, permitimos a los usuarios mostrar opcionalmente los mismos mensajes en todos los correos electrónicos enviados a través de GitLab, para mantener la coherencia con otro punto de interacción del usuario con GitLab.
Filtro para tareas confidenciales
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Las tareas confidenciales son una herramienta útil para los equipos, permitiendo discutir temas delicados dentro de un proyecto abierto. En particular, son ideales para trabajar en vulnerabilidades de seguridad. Hasta ahora, gestionar las tareas confidenciales no ha sido demasiado fácil.
En GitLab 11.9, la lista de tareas de GitLab ahora se filtra por tareas confidenciales o no confidenciales. Esto también se aplica a la búsqueda de tareas a través de la API.
Agradecemos la contribución de Robert Schilling ()!
Edición de dominio Knative después del despliegue
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Especificar un dominio personalizado al instalar Knative permite servir diferentes aplicaciones/functions serverless con un punto final único.
Ahora, la integración de Kubernetes en GitLab permite modificar/actualizar el dominio personalizado después del despliegue de Knative en el clúster de Kubernetes.
Verificación del formato del certificado CA de Kubernetes
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Al agregar un clúster existente de Kubernetes, GitLab ahora verifica que el certificado CA ingresado tenga un formato PEM válido. Esto evita posibles errores en la integración de Kubernetes.
Ampliación de la utilidad de comparación de merge requests a todo el archivo
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Al revisar los cambios en un merge request, ahora puedes ampliar la utilidad de comparación para cada archivo para mostrar el archivo completo para mayor contexto y dejar comentarios en las líneas inalteradas.
Ejecutando trabajos específicos por merge requests solo al cambiar ciertos archivos
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
En GitLab 11.6 se añadió la capacidad de definir para trabajos en pipelines, de modo que los usuarios puedan ejecutar tareas específicas solo al crear un merge request.
Ahora estamos ampliando esta funcionalidad: se ha añadido la lógica de conexión , y los usuarios pueden ejecutar trabajos específicos solo para merge requests y solo al cambiar ciertos archivos.
Gracias por la contribución de Hiroyuki Sato ()!
Monitoreo automático de GitLab con Grafana
(CORE, STARTER, PREMIUM, ULTIMATE)
Grafana ahora forma parte de nuestro paquete Omnibus, lo que facilita la comprensión del funcionamiento de tu instancia.
Configura grafana['enable'] = true en gitlab.rb, y Grafana estará disponible en: https://your.gitlab.instance/-/grafana. En un futuro cercano también «listo para usar».
Visualización de epics primarios en la barra lateral de epics
(ULTIMATE, GOLD)
Recientemente presentamos , que permite el uso de epics de epics.
En GitLab 11.9 hemos simplificado el mecanismo para visualizar esta relación. Ahora se puede ver no solo el epic padre de un epic dado, sino todo el árbol de epics en la barra lateral derecha. Se puede ver si estos epics están cerrados o no, e incluso puedes acceder directamente a ellos.
Enlace a una nueva tarea desde una tarea movida y cerrada
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
En GitLab, puedes mover fácilmente una tarea a otro proyecto utilizando la barra lateral o acción rápida. Tras bambalinas, la tarea existente se cierra y se crea una nueva tarea en el proyecto de destino con todos los datos copiados, incluidas las notas del sistema y los atributos de la barra lateral. Es una gran característica.
Dado que existe una nota del sistema sobre el movimiento, los usuarios, al revisar la tarea cerrada, se sienten confusos: no pueden entender que la tarea se cerró debido a su traslado.
En esta versión, indicamos directamente en el icono en la parte superior de la página de la tarea cerrada que ha sido movida, e incluimos un enlace integrado a la nueva tarea, para que cualquiera que acceda a la antigua pueda dirigirse rápidamente a la nueva.
Integración de YouTrack
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab se integra con muchos sistemas externos de seguimiento de tareas, lo que facilita a los equipos el uso de GitLab para otras funciones, manteniendo la herramienta de gestión de tareas que han elegido.
En esta versión, hemos añadido la capacidad de integración de YouTrack de JetBrains.
Gracias a Kotau Yauhen por su contribución ()!
Redimensionamiento del árbol de archivos del merge request
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Al revisar los cambios de un merge request, ahora se puede redimensionar el árbol de archivos para mostrar nombres de archivos largos o ahorrar espacio en pantallas pequeñas.
Acceso a paneles de tareas recientes
(STARTER, PREMIUM, ULTIMATE, BRONCE, PLATA, ORO)
Los paneles de tareas son muy útiles, y los equipos crean varios paneles para cada proyecto y grupo. Recientemente hemos añadido un panel de búsqueda para filtrar rápidamente todos los paneles que te interesan.
En GitLab 11.9, también introdujimos la sección Reciente en el menú desplegable. Así puedes acceder rápidamente a los paneles con los que has interactuado recientemente.
Capacidad de los desarrolladores para crear ramas protegidas
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Las ramas protegidas no permiten mover o fusionar código que no ha sido revisado. Sin embargo, si nadie tiene permiso para mover ramas protegidas, entonces nadie puede crear una nueva rama protegida: por ejemplo, una rama de lanzamiento.
En GitLab 11.9, los desarrolladores pueden crear ramas protegidas a partir de ramas ya protegidas a través de GitLab o API. El uso de Git para mover una nueva rama protegida sigue estando limitado, para evitar la creación accidental de nuevas ramas protegidas.
Desduplicación de objetos Git para ramas abiertas (Beta)
(CORE, STARTER, PREMIUM, ULTIMATE)
La ramificación permite que cualquier persona participe en proyectos de código abierto: sin necesidad de permisos de escritura, solo copiando el repositorio a un nuevo proyecto. Almacenar copias completas de repositorios de Git que se ramifican frecuentemente no es eficiente. Ahora, con Git alternativas las ramas comparten objetos comunes del proyecto superior en el grupo de objetos para reducir los requisitos de almacenamiento en disco.
Los grupos de objetos para ramas se crean solo para proyectos abiertos, si se conecta un almacenamiento hasheado. Los grupos de objetos se habilitan mediante el parámetro de función object_pools.
Filtrado de la lista de merge requests por revisores asignados
(STARTER, PREMIUM, ULTIMATE, BRONCE, PLATA, ORO)
La revisión de código es una práctica común en cualquier proyecto exitoso, pero a veces es complicado para el revisor rastrear los merge requests.
En GitLab 11.9, la lista de merge requests se filtra por el revisor asignado. De esta manera, puedes encontrar merge requests que se te hayan asignado como revisor.
Agradecemos la contribución de Glavin Wiechert ()!
Atajos de teclado para el siguiente y anterior archivo en el merge request
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Al revisar los cambios en el merge request, puedes alternar rápidamente entre archivos usando ]o j para ir al siguiente archivo y [ o k para regresar al archivo anterior.
Simplificación .gitlab-ci.yml para proyectos serverless
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Creada a partir de la funcionalidad de GitLab CI, la plantilla serverless gitlab-ci.yml ha sido significativamente simplificada. Para introducir nuevas funciones en futuras versiones, no es necesario modificar este archivo.
Soporte para nombres de host Ingress
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Durante el despliegue del controlador Kubernetes Ingress, algunas plataformas regresan a la dirección IP (por ejemplo, GKE de Google), mientras que otras utilizan el nombre DNS (por ejemplo, EKS de AWS).
Nuestra integración de Kubernetes ahora admite ambos tipos de endpoints para mostrarse en la sección clusters del proyecto.
Agradecemos la contribución de Aaron Walker ()!
Restricción de acceso a JupyterHub solo para miembros del grupo/proyecto
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Desplegar JupyterHub mediante la integración de GitLab con Kubernetes es una excelente manera de administrar y usar Jupyter Notebook en grandes grupos. También es útil controlar el acceso a ellos al manejar datos confidenciales o personales.
En GitLab 11.9, el acceso a instancias de JupyterHub desplegadas a través de Kubernetes está limitado a los participantes del proyecto con nivel de acceso “desarrollador” (a través de grupo o proyecto).
Intervalos de tiempo personalizables para el esquema del panel de seguridad
(ULTIMATE, GOLD)
El panel de seguridad del grupo incluye un esquema de vulnerabilidades para revisar el estado de seguridad actual de los proyectos del grupo. Esto es muy útil para los directores de seguridad al configurar procesos y comprender cómo trabaja el equipo.
En GitLab 11.9, ahora se puede seleccionar el intervalo de tiempo de este esquema de vulnerabilidades. De forma predeterminada, son los últimos 90 días, pero se puede establecer un intervalo de 60 o 30 días, dependiendo del nivel de detalle necesario.
Esto no afecta los datos en los contadores o en la lista, solo a los puntos de datos que se muestran en el esquema.
Agregar un trabajo de compilación Auto DevOps para etiquetas
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
La etapa de compilación automática de Auto DevOps crea una compilación de tu aplicación utilizando el Dockerfile del proyecto o el paquete de compilación de Heroku.
En GitLab 11.9, la imagen de Docker generada, incrustada en el pipeline de etiquetas, recibe un nombre similar a los nombres tradicionales de las imágenes utilizando la etiqueta de commit en lugar del SHA de commit.
¡Gracias por la contribución de Aaron Walker!
Actualización de Code Climate a la versión 0.83.0
(STARTER, PREMIUM, ULTIMATE, BRONCE, PLATA, ORO)
GitLab utiliza para verificar cómo los cambios afectan el estado de tu código y proyecto.
En GitLab 11.9, hemos actualizado el motor a la última versión (), para ofrecer ventajas de un lenguaje adicional y soporte de análisis estático para la Calidad del Código de GitLab.
¡Gracias por la contribución del miembro del equipo de GitLab Core Takuya Noguchi ()!
Escalado y desplazamiento del panel de métricas
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Cuando investigas anomalías de rendimiento, a menudo es útil examinar más de cerca partes específicas de una métrica determinada.
Con GitLab 11.9, los usuarios podrán escalar períodos de tiempo individuales en el panel de métricas, desplazarse por todo el intervalo de tiempo y volver fácilmente a la vista del intervalo de tiempo original. Esto permite investigar eventos relevantes de manera rápida y sencilla.
SAST para TypeScript
(ULTIMATE, GOLD)
es un lenguaje de programación relativamente nuevo basado en .
En GitLab 11.9, la función de Análisis de Seguridad de Aplicaciones Estáticas (SAST) analiza y detecta vulnerabilidades en el código TypeScript, mostrándolas en el widget de la solicitud de fusión, a nivel de pipeline y en el panel de seguridad. La definición actual del trabajo sast no necesita ser alterada, y también se activa automáticamente en .
SAST para proyectos Maven de múltiples módulos
(ULTIMATE, GOLD)
Los proyectos Maven a menudo están organizados para reunir en un solo repositorio. Anteriormente, GitLab no podía escanear correctamente tales proyectos, y los desarrolladores y especialistas en seguridad no recibían informes sobre vulnerabilidades.
GitLab 11.9 ofrece un soporte mejorado para la función SAST para esta configuración específica del proyecto, permitiendo probarlos en busca de vulnerabilidades en su estado original. Gracias a la flexibilidad de los analizadores, la configuración se determina automáticamente, y no es necesario cambiar nada para ver los resultados en aplicaciones Maven de múltiples módulos. Como de costumbre, mejoras similares también están disponibles en el marco de .
GitLab Runner 11.9
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Hoy también lanzamos GitLab Runner 11.9. GitLab Runner es un proyecto de código abierto que se utiliza para ejecutar trabajos de CI/CD y enviar los resultados de vuelta a GitLab.
A continuación se presentan algunos cambios en GitLab Runner 11.9:
- .
- y .
- . Esto también .
- para soportar , que aparecerá en GitLab 11.10.
- .
- .
- Moviendo múltiples scripts, incluyendo y — a Go.
- .
- .
- .
La lista completa de cambios se puede encontrar en el registro de cambios de GitLab Runner: .
Mejoras en el esquema de GitLab
(CORE, STARTER, PREMIUM, ULTIMATE)
En el gráfico de GitLab se han realizado las siguientes mejoras:
- Se añadió soporte para Google Cloud Memorystore.
- Las configuraciones de Cron job , ya que son utilizados por varios servicios.
- El registro se ha actualizado a la versión 2.7.1.
- Se ha añadido un nuevo parámetro que asegura la compatibilidad del registro de GitLab con versiones de Docker anteriores a 1.10. Para activarlo, establezca
registry.compatibility.schema1.enabled: true.
Mejoras de rendimiento
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Continuamos mejorando el rendimiento de GitLab con cada lanzamiento para instancias de GitLab de cualquier tamaño. Aquí hay algunas mejoras en GitLab 11.9:
- .
- .
- .
- .
Mejoras de Omnibus
(CORE, STARTER, PREMIUM, ULTIMATE)
Las siguientes mejoras de Omnibus se han realizado en GitLab 11.9:
- GitLab 11.9 incluye , , cuya última versión incluye MFA para Team Edition, rendimiento mejorado de imágenes y mucho más. Esta versión también incluye ; se recomienda la actualización.
- Se ha añadido un nuevo parámetro que asegura la compatibilidad del registro de GitLab con versiones de Docker anteriores a 1.10. Para activarlo, establezca
registry['compatibility_schema1_enabled'] = true en gitlab.rb. - El registro de GitLab ahora exporta métricas de Prometheus y se controla automáticamente mediante .
- Se ha añadido soporte para Google Cloud Memorystore, que requiere .
opensslactualizado a la versión 1.0.2r,nginx— a la versión 1.14.2,python— a la versión 3.4.9,jemalloc— a la versión 5.1.0,docutils— a la versión 0.13.1,gitlab-monitor— a la versión 3.2.0.
Características obsoletas
GitLab Geo proporcionará almacenamiento hash en GitLab 12.0
GitLab Geo requiere para mitigar la competencia (race condition) en nodos secundarios. Esto se ha indicado en .
En GitLab hemos añadido este requisito en la documentación de Geo: .
En GitLab sudo gitlab-rake gitlab: geo: check verifica si el almacenamiento hash está habilitado y si todos los proyectos están migrando. Consulte. . Si está utilizando Geo, por favor, ejecute esta verificación y migre lo antes posible.
En GitLab advertencia permanentemente deshabilitada se mostrará en la página Área de administración › Geo › Nodos, si las verificaciones mencionadas no están permitidas.
En GitLab Geo utilizará los requisitos de almacenamiento hash. Consulte. .
Fecha de eliminación: 22 de junio de 2019.
Integración de Hipchat
Hipchat . Además, en la versión 11.9 .
Fecha de eliminación: 22 de marzo de 2019.
Soporte para CentOS 6 para GitLab Runner usando Docker executor
GitLab Runner no soporta CentOS 6 cuando se utiliza Docker en GitLab 11.9. Esto es resultado de la actualización de la biblioteca base de Docker, la cual ya no soporta CentOS 6. Para más detalles, consulte .
Fecha de eliminación: 22 de marzo de 2019.
Rutas obsoletas de código legacy de GitLab Runner
A partir de GitLab 11.9, GitLab Runner utiliza de clonación/llamada al repositorio. Actualmente, GitLab Runner usará el método antiguo si el nuevo no está soportado.
En GitLab 11.0, cambiamos la configuración del servidor de métricas para GitLab Runner. metrics_server será eliminado en favor de listen_address en GitLab 12.0. Para más detalles, consulte . Y más información en .
En la versión 11.3, GitLab Runner comenzó a soportar , lo que condujo a nuevas configuraciones para . Hay se proporciona una tabla de cambios e instrucciones para la transición a la nueva configuración. Para más detalles, consulte .
Estas rutas ya no están disponibles en GitLab 12.0. Como usuario, no necesita cambiar nada, solo asegúrese de que la instancia de GitLab esté funcionando con la versión 11.9+ al actualizar a GitLab Runner 12.0.
Fecha de eliminación: 22 de junio de 2019.
Parámetro obsoleto para la característica de punto de entrada para GitLab Runner
En 11.4, GitLab Runner presentó el parámetro de característica para solucionar problemas como y .
En GitLab 12.0, cambiaremos al comportamiento adecuado, como si el parámetro de característica estuviera desactivado. Para más detalles, consulte .
Fecha de eliminación: 22 de junio de 2019.
Soporte obsoleto para distribuciones de Linux que alcanzaron EOL, para GitLab Runner
Algunas distribuciones de Linux donde se puede instalar GitLab Runner han llegado al final de su vida útil.
En GitLab 12.0, GitLab Runner ya no distribuirá paquetes a estas distribuciones de Linux. La lista completa de distribuciones ya no soportadas se puede encontrar en nuestra . Gracias a Javier Ardó () por su !
Fecha de eliminación: 22 de junio de 2019.
Eliminación de viejas comandos de GitLab Runner Helper
Como parte de los esfuerzos para soportar se tuvieron que eliminar algunos viejos comandos que se utilizan para .
En GitLab 12.0, GitLab Runner se ejecuta con nuevos comandos. Esto solo afecta a los usuarios que sobrescriben . Para más detalles, consulte .
Fecha de eliminación: 22 de junio de 2019.
Los desarrolladores pueden eliminar etiquetas de Git en GitLab 11.10
La eliminación o edición de notas de versión para etiquetas de Git en ramas no protegidas se ha limitado históricamente solo a .
Dado que los desarrolladores pueden añadir etiquetas y también modificar y eliminar ramas no protegidas, los desarrolladores deben tener la capacidad de eliminar etiquetas de Git. En GitLab 11.10 en nuestro modelo de permisos para mejorar el flujo de trabajo y ayudar a los desarrolladores a usar etiquetas de manera más eficiente.
Si desea mantener esta restricción para mantenedores y propietarios, utilice .
Fecha de eliminación: 22 de abril de 2019.
Soporte para Prometheus 1.x en Omnibus GitLab
A partir de GitLab , la versión integrada de Prometheus 1.0 se elimina de Omnibus GitLab. . Sin embargo, el formato de métricas no es compatible con la versión 1.0. Las versiones existentes se pueden actualizar a 2.0 y, si es necesario, trasladar los datos .
En las versiones de GitLab se instalará automáticamente Prometheus 2.0, si no se han realizado actualizaciones. Los datos de Prometheus 1.0 se perderán, ya que no se migrarán.
Fecha de eliminación: 22 de junio de 2019.
TLS v1.1
A partir de GitLab para aumentar la seguridad. Esto resuelve múltiples problemas, incluyendo Heartbleed, y hace que GitLab sea compatible 'out of the box' con el estándar PCI DSS 3.1.
Para desactivar inmediatamente TLS v1.1, configure nginx['ssl_protocols'] = "TLSv1.2" en gitlab.rband y ejecute gitlab-ctl reconfigure.
Fecha de eliminación: 22 de junio de 2019.
Plantilla de OpenShift para instalar GitLab
Oficial — el método recomendado para ejecutar GitLab en Kubernetes, incluyendo .
para instalar GitLab ha quedado obsoleta y no será compatible en .
Fecha de eliminación: 22 de junio de 2019.
Las definiciones de trabajos de seguridad anteriores
Con la introducción de cualquier definición de trabajos anterior quedará obsoleta y será eliminada en GitLab 12.0 o posterior.
Actualice las definiciones de trabajos para utilizar la nueva sintaxis y aprovechar todas las nuevas características de seguridad que ofrece GitLab.
Fecha de eliminación: 22 de junio de 2019.
La sección de Información del Sistema en el panel de administración
GitLab presenta información sobre su instancia de GitLab en admin/system_info, pero esta información puede no ser precisa.
Nosotros del panel de administración en GitLab 12.0 y recomendamos utilizar .
Fecha de eliminación: 22 de junio de 2019.
Fuente: habr.com
