Código fuente sin servidor
GitLab fusiona todas las solicitudes de los usuarios individuales a nivel de usuario y crea automáticamente una aplicación de comentarios. Esta característica permite a cada usuario saber cómo ha cambiado el diseño o UX.
GitLab 12.0 agrega herramientas de revisión visual a la aplicación de revisión para ampliar las capacidades de revisión de cambios. Con un pequeño fragmento de código, los usuarios pueden permitir que los diseñadores, gerentes de productos y otro personal relevante brinden comentarios rápidamente sobre las solicitudes de fusión sin salir de la aplicación.
La nueva versión de Ultimate puede enumerar la lista de dependencias del proyecto (a veces llamada lista de materiales o BOM) en el menú de la barra lateral a la izquierda del proyecto.
La lista de materiales puede indicar qué componentes se incluyen en el proyecto y los equipos de seguridad y cumplimiento normalmente comprobarán estos componentes dependientes para garantizar que no haya problemas de seguridad. Puede explorar informes relacionados y admitir la exportación en formato JSON.
Restringir el acceso a la interfaz de Gitlab siempre ha sido una característica que se necesitaba con urgencia. En la nueva versión comercial, Gitlab admite restricciones de IP (segmentos) y agrega un mecanismo de lista negra para restringir el acceso a IP, haciéndolo más flexible. Puede crear su propia instancia y establecer límites a nivel de grupo. (Por supuesto, las restricciones de IP se pueden implementar a través de nginx. El método requiere contacto).
En GitLab 12.0, los cambios en el IDE web se pueden sincronizar automáticamente con el terminal web y los cambios se pueden probar en la terminal web antes del envío. Esta característica reduce la barrera de entrada para nuevos contribuyentes porque pueden ver, editar y probar el proyecto sin tener que instalar dependencias locales.
Implementar JupyterHub a través de la integración de Kubernetes de GitLab es una forma sencilla y cómoda de crear un entorno de portátil Jupyter. Con este entorno, puede crear y compartir código en vivo, visualizar y ejecutar archivos de libros futuros.
En GitLab 12.0, si JupyterHub se implementa en un clúster a través de GitLab y K8s, la extensión Git configurada con JupyterLab se instalará automáticamente. Luego, el entorno se versiona completamente a través de Git y los comandos de Git se ejecutan en Jupyter. Se puede ejecutar a través de la pestaña Git en el panel izquierdo o mediante la línea de comando de Jupyter.
Dividir contenido diferente en archivos diferentes mediante la palabra clave extends puede mantener limpio el archivo de configuración CI/CD del usuario. En GitLab 12.0, se puede permitir a los usuarios incluir múltiples extensiones en un solo trabajo para mejorar esta característica. Múltiples extensiones pueden lograr una configuración de CI limpia y simplificada (imprescindible para los administradores de Virgo).
GitLab 12.0 agrega la salida de los registros de expansión y colapso de trabajos de CI/CD de GitLab. Los usuarios pueden depurar más fácilmente algunos pasos de un trabajo y navegar por los pasos si es necesario.
Gitlab ha revelado el proyecto de base de datos de vulnerabilidades (/git lab-org/security-products/gemnasium-db). Los usuarios pueden ver entradas específicas y verificar vulnerabilidades de interés, y también permitir la participación del usuario en la mejora de la base de datos.
Las organizaciones que dependen de LDAP a menudo necesitan sincronizar la gestión de permisos con GitLab. En GitLab 12.0, las instancias pueden evitar que los no administradores con configuraciones a nivel de instancia realicen cambios de permisos fuera de LDAP.
De esta manera, las organizaciones que cumplen con los estándares pueden usar esta opción para garantizar que los permisos en LDAP se asignen a la instancia de GitLab y no puedan ser modificados por usuarios que no sean administradores de instancias.
GitLab Insights introducido en GitLab Ultimate 11.9 (indicadores de funciones) ahora está habilitado de forma predeterminada en GitLab Ultimate 12.0.
Puede recopilar estadísticas sobre datos importantes del proyecto, como problemas de creación/cierre dentro de un período de tiempo determinado, tiempo de fusión promedio de las solicitudes de fusión, etc.
La capacidad de que las operaciones de puentes ascendentes activen canalizaciones descendentes se introdujo en GitLab 11.8. También introduce soporte básico para pasar variables a tuberías posteriores. En GitLab 12.0, se agregó soporte para pasar variables de entorno actuales a canalizaciones posteriores. Se puede permitir a los usuarios proporcionar contexto para las canalizaciones posteriores y otros detalles sobre la confirmación, la solicitud de fusión o la canalización que desencadenó la solicitud.
En git lab 11.11, se lanza MVC basado en proxy, lo que permite a los usuarios descargar y almacenar en caché imágenes de Docker para lograr descargas más rápidas y confiables. En GitLab 12.0, esta función está habilitada de forma predeterminada a nivel de grupo.
La API Container Registration permite a los usuarios de GitLab gestionar fácilmente los registros mediante programación. El modelo de permisos se actualizó en GitLab 12.0 para permitir a los desarrolladores eliminar etiquetas.
En GitLab 12.0, cuando se vuelve a empaquetar un repositorio Git, la caché del mapa de bits se guardará en el índice del mapa de bits. El almacenamiento en caché mejora el rendimiento del reempaquetado. (Las versiones anteriores a JGit 3.5.0 no son compatibles con mapas de bits)
Antes de esta versión, la funcionalidad sin servidor de GitLab solo estaba disponible en Knative instalado a través de GitLab. GitLab Serverless utiliza Knative instalado en GitLab 12.0. Puede agregar manualmente un clúster Knative existente y agregar las plantillas sin servidor relevantes a su proyecto. Por lo tanto, GitLab Serverless se puede utilizar con productos Kennative alojados, como la nube de Google que se ejecuta en GKE o el servicio Kennative alojado de IBM.
A partir de GitLab 12.0, los paneles externos están disponibles directamente desde el panel del entorno de GitLab y son de fácil acceso.
El diseño existente para discutir solicitudes y problemas de fusión implica muchos cuadros y límites, y puede resultar difícil realizar un seguimiento de la conversación. En la nueva versión, esto se ha rediseñado para mejorar la experiencia de discusión para los usuarios.
Ya no es necesario ejecutar las pruebas dinámicas de seguridad de aplicaciones (DAST) en Docker. Por lo tanto, la imagen DAST Docker (3 GB) ahora se almacenará en caché en el ejecutor. (Tenga en cuenta que la imagen se actualiza semanalmente, por lo que el caché se invalidará todos los lunes).
En 12.0, se agregó la función de configurar un buzón de correo de notificación grupal. Puede permitir que los usuarios envíen notificaciones grupales a diferentes direcciones de correo electrónico. Por ejemplo, el correo electrónico de trabajo del grupo de trabajo y el correo electrónico personal del grupo personal (hay un menú de correo electrónico en el elemento de configuración personal para agregar direcciones de correo electrónico).
Al eliminar una vulnerabilidad encontrada por el escáner, se puede agregar un nuevo campo para proporcionar una explicación detallada del motivo de la eliminación de la vulnerabilidad.
Esto permitirá a los equipos de seguridad y desarrolladores ver el historial y comprender por qué los proyectos no se solucionaron.
Por motivos de auditoría, etc., es posible que desees asegurarte de que los proyectos (que pueden incluir código importante en el repositorio) solo puedan archivarse y no eliminarse ni perderse permanentemente. La nueva versión evita que los no administradores eliminen proyectos a través de la configuración a nivel de instancia.
A partir de GitLab 8.9, GitLab CI/CD admite la clonación superficial de GIT especificando la variable git_DEPTH en la definición del trabajo. La nueva versión agrega la función de establecer la profundidad de la clonación a nivel de proyecto, y los mantenedores del proyecto pueden establecer la clonación superficial de forma predeterminada. La clonación superficial de Git es más rápida que clonar todo el repositorio de Git a la vez.
Si el trabajo de CI/CD está configurado para crear el código más reciente, una clonación superficial suele ser suficiente.
También en GitLab 12.0, de forma predeterminada, el GIT_DEPTH de los nuevos proyectos en GitLab se establece en 50 cuando se crean. Esta configuración predeterminada ayudará a los usuarios a lograr tiempos de clonación y compilación más rápidos con GitLab CI/CD, y al mismo tiempo permitirá a los usuarios avanzados cambiar esta configuración si es necesario para diferentes tipos de casos de uso de CI/CD.
El flujo de trabajo Fork crea una copia que el usuario modifica y fusiona en el proyecto anterior, lo que facilita la aceleración de la colaboración y es una característica popular para Github y otros proyectos Git. Pero para un proyecto popular, puede haber miles de copias y almacenar estas copias consume muchos recursos del servidor.
En GitLab 12.0, los administradores de instancias pueden habilitar la deduplicación de objetos Git usando el indicador de función object_pools. Cuando está habilitado, la creación de una rama pública también creará un grupo de objetos y utilizará objetos/información/alternativos para reducir los requisitos de almacenamiento de la bifurcación. La deduplicación de objetos requiere que el proyecto principal habilite y utilice el almacenamiento hash. Las sucursales existentes no se han migrado automáticamente al grupo de objetos. En una próxima versión, las bifurcaciones rápidas se habilitarán mediante la creación de bifurcaciones directamente en un estado deduplicado. La versión actual también requiere crear primero una bifurcación y luego deduplicarla.
A partir del 30 de mayo de 2019, el servicio git en línea de GitLab ha habilitado la deduplicación de objetos. Cree su propia instancia, pero desactívela de forma predeterminada, ya que se mostrarán advertencias duplicadas cuando la obtenga.
Agregar manualmente un clúster de Kubernetes requiere múltiples puntos de datos y es propenso a errores. Para agregar manualmente un clúster para resolver problemas de acceso y permisos, el soporte de integración de Kubernetes verificará la accesibilidad de la URL de API y la validez del token del clúster y el certificado de CA.
En GitLab 12.0, es fácil colaborar con los miembros del equipo en cuestiones a través de reuniones de telecomunicaciones de Zoom. Pegue el enlace de la reunión en la descripción de la pregunta. GitLab detecta el enlace y muestra un botón "Unirse a la reunión de Zoom" en la parte superior, justo debajo del título, para que sea visible para todos los colaboradores.
Los usuarios pueden definir tareas dentro de las preguntas y esta información se mostrará en varias ubicaciones a lo largo de la aplicación. En GitLab 12.0, los usuarios pueden devolver información del progreso de la tarea a través de la API.
Los usuarios de versiones anteriores no pueden obtener estadísticas detalladas de problemas de la API de problemas. GitLab 12.0 agrega la función de devolver estadísticas de todos los problemas abiertos y cerrados.
Las mejoras de GitLab 12.0 a Omnibus incluyen:
Presentación de Mattermost 5.11, una alternativa de código abierto a Slack. Su última versión incluye una nueva herramienta CLI remota y más funciones. Esta versión también incluye actualizaciones de seguridad. Actualice a la nueva versión lo antes posible.
De forma predeterminada, el registro JSON está habilitado.
Omnibus-gitlab habilitará el servicio Grafana de forma predeterminada. Además, GitLab y Grafana ahora tienen la autenticación OAuth habilitada automáticamente.
Los indicadores de GitLab se han mejorado mediante el uso de algunos indicadores Ruby detectados directamente.
GitLab también lanzó GitLab Runner 12.0. Los principales cambios son los siguientes:
Compatibilidad con el asistente de credenciales de Docker;
Agregar configuración de nivel de acceso para los corredores al registrarse;
Permitir que Kubernetes Executor configure el contexto de seguridad del Pod;
Establece los valores predeterminados de PowerShell para los ejecutores de shell de Windows recién registrados;
Admite la configuración del volumen de la ventana acoplable de Windows.
Al mismo tiempo, Gitlab Runner versión 12.0 también elimina algunas cosas que se descartaron anteriormente:
Eliminar comandos de clonación/extracción obsoletos.
Eliminar la política de limpieza de git obsoleta.
Eliminar la compatibilidad con la configuración obsoleta metrics_server.
Eliminar la compatibilidad con la configuración de punto de entrada obsoleta para K8S.
Eliminar la compatibilidad con la configuración de caché S3 obsoleta.
Eliminar el soporte para distribuciones obsoletas.
Eliminar el antiguo comando de imagen auxiliar de Docker
Puede encontrar una lista de todos los cambios en CHANGELOG de GitLab Runner.
Algunas mejoras de rendimiento en GitLab 12.0 incluyen:
El rendimiento del sistema de páginas de lista de Epics se puede optimizar en gran medida.
Evite acceder a la base de datos para obtener resultados de Elasticsearch y evite hacer clic dos veces en Elasticsearch para obtener resultados de búsqueda.
Enviar documentos en lotes al índice ElasticSearch;
El caché representa Markdown en el mensaje de envío para mejorar el rendimiento del envío de la lista;
Aumentar el tamaño del repositorio de cada pulsación Limite el rendimiento de las comprobaciones;
Mejore el rendimiento al cargar problemas o solicitudes de combinación con descripciones largas;
Mejore el rendimiento de las solicitudes de combinación con cambios recomendados;
Al empaquetar repositorios de Git, utilizamos delta Island para mejorar el rendimiento y reducir la utilización de CPU de los clones.
Mejorar el rendimiento de los gráficos de seguimiento;
Corregir git n 1 en ListLastCommit RPC;
Utilizar -perl-regexp para mejorar el rendimiento de la búsqueda de código Git;
p>
Mejora del rendimiento de JobsController con correcciones para Git N 1;
Versión de mantenimiento importante de GitLab que elimina la compatibilidad con GitLab 9.x en este caso. La versión mínima admitida aumenta a GitLab 10.0.
Fecha de inicio: 2065 438 22 de junio de 2009
En GitLab 12.0, GitLab Geo requiere el uso de almacenamiento hash para mitigar la contención en nodos secundarios. Utilice "sudo git lab -rake git lab:geo:check" para comprobar si el almacenamiento hash está habilitado y si se han migrado todos los proyectos.
Fecha de migración: 2065 438 22 de junio de 2009
En GitLab 12.0, Geo requiere un contenedor de datos externo para PostgreSQL, elevando la versión mínima de PostgreSQL a 9.6. GitLab Geo utiliza contenedores de datos externos de PostgreSQL para consultar datos de diferentes instancias de PostgreSQL. Esto es necesario para los cursores de registro geográfico y puede mejorar significativamente el rendimiento de ciertas operaciones de sincronización. El contenedor de datos externos también mejora el rendimiento de las consultas de estado de los nodos geográficos. Para proyectos grandes, las consultas heredadas tienen un rendimiento inaceptable.
Fecha de migración: 2065 438 22 de junio de 2009
En GitLab 12.1, se eliminará la etiqueta de aplicación que coincide con el selector de implementación de Kubernetes (el plan original era eliminarla en 12.0) . Como parte de GitLab 11.10, GitLab introdujo un nuevo mecanismo de coincidencia para mostrar implementaciones en el tablero de implementación usando app.gitlab.com/app y app.gitlab.com/env. Para ver estas implementaciones en el tablero de implementación, simplemente presione la nueva implementación y GitLab la implementará con la nueva etiqueta.
Fecha de eliminación: 2065 438 22 de junio de 2009
Se introdujeron nuevas variables de entorno de dominio básico de entrada de KUBE en GitLab 11.8. Ya no necesita usar AUTO_DEVOPS_DOMAIN para definir múltiples dominios, ya que ahora puede definir estos dominios individualmente en la página del clúster.
Fecha de eliminación: 2065 438 22 de junio de 2009
Está previsto eliminar la plantilla de servicio Kubernetes a nivel de instancia en GitLab 12.1 para admitir la función de clúster a nivel de instancia introducida en GitLab 11. .
Como parte de la actualización a GitLab 12.0, cualquier instancia de GitLab autoconstruida que utilice plantillas de servicio se migrará a clústeres a nivel de instancia.
Fecha de eliminación: 2065 438 22 de junio de 2009
En GitLab 12.0, se eliminó por completo la compatibilidad con archivos skip_auto_migrations. Este archivo ha quedado obsoleto en GitLab 10.6.
Fecha de eliminación: 2065 438 22 de junio de 2009
GitLab 12.0 elimina por completo el soporte para Prometheus 1.x
Fecha de eliminación:2065 438 22 de junio de 2009
OpenSUSE 42.3 caducará el 30 de junio de 2019. Gitlab dejará de ser compatible en 12.2.
Fecha de eliminación: 2065 438 22 de agosto de 2009
git lab 11.9 El git lab Runner ha estado usando un nuevo método para clonar/obtener el repositorio. En la versión actual, GitLab Runner utilizará el método antiguo si el nuevo método no es compatible.
En GitLab 11.0, cambiamos la forma en que configuramos el servidor de medición para GitLab Runner. Se eliminó Metrics_server; use listening_address en GitLab 12.0 en su lugar.
En 11.3, GitLab Runner comienza a admitir múltiples proveedores de caché. Esto resultó en nuevas configuraciones para configuraciones específicas de S3.
Estas rutas ya no estarán disponibles en GitLab 12.0. Para usuarios superiores a 11.9, la actualización directa no tendrá ningún efecto.
Fecha de abandono: 2065 438 22 de junio de 2009
En GitLab 11.4, GitLab Runner introdujo el indicador de función FF_K8s_use_entry point_over_command. En GitLab 12.0, estos indicadores de funciones se eliminarán.
Fecha de eliminación: 2065 438 22 de junio de 2009
Algunas distribuciones de Linux en GitLab Runner han llegado al final de su soporte vital. En GitLab 12.0, GitLab Runner ya no proporciona paquetes de distribución especiales para distribuciones de Linux obsoletas.
Fecha de obsolescencia: 2065 438 22 de junio de 2009
Como parte de agregar soporte para el ejecutor Docker de Windows, es necesario descartar algunos comandos antiguos para imágenes auxiliares. En GitLab 12.0, GitLab Runner comienza a usar nuevos comandos. Esto sólo afecta a los usuarios que sobrescriben la imagen secundaria.
Fecha de migración: 2065 438 22 de junio de 2009
Utilizando git lab Runner 11.10, se introduce un método para configurar Runner para ejecutar el comando git clean. La nueva estrategia de limpieza elimina la necesidad de utilizar los comandos git reset y git clean después del pago.
En GitLab Runner 12.0, GitLab Runner dejó de admitir la antigua estrategia de limpieza y eliminó el método para restaurar funciones estableciendo un indicador de función.
Fecha de obsolescencia: 2065 438 22 de junio de 2009
Se ha cambiado el nombre de la administración de licencias para alinearse mejor con la terminología común de la industria en GitLab 12.0. El propósito del cumplimiento de la licencia es analizar la aplicación, rastrear las licencias utilizadas por componentes de terceros, como bibliotecas y dependencias externas, y verificar si son compatibles con el modelo de licencia del proyecto. Miembro del Equipo de Análisis de Portafolio de Software de Seguridad de Cumplimiento de Licencias.
Fecha de migración: 2065 438 22 de junio de 2009
El parámetro de línea de comando -auth-first-page ya no es compatible y debe eliminarse.
Es necesario eliminar la variable de marca DEP_Scan_Disable_Remote_Check, que ya no es compatible.
El valor de sast_container en la variable de entorno GITLAB_FEATURES debe cambiarse a container_scanning.
Fecha de migración: 2065 438 22 de junio de 2009
La nueva versión ya no actualiza los fragmentos de código de configuración manual de seguridad en la documentación utilizada al configurar las funciones de seguridad en la canalización del proyecto. Utilice include:template:dependency scan. gitlab-ci.yml se incluye mediante la configuración segura.
Fecha de obsolescencia: 2065 438 22 de junio de 2009
Para mitigar esta situación, el reenvío 3DES se desactivará de forma predeterminada. Esto no debería cambiar nada para los usuarios de navegadores modernos, pero algunos usuarios de Internet Explorer versiones 7 y 8 que ejecutan sistemas operativos Windows XP pueden verse afectados.
Fecha de obsolescencia: 2065 438 22 de junio de 2009
GitLab 12.0 es la última versión compatible con MySQL (y MariaDB). Los usuarios deberán migrar a PostgreSQL para utilizar versiones futuras. MySQL ha quedado obsoleto y su soporte anteriormente se limitaba a Enterprise Edition Starter y Premium.
Fecha de obsolescencia: 2065 438 22 de julio de 2009
Estas configuraciones se eliminarán en la interfaz de usuario de GitLab 12.1. Esta política ya se proporciona en gitlab.yml de GitLab 11. Además, los entornos Sentry se pueden definir para diferenciar entre múltiples implementaciones, como desarrollo, stagin y producción.
Fecha de migración: 2065 438 22 de julio de 2009
Cuando introdujimos plantillas de proyectos a nivel de grupo en GitLab 11.6, se amplió la funcionalidad. Se corrigió este error en git lab 11.11 para brindar a los usuarios/instancias existentes por debajo de Silver/Premium un período de gracia de tres meses. El 22 de agosto de 2019, este período de gracia expirará y las plantillas de proyectos grupales requerirán Silver/remium o superior.
Fecha de migración: 2065 438 22 de agosto de 2009
Si los usuarios que usan Python 2 se administran ellos mismos al comenzar a usar GitLab 12.2, deberán configurar la variable CI LM_PYTHON_VERSION en "2". . Los usuarios que usan Python 3 ahora pueden cambiar la variable CI LM_PYTHON_VERSION a "3".
Fecha de migración: 2065 438 22 de agosto de 2009
En GitLab 12.3, está previsto abandonar los trabajos de línea de comandos por lotes de Windows (como cmd.exe) en GitLab Runner para admitir soporte extendido y extendido para Windows PowerShell.
Para aquellos que aún desean ejecutar sus proyectos en cmd.exe, estos comandos se pueden llamar desde PowerShell, pero el procesamiento por lotes de Windows no es compatible directamente.
Fecha de obsolescencia: 2065 438 22 de septiembre de 2009
Al ejecutar programas usando Docker y máquinas Docker usando git lab Runner 11.10, el directorio de trabajo almacenado en caché en el volumen compartido cambió. GitLab Runner ahora almacena en caché todo el directorio base configurado con builds_dir, no solo el directorio principal del directorio de trabajo del trabajo. Debido a que se trata de un cambio de comportamiento, agregamos un indicador de función que nos permite controlar si se debe utilizar el comportamiento nuevo o antiguo. En GitLab Runner 12.3, se eliminarán los indicadores de funciones y el comportamiento anterior.
Fecha de migración: 22 de septiembre de 2065 438 2009
Python 2.7 alcanzó su ciclo de vida el 65 de junio de 2065 438 2009, por lo que se moverá en futuras versiones de GitLab Excepto por la compatibilidad con Python 2 .
Fecha de migración: 2065438 22 de febrero de 2009.
Si utiliza Omnibus para instalar una instancia de creación propia, puede actualizarla directamente a través del administrador de paquetes de la oficina de distribución:
Por ejemplo, en CentOS, puede completar automáticamente el proceso de actualización a través de yum updatedata gitlab-ce.
GitLab 12.0 fusiona los cambios de la base de datos realizados en la Edición Empresarial a lo largo de los años en la Edición Comunitaria. Como parte de este trabajo, también se eliminaron varias migraciones antiguas. Los usuarios que actualicen a GitLab 12 deben primero actualizar a la última versión del parche 11.11 y luego actualizar a 12.0.0. Al actualizar a versiones futuras, como 12.1.0, los usuarios primero deben actualizar a 12.0.0. No actualizar en este orden puede provocar que falle la migración de datos, lo que provocará errores en la aplicación. La instalación general primero forzará una actualización a 12.0.0. Los usuarios que instalen desde el código fuente deben hacerlo manualmente en este orden (XX --> 11.11 --> 12.0 --> YY). De forma predeterminada, GitLab 12.0 usa almacenamiento hash. Esto afectará a las nuevas instalaciones.
GitLab 12.0 actualizará automáticamente la versión de PostgreSQL a 10.0.
Los usuarios pueden omitir la actualización automática de PostreSQL 10.0 y crear /etc/git lab/disable-PostgreSQL-upgrade.
Si usa GitLab Geo, la actualización automática de PostgreSQL se omitirá en el nodo principal y en todos los nodos secundarios. Proporcionaremos una ruta de actualización para los usuarios de Geo en 12.1.
De forma predeterminada, GitLab 12.0 habilitará el registro JSON. También proporciona un documento de configuración para conservar el formato de registro anterior que no es JSON.