GitLab 11.10 con pipelines en el panel de control, pipelines para resultados combinados y sugerencias para varias líneas en las solicitudes de fusión.
Información útil sobre el rendimiento de los pipelines en diferentes proyectos.
GitLab continúa aumentando la transparencia del ciclo de vida de DevOps. En esta versión, se ha añadido un resumen del estado de los pipelines.
Es conveniente, incluso si estás explorando el pipeline de un solo proyecto, pero especialmente útil si – que es lo habitual cuando utilizas microservicios y quieres lanzar un pipeline para probar y desplegar código desde varios repositorios de proyectos. Ahora puedes ver inmediatamente el rendimiento , donde quiera que se estén ejecutando.
Ejecutar pipelines para resultados combinados.
Con el tiempo, la rama de origen y la rama de destino se desvían, y puede surgir una situación en la que por separado funcionan, pero juntas no. Ahora es posible Así podrás detectar rápidamente errores que solo aparecerían con el movimiento frecuente de cambios entre ramas, lo que significa que corregirás los errores del pipeline mucho más rápido y utilizarás .
Más optimización para la colaboración.
En GitLab 11.10 hay aún más funciones para facilitar la colaboración y simplificar los flujos de trabajo. En la introdujimos sugerencias en las solicitudes de fusión, donde el revisor podía proponer un cambio de una línea en el comentario de la solicitud de fusión, que podía ser comiteado de inmediato desde el hilo de comentarios. A nuestros usuarios les gustó esto y pidieron ampliar esta función. Ahora puedes sugerir indicando qué líneas eliminar y cuáles agregar.
¡Gracias por sus comentarios y sugerencias!
Y esto no es todo...
Esta versión tiene tantas funciones increíbles, como una limpieza más rigurosa del , y la posibilidad de A continuación, más detalles sobre cada una de ellas.
El empleado más valioso de este mes () es Takuya Noguchi.
Este mes, el empleado más valioso ha sido Takuya Noguchi (). Takuya : corregía errores, completaba tareas pendientes en el backend y frontend y mejoraba la interfaz de usuario. ¡Gracias!
Funciones principales de GitLab 11.10
Pipelines en el panel de control
PREMIUM, ULTIMATE, SILVER, GOLD
En el panel de control de GitLab se muestran detalles sobre los proyectos en toda la instancia de GitLab. Puedes agregar proyectos individuales uno por uno y elegir cuál te interesa.
En esta versión, hemos añadido información sobre los estados de los pipelines en el panel de control. Ahora los desarrolladores pueden ver el estado de los pipelines en todos los proyectos necesarios, todo en una sola interfaz.
Pipelines para resultados combinados
PREMIUM, ULTIMATE, SILVER, GOLD
Normalmente, con el tiempo, la rama de origen se desvía de la rama objetivo si no se mueven constantemente los cambios entre ellas. Como resultado, los pipelines de la rama de origen y la rama objetivo estarán ‘verdes’ y no habrá conflictos de fusión, pero la fusión fallará debido a la incompatibilidad de los cambios.
Cuando un pipeline de merge requests crea automáticamente un nuevo enlace que contiene el resultado combinado de la fusión de la rama de origen y la rama objetivo, podemos ejecutar el pipeline a través de este enlace y garantizar que el resultado combinado funcione.
Si utilizas pipelines de merge requests (de cualquier tipo) y empleas GitLab runners privados de version 11.8 o anteriores, debes actualizarlos para evitar problemas. . Esto no afecta a los usuarios de GitLab runners públicos.
Propuesta de cambios en varias líneas
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Al colaborar en merge requests, a menudo notas problemas y propones soluciones. Desde la versión 11.6 de GitLab, apoyamos la para una línea.
En la versión 11.10, en los comentarios del diff del merge request, puedes proponer cambios para varias líneas, y luego cualquier usuario con permisos de escritura en la rama de origen puede aceptarlos con un solo clic. Gracias a esta nueva función, puedes evitar el copiar y pegar, como sucedía en versiones anteriores.
Etiquetas en una misma área
PREMIUM, ULTIMATE, SILVER, GOLD
Con etiquetas en una misma área, los equipos pueden aplicar etiquetas excluyentes (en la misma área) a una tarea, merge request o épico en escenarios con campos personalizados o estados de flujo de trabajo personalizados. Se configuran utilizando una sintaxis especial con dos puntos en el encabezado de la etiqueta.
Supongamos que necesita un campo personalizado en las tareas para rastrear el sistema operativo de la plataforma a la que se dirigen sus funciones. Cada tarea debe estar asociada solo a una plataforma. Se pueden crear etiquetas platform::iOS, platform::Android, platform::Linux y otras según sea necesario. Si se aplica una de estas etiquetas a una tarea, automáticamente se eliminará otra etiqueta existente que comience con platform::.
Supongamos que tiene etiquetas workflow::development, workflow::review y workflow::deployed, que representan el estado del flujo de trabajo en su equipo. Si una tarea ya tiene una etiqueta workflow::development, y el desarrollador desea cambiar la tarea a la etapa workflow::review, simplemente aplica una nueva etiqueta, y la antigua (workflow::development) se elimina automáticamente. Este comportamiento ya existe cuando mueve tareas entre listas de etiquetas en el tablero de tareas, que representa el flujo de trabajo de su equipo. Ahora, los miembros del equipo que no trabajan directamente con el tablero de tareas pueden cambiar el estado del flujo de trabajo dentro de las propias tareas.
Limpieza más exhaustiva del registro de contenedores
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Con el uso habitual del registro de contenedores con CI pipelines, envía varios cambios individuales en una sola etiqueta. Debido a la implementación de la distribución de Docker, el comportamiento predeterminado es conservar todos los cambios en el sistema, pero, al final, ocupan mucha memoria. Si utiliza la opción -m con registry-garbage-collect, puede eliminar rápidamente todos los cambios anteriores y liberar valioso espacio.
Compra de minutos adicionales de CI Runner
BRONZE, SILVER, GOLD
Los usuarios con planes pagos de GitLab.com (Gold, Silver, Bronze) ahora pueden comprar minutos adicionales de CI Runner. Antes, era necesario ajustarse a la cuota prevista por el plan. Con esta mejora, es posible comprar minutos por adelantado más allá de la cuota para evitar interrupciones en el trabajo debido a la detención de pipelines.
Actualmente, 1000 minutos cuestan 8 dólares, y se pueden comprar tantos como se desee. Los minutos adicionales comenzarán a gastarse una vez que haya utilizado toda la cuota mensual, y el saldo de minutos adicionales se traspasa al siguiente mes. En queremos añadir esta función también a los planes gratuitos.
Auto DevOps componible
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Con Auto DevOps, los equipos adoptan prácticas modernas de DevOps casi sin esfuerzo. A partir de GitLab 11.10, cada trabajo en Auto DevOps se presenta como . Los usuarios pueden utilizar en GitLab CI para incluir etapas específicas de Auto DevOps y al mismo tiempo utilizar su archivo personalizado gitlab-ci.yml. De esta manera se pueden incluir solo los trabajos necesarios y aprovechar las actualizaciones del upstream.
Gestión automática de miembros de grupo en GitLab.com mediante SCIM
SILVER, GOLD
Anteriormente, gestionar la membresía en grupos en GitLab.com tenía que hacerse manualmente. Ahora se puede utilizar SAML SSO y gestionar la membresía mediante SCIM para crear, eliminar y actualizar usuarios en GitLab.com.
Esto es especialmente útil para empresas con un gran número de usuarios y proveedores de identidades centralizados. Ahora puede tener una única fuente de verdad, como Azure Active Directory, y los usuarios se crearán y eliminarán automáticamente a través del proveedor de identidades, no manualmente.
Acceso a GitLab.com a través de un proveedor SAML
SILVER, GOLD
Anteriormente, al utilizar SAML SSO para grupos, el usuario debía iniciar sesión con sus credenciales de GitLab y con el proveedor de identidades. Ahora se puede acceder directamente a través de SSO como un usuario de GitLab vinculado al grupo configurado.
Los usuarios no tendrán que iniciar sesión dos veces, por lo que es más conveniente para las empresas utilizar SAML SSO para GitLab.com.
Otras mejoras en GitLab 11.10
Esquema de epics secundarios
ULTIMATE, GOLD
En la versión anterior, añadimos epics secundarios (epics de epics) para facilitar la gestión de la estructura de distribución de tareas. Los epics secundarios se muestran en la página del epic principal.
En esta versión, en la página del epic principal se muestra el esquema de epics secundarios, por lo que los equipos pueden ver la cronología de los epics secundarios y gestionar las dependencias temporales.
Ventanas emergentes de merge requests
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
En esta versión, presentamos pantallas informativas que aparecen al pasar el cursor sobre el enlace del merge request. Antes solo mostrábamos el título del merge request, y ahora también el estado del merge request, el estado del pipeline CI y una URL corta.
En futuras versiones, planeamos añadir más información importante, como , y también introduciremos ventanas emergentes para .
Filtrado de merge requests por ramas objetivo
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Los flujos de trabajo de Git para la liberación o entrega de software a menudo están asociados con varias ramas a largo plazo, como para realizar correcciones en versiones anteriores (por ejemplo, stable-11-9) o la transición de control de calidad a producción (por ejemplo, integration), pero no es tan fácil encontrar solicitudes de fusión para estas ramas entre las numerosas solicitudes de fusión abiertas.
Ahora se puede filtrar la lista de solicitudes de fusión para proyectos y grupos según la rama objetivo de la solicitud de fusión, para facilitar la búsqueda de la que se necesita.
Gracias, Hiroyuki Sato ()!
Envío y fusión en caso de pipeline exitoso
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Si utilizamos el método de desarrollo basado en Trunk, debemos evitar ramas de larga vida en favor de pequeñas ramas temporales con un solo propietario. Los cambios menores a menudo se envían directamente a la rama objetivo, pero corremos el riesgo de romper la compilación.
En esta versión, GitLab admite nuevos parámetros de envío a Git para abrir automáticamente solicitudes de fusión, establecer la rama objetivo y asegurar la fusión en caso de un pipeline exitoso desde la línea de comandos durante el envío a la rama.
Mejor integración con paneles de monitoreo externos
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
GitLab puede conectarse a múltiples servidores Prometheus (a nivel de entorno, proyecto y ), pero tener múltiples puntos finales puede complicar el sistema o no ser compatible con los paneles de monitoreo estándar. En esta versión, los equipos pueden utilizar una única API de Prometheus, lo que simplifica significativamente la integración con servicios como Grafana.
Ordenación de páginas Wiki por fecha de creación
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
En la Wiki del proyecto, los equipos pueden compartir documentación y otra información importante junto con el código fuente y las tareas. En esta versión, la lista de páginas en la Wiki se puede ordenar por fecha de creación y título para encontrar rápidamente el contenido recién creado.
Monitoreo de recursos solicitados por el clúster
ULTIMATE, GOLD
GitLab ayuda a monitorear el clúster de Kubernetes para aplicaciones en desarrollo y en producción. A partir de esta versión, sigue los recursos procesador y memoria solicitados por el clúster para detectar problemas potenciales antes de que se conviertan en un problema.
Visualización de métricas del balanceador de carga en el panel de Grafana
CORE, STARTER, PREMIUM, ULTIMATE
Es muy importante monitorear el funcionamiento de la instancia de GitLab. Anteriormente, proporcionábamos paneles de monitoreo predeterminados a través de una instancia integrada de Grafana. A partir de esta versión, hemos incluido paneles adicionales para monitorear los balanceadores de carga NGINX.
SAST para Elixir
ULTIMATE, GOLD
Continuamos expandiendo el soporte para lenguajes y profundizando las verificaciones de seguridad. En esta versión, hemos incluido verificaciones de seguridad para proyectos en y proyectos creados en .
Varias consultas en un solo gráfico
PREMIUM, ULTIMATE, SILVER, GOLD
En GitLab, puedes crear gráficos para visualizar las métricas recopiladas. A menudo, por ejemplo, si necesitas ver el valor máximo o el promedio de una métrica, querrás mostrar varios valores en un solo gráfico. A partir de esta versión, tienes esa posibilidad.
Resultados de DAST en el panel de seguridad del grupo
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Hemos agregado los resultados de las pruebas de seguridad de aplicaciones dinámicas (Dynamic Application Security Testing, DAST) al panel de seguridad del grupo, además de SAST, escaneos de contenedores y escaneos de dependencias.
Adición de metadatos al informe de escaneo de contenedores
ULTIMATE, GOLD
En esta versión, el informe de escaneo de contenedores contiene más metadatos: hemos agregado el componente afectado (característica de Clair) a los metadatos existentes: prioridad, identificador (con referencia a mitre.org) y nivel afectado (por ejemplo, debian:8).
Adición de un tipo de informe de métricas en las solicitudes de fusión
PREMIUM, ULTIMATE, SILVER, GOLD
GitLab ya proporciona varios tipos de informes que se pueden incluir directamente en las solicitudes de fusión: desde informes sobre y en la etapa de revisión hasta y en la etapa de protección.
Y aunque estos son informes importantes, también se necesitan datos básicos que sean adecuados para diferentes escenarios. En GitLab 11.10, proporcionamos informes de métricas directamente en la solicitud de fusión, que espera un simple par clave-valor. De este modo, los usuarios pueden rastrear los cambios a lo largo del tiempo, incluidas las métricas personalizadas, y los cambios en las métricas para una solicitud de fusión específica. El uso de memoria, las pruebas de cargas especializadas y los estados de disponibilidad se pueden transformar en métricas simples que se pueden ver directamente en las solicitudes de fusión junto con otros informes integrados.
Soporte para proyectos multimódulo de Maven para escaneo de dependencias
ULTIMATE, GOLD
En este lanzamiento, los proyectos multimódulo de Maven soportan el escaneo de dependencias de GitLab. Anteriormente, si un submódulo tenía una dependencia de otro submódulo del mismo nivel, no podía resolver la carga desde el repositorio central de Maven. Ahora, un proyecto multimódulo de Maven se crea con dos módulos y una dependencia entre ellos. La dependencia entre módulos del mismo nivel ahora está disponible en el repositorio local de Maven, permitiendo continuar con la construcción.
Los usuarios pueden cambiar la ruta para clonar en CI
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Por defecto, GitLab Runner clona el proyecto en una ruta anidada única en $CI_BUILDS_DIR. Pero para algunos proyectos, como Golang, es necesario clonar el código en un directorio específico para que pueda ser compilado.
En GitLab 11.10 introdujimos la variable GIT_CLONE_PATH, que permite especificar una ruta concreta donde GitLab Runner clona el proyecto antes de ejecutar el trabajo.
Enmascaramiento simple de variables protegidas en los registros
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
GitLab proporciona varias maneras de y de variables en GitLab CI/CD. Sin embargo, las variables aún pueden aparecer intencionalmente o accidentalmente en los registros de construcción.
GitLab toma en serio la gestión de riesgos y auditoría y sigue añadiendo funciones para cumplir con los requisitos. En GitLab 11.10 introdujimos la capacidad de enmascarar ciertos tipos de variables en los registros de trazado de trabajos, añadiendo un nivel de protección contra la exposición accidental del contenido de esas variables en los registros. Además, GitLab ahora muchas variables incorporadas de tokens.
Activación y desactivación de Auto DevOps a nivel de grupo
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Con Auto DevOps en un proyecto de GitLab.com, puedes abordar sin complicaciones los modernos flujos de trabajo de DevOps, desde la construcción hasta la entrega.
A partir de GitLab 11.10 puedes activar y desactivar Auto DevOps para todos los proyectos en un solo grupo.
Página de licencias simplificada y mejorada
STARTER, PREMIUM, ULTIMATE
Para gestionar las claves de licencia de manera más conveniente y sencilla, hemos rediseñado la página de licencias en el panel de administración y destacado los elementos más importantes.
Actualización del selector de etiquetas para implementaciones de Kubernetes
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
En los paneles de implementación se muestra información sobre todas las implementaciones de Kubernetes.
En este lanzamiento, cambiamos la forma de emparejar etiquetas con implementaciones. Ahora están disponibles las coincidencias por app.example.com/app y app.example.com/env o app. Esto permitirá evitar conflictos durante la filtración y el riesgo de implementaciones incorrectas relacionadas con el proyecto.
Además, en la versión GitLab 12.0 nosotros , y la coincidencia solo será posible por app.example.com/app y app.example.com/env.
Creación dinámica de recursos de Kubernetes
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
La integración de Kubernetes en GitLab permite utilizar la función RBAC con una cuenta de servicio y un espacio de nombres dedicado para cada proyecto de GitLab. A partir de este lanzamiento, para máxima eficacia, estos recursos serán creados solo cuando sean necesarios para la implementación.
Durante la implementación de Kubernetes, GitLab CI creará estos recursos antes de la implementación.
Runners grupales para clústeres a nivel de grupo
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Los clústeres a nivel de grupo ahora soportan la instalación de GitLab Runner. Los runners de Kubernetes a nivel de grupo se mostrarán para los proyectos hijos como runners grupales, etiquetados cluster y kubernetes.
Contador de llamadas para funciones Knative
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Las funciones desplegadas con , ahora muestran la cantidad de llamadas recibidas para cada función. Para esto, es necesario instalar Prometheus en el clúster donde está instalado Knative.
Control de parámetros git clean para trabajos de GitLab CI/CD
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Por defecto, GitLab Runner ejecuta git clean en el proceso de descarga de código al ejecutar un trabajo en GitLab CI/CD. A partir de GitLab 11.10, los usuarios pueden controlar los parámetros pasados al comando git clean. Esto es útil para equipos con runners dedicados, así como para equipos que compilan proyectos desde grandes monorepositorios. Ahora pueden gestionar el proceso de descarga antes de ejecutar los scripts. La nueva variable GIT_CLEAN_FLAGS por defecto tiene el valor -ffdx y acepta todos los parámetros posibles del comando [git clean](https://git-scm.com/docs/git-clean).
Autenticación externa en Core
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Los entornos protegidos pueden requerir un recurso externo adicional de autenticación para acceder al proyecto. Hemos añadido soporte para un nivel de control de acceso adicional en y hemos recibido muchas solicitudes para abrir esta funcionalidad en Core. Nos complace presentar la autenticación externa y un nivel adicional de seguridad para instancias de Core, dado que esta característica es necesaria para ciertos participantes.
Posibilidad de crear proyectos en grupos en Core
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
El rol de Developer puede crear proyectos en grupos , y ahora esto es posible también en Core. La creación de proyectos es una función clave para el trabajo productivo en GitLab, y con la inclusión de esta funcionalidad en Core, los participantes de la instancia ahora pueden embarcarse más fácilmente en algo nuevo.
GitLab Runner 11.10
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
¡Hoy hemos lanzado GitLab Runner 11.10! GitLab Runner es un proyecto de código abierto que se utiliza para ejecutar trabajos de CI/CD y enviar resultados nuevamente a GitLab.
Los cambios más interesantes:
- .
- .
- .
- .
- .
La lista completa de cambios se puede encontrar en el registro de cambios de GitLab Runner: .
Corrección del valor devuelto project_id en la API de búsqueda de blobs en Elasticsearch
STARTER, PREMIUM, ULTIMATE
Hemos corregido un error en la API de búsqueda de blobs en Elasticsearch que erróneamente devolvía 0 para project_id. Será necesario , para obtener valores correctos project_id después de instalar esta versión de GitLab.
Mejoras de Omnibus
CORE, STARTER, PREMIUM, ULTIMATE
Hemos realizado las siguientes mejoras en Omnibus en GitLab 11.10:
- GitLab 11.10 incluye , , cuya última versión incluye un catálogo de integración para una fácil migración de datos desde Hipchat y mucho más. Esta versión incluye , y recomendamos actualizar.
- Nosotros , y ahora comenzar a monitorear la instancia de GitLab es muy fácil.
- Hemos agregado soporte para eliminar imágenes de contenedores antiguas del registro de Docker.
- Hemos actualizado ca-certs a 2019-01-23.
Mejoras de rendimiento
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Seguimos mejorando el rendimiento de GitLab con cada lanzamiento para instancias de GitLab de cualquier tamaño. Algunas mejoras en GitLab 11.10:
- .
- .
- .
- .
- .
- .
- .
- .
Mejoras en los gráficos de GitLab
CORE, STARTER, PREMIUM, ULTIMATE
Hemos realizado las siguientes mejoras en los gráficos de GitLab:
- .
Características obsoletas
GitLab Geo proporcionará almacenamiento hash en GitLab 12.0
GitLab Geo requiere para mitigar la competencia en nodos secundarios. Esto se señaló 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.
Soporte para Ubuntu 14.04
GitLab 11.10 será la última versión con .
Canonical anunció el fin del soporte estándar para Ubuntu 14.04 desde . Recomendamos a los usuarios actualizar a una versión LTS soportada: Ubuntu 16.04 o Ubuntu 18.04.
Fecha de eliminación: 22 de mayo de 2019
Restricción del número máximo de pipelines generados por un solo envío
Antes GitLab generaba pipelines para HEAD cada rama en la solicitud. Esto es conveniente para los desarrolladores que envían múltiples cambios a la vez (por ejemplo, a una rama de función y a la develop).
Pero al enviar un gran repositorio con muchas ramas activas (por ejemplo, para mover, reflejar o bifurcar), no es necesario crear un pipeline para cada rama. A partir de GitLab 11.10, generamos al enviar.
Fecha de eliminación: 22 de mayo de 2019
Rutas obsoletas de código legacy de GitLab Runner
A partir de GitLab 11.9, GitLab Runner utiliza clonación/llamada al repositorio. Actualmente, GitLab Runner utilizará el método anterior si el nuevo no es soportado. Para más detalles, consulte .
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 .
En la versión 11.3, GitLab Runner comenzó a soportar ; lo que llevó a nuevas configuraciones para . Hay , se presenta una tabla de cambios e instrucciones para pasar a la nueva configuración. Para más detalles, consulte .
Estos caminos no estarán disponibles en GitLab 12.0. Como usuario, no necesita cambiar nada, solo asegúrese de que la instancia de GitLab esté ejecutándose en 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 !
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 inicia con nuevos comandos. Esto aplica solo a usuarios que . Para más detalles, consulte .
Fecha de eliminación: 22 de junio de 2019.
Eliminación del mecanismo heredado git clean de GitLab Runner
En GitLab Runner 11.10 configurar cómo el Runner ejecuta el comando git clean. Además, la nueva estrategia de limpieza elimina el uso de permite revertir cambios en los despliegues; siempre hay estados anteriores disponibles. y coloca el comando git clean después del paso de descarga.
Dado que este cambio de comportamiento puede afectar a algunos usuarios, hemos preparado un parámetro FF_USE_LEGACY_GIT_CLEAN_STRATEGY. Si se establece en true, restaurará la estrategia de limpieza heredada. Más sobre el uso de parámetros de funciones en GitLab Runner se puede encontrar .
En GitLab Runner 12.0 eliminaremos el soporte para la estrategia de limpieza heredada y la capacidad de restaurarla con el parámetro de función. Para más información, consulte .
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.
Registro de cambios
Busque todos estos cambios en el registro de cambios:
Instalación
Si está configurando una nueva instalación de GitLab, visite .
Actualización
Eche un vistazo a .
Planes de suscripción de GitLab
GitLab está disponible en dos versiones: y .
: localmente o en la plataforma en la nube de su elección.
- Core: para equipos pequeños, proyectos personales o la versión de prueba de GitLab sin límite de tiempo.
- Starter: para equipos que trabajan en una misma oficina en varios proyectos que necesitan soporte profesional.
- Premium: para equipos distribuidos que requieren funciones avanzadas, alta disponibilidad y soporte 24/7.
- Ultimate: para empresas que necesitan una estrategia sólida y una implementación con mayor seguridad y cumplimiento normativo.
— GitLab.com: alojado, administrado y gestionado por GitLab a través de para desarrolladores individuales y equipos.
- Gratis: repositorios privados ilimitados y número ilimitado de participantes en el proyecto. Los proyectos privados tienen acceso a funciones de nivel Gratis, mientras que los tienen acceso a funciones de nivel Gold.
- Bronce: para equipos que necesitan acceso a funciones avanzadas de flujo de trabajo.
- Plata: para equipos que requieren capacidades DevOps más robustas, cumplimiento normativo y soporte rápido.
- Gold: adecuado para múltiples trabajos CI/CD. Todos los proyectos públicos pueden utilizar gratuitamente las funciones Gold sin importar el plan.
Fuente: habr.com
