GitLab 11.10 con canalizacións do panel de control, canalizacións de resultados combinados e suxestións de varias liñas nas solicitudes de combinación.
Información conveniente sobre o rendemento das canalizacións en diferentes proxectos
GitLab segue aumentando a visibilidade do ciclo de vida de DevOps. Neste número sobre panel de control engadiu unha visión xeral do estado da canalización.
Isto é conveniente aínda que esteas estudando o pipeline dun único proxecto, pero é especialmente útil se varios proxectos, - e isto adoita ocorrer se usa microservizos e quere executar unha canalización para probar e entregar código desde diferentes repositorios de proxectos. Agora podes ver inmediatamente a actuación tuberías no panel de control, onde queira que se realicen.
Execución de canalizacións para resultados combinados
Co paso do tempo, as ramas de orixe e destino diverxen, e pode xurdir unha situación na que se enfronten por separado, pero xuntos non funcionen. Agora podes executar canalizacións para obter resultados combinados antes de fusionar. Deste xeito, notará rapidamente erros que só aparecerían se os cambios se movesen con frecuencia entre ramas, o que significa que corrixirá os erros da canalización moito máis rápido e empregará o GitLab Runner.
Optimice aínda máis a colaboración
GitLab 11.10 engade aínda máis funcións para unha colaboración perfecta e fluxos de traballo simplificados. EN número anterior introducimos suxestións para solicitudes de combinación, nas que un revisor podía suxerir un cambio nunha liña dun comentario a unha solicitude de combinación, e podería ser enviado inmediatamente directamente desde o fío de comentarios. Aos nosos usuarios gustoulles e pediron ampliar esta función. Agora podes ofrecer cambios para varias liñas, indicando que liñas eliminar e cales engadir.
O empregado máis valioso deste mesMVP) - Takuya Noguchi
O empregado máis valioso deste mes é Takuya Noguchi (Takuya Noguchi). Takuya fixo un bo traballo para a gloria de GitLab: corrixiron erros, completou as deficiencias no backend e na interface e mellorouse a interface de usuario. Grazas!
Características principais de GitLab 11.10
Canalizacións no panel de control
PREMIUM, ULTIMATE, PRATA, OURO
O panel de control de GitLab mostra información sobre proxectos en toda a túa instancia de GitLab. Engades proxectos individuais un a un e podes escoller o que che interesa.
Nesta versión, engadimos información sobre os estados das canalizacións ao panel. Agora os desenvolvedores ven a funcionalidade das canalizacións en todos os proxectos necesarios, nunha soa interface.
Canalizacións para resultados combinados
PREMIUM, ULTIMATE, PRATA, OURO
É común que a rama de orixe diverxe da rama de destino ao longo do tempo, a menos que constantemente presione cambios entre elas. Como resultado, as canalizacións das ramas de orixe e destino son "verdes" e non hai conflitos de fusión, pero a fusión falla debido a cambios incompatibles.
Cando a canalización de solicitude de combinación crea automaticamente unha nova ligazón que contén o resultado combinado da combinación das ramas de orixe e destino, podemos executar a canalización nesa ligazón e asegurarnos de que o resultado global funciona.
Se estás a usar canalizacións de solicitude de combinación (en calquera capacidade) e utilizas executadores privados de GitLab versión 11.8 ou anterior, terás que actualizalos para evitar este problema. gitlab-ee#11122. Isto non afecta aos usuarios dos corredores públicos de GitLab.
Cando traballan xuntos en solicitudes de combinación, moitas veces detectan problemas e propón solucións. Desde GitLab 11.6 soportamos proposta de modificación por unha liña.
Na versión 11.10, os comentarios de diferenza de solicitude de combinación poden propoñer cambios en varias liñas e, a continuación, calquera que teña permisos de escritura na rama orixinal pode aceptalos cun só clic. Grazas á nova función, podes evitar copiar e pegar, como nas versións anteriores.
Atallos nunha zona
PREMIUM, ULTIMATE, PRATA, OURO
Con etiquetas no mesmo ámbito, os equipos poden aplicar etiquetas mutuamente excluíntes (no mesmo ámbito) a un problema, solicitude de combinación ou épico en escenarios con campos personalizados ou estados de fluxo de traballo personalizados. Configúranse usando unha sintaxe especial de dous puntos no título da etiqueta.
Digamos que necesitas un campo personalizado nas tarefas para facer un seguimento do sistema operativo da plataforma á que se dirixan as túas funcións. Cada tarefa debe relacionarse só cunha plataforma. Podes crear atallos platform::iOS, platform::Android, platform::Linux e outros segundo sexa necesario. Se aplicas un destes atallos a unha tarefa, eliminará automaticamente outro atallo existente que comeza platform::.
Digamos que tes atallos workflow::development, workflow::review и workflow::deployed, indicando o estado do fluxo de traballo do teu equipo. Se a tarefa xa ten un atallo workflow::development, e o programador quere mover a tarefa ao escenario workflow::review, só aplica o novo atallo e o antigo (workflow::development) elimínase automaticamente. Este comportamento xa existe cando moves tarefas entre listas de atallos no taboleiro de tarefas que representa o fluxo de traballo do teu equipo. Agora os membros do equipo que non traballan directamente co taboleiro de tarefas poden cambiar o estado do fluxo de traballo nas propias tarefas.
Cando adoita utilizar un rexistro de contedores con canalizacións de CI, realiza varias modificacións separadas nunha única etiqueta. Debido á implementación da distribución de Docker, o comportamento predeterminado é gardar todos os cambios no sistema, pero acaban ocupando moita memoria. Se usa o parámetro -m с registry-garbage-collect, pode eliminar rapidamente todos os cambios anteriores e liberar espazo precioso.
Compra de minutos adicionais de CI Runner
OURO, BRONCE, PRATA
Os usuarios con plans de pago de GitLab.com (Ouro, Prata, Bronce) agora poden comprar minutos adicionais de CI Runner. Previamente, era necesario cumprir a cota prevista no plan. Con esta mellora, pode precomprar minutos por encima da cota para evitar interrupcións debido a paradas de canalizacións.
Agora 1000 minutos custan 8 $ e podes mercar tantos como queiras. Os minutos adicionais comezarán a consumirse cando gastas toda a túa cota mensual, e o resto dos minutos adicionais transferiranse ao mes seguinte. EN futura versión queremos engadir esta función aos plans gratuítos tamén.
Con Auto DevOps, os equipos pasan ás prácticas modernas de DevOps case sen esforzo. A partir de GitLab 11.10, cada traballo en Auto DevOps ofrécese como modelo independente. Os usuarios poden usar функцию includes en GitLab CI para habilitar etapas individuais de Auto DevOps e, ao mesmo tempo, utilizar o seu ficheiro personalizado gitlab-ci.yml. Deste xeito, só pode habilitar os traballos que precisa e aproveitar as actualizacións anteriores.
Xestiona automaticamente os membros do grupo en GitLab.com mediante SCIM
PRATA, OURO
Anteriormente, tiñas que xestionar manualmente a pertenza ao grupo en GitLab.com. Agora podes usar SAML SSO e xestionar a adhesión mediante SCIM para crear, eliminar e actualizar usuarios en GitLab.com.
Isto é especialmente útil para empresas con gran número de usuarios e provedores de identidade centralizados. Agora podes ter unha única fonte de verdade, como Azure Active Directory, e os usuarios crearanse e eliminaranse automaticamente a través do fornecedor de identidade en lugar de manualmente.
Inicie sesión en GitLab.com a través do provedor SAML
PRATA, OURO
Anteriormente, ao usar SAML SSO para grupos, o usuario tiña que iniciar sesión coas credenciais de GitLab e cun provedor de identidade. Agora podes iniciar sesión directamente mediante SSO como usuario de GitLab asociado a un grupo configurado.
Os usuarios non terán que iniciar sesión dúas veces, o que facilita ás empresas o uso de SAML SSO para GitLab.com.
Outras melloras en GitLab 11.10
Esquema épico infantil
ÚLTIMO, OURO
Na versión anterior, engadimos épicas infantís (épicas de épicas) para axudarche a xestionar a estrutura de distribución de emprego. As épicas infantís aparecen na páxina da épica pai.
Nesta versión, a páxina épica principal mostra un esquema das épicas fillas para que os equipos poidan ver a cronoloxía das épicas fillas e xestionar as dependencias de tempo.
Nesta versión, presentamos pantallas informativas que aparecen cando pasas o rato sobre unha ligazón de solicitude de combinación. Anteriormente, só mostrabamos o título da solicitude de combinación, pero agora tamén mostramos o estado da solicitude de combinación, o estado da canalización de CI e o URL curto.
Os fluxos de traballo de Git para lanzar ou enviar software adoitan implicar varias sucursais a longo prazo, para facer correccións en versións anteriores (p. ex. stable-11-9) ou pasar das probas de calidade á produción (p. ex. integration), pero non é doado atopar solicitudes de combinación para estas ramas entre as moitas solicitudes de combinación abertas.
A lista de solicitudes de combinación de proxectos e grupos agora pode filtrarse pola rama de destino da solicitude de combinación para que sexa máis doado atopar a que precisa.
Se utilizamos o método de desenvolvemento baseado en Trunk, debemos evitar ramas de longa duración en favor de ramas pequenas e temporais cun único propietario. Os pequenos cambios adoitan enviarse directamente á rama de destino, pero facelo corre o risco de romper a compilación.
Nesta versión, GitLab admite novas opcións de inserción de Git para abrir automaticamente solicitudes de fusión, establecer a rama de destino e aplicar unha fusión na canalización exitosa desde a liña de comandos no momento da inserción á rama.
GitLab pode acceder a varios servidores Prometheus (entorno, proxecto e grupos (esperado)), pero ter varios puntos finais pode engadir complexidade ou pode non ser compatible con paneis estándar. Con esta versión, os equipos poden usar unha única API de Prometheus, facilitando moito a integración con servizos como Grafana.
Nun Wiki do proxecto, os equipos poden compartir documentación e outra información importante xunto co código fonte e as tarefas. Con esta versión, pode ordenar a lista de páxinas Wiki por data de creación e título para atopar rapidamente o contido creado recentemente.
Seguimento dos recursos solicitados polo clúster
ÚLTIMO, OURO
GitLab axúdache a supervisar o teu clúster de Kubernetes para aplicacións de desenvolvemento e produción. A partir desta versión, supervisa as solicitudes de CPU e memoria do teu clúster para detectar posibles problemas antes de que se convertan en problemas.
Consulta as métricas do equilibrador de carga no panel de control de Grafana
CORE, STARTER, PREMIUM, ULTIMATE
É moi importante supervisar o estado da túa instancia de GitLab. Anteriormente, fornecíamos paneis predeterminados a través dunha instancia de Grafana incorporada. A partir desta versión, incluímos paneis adicionais para supervisar os equilibradores de carga NGINX.
SAST para Elixir
ÚLTIMO, OURO
Seguimos ampliando a compatibilidade lingüística e profundizando nas comprobacións de seguridade. Nesta versión activamos as comprobacións de seguranza dos proxectos Elixir e proxectos creados en Plataforma Phoenix.
Múltiples consultas nun mesmo diagrama
PREMIUM, ULTIMATE, PRATA, OURO
En GitLab, podes crear gráficos para visualizar as métricas que recompilas. Moitas veces, por exemplo, se precisa mirar o valor máximo ou medio dunha métrica, quere mostrar varios valores nun gráfico. A partir deste lanzamento, tes esta oportunidade.
Resultados de DAST no Panel de control de seguranza do grupo
Engadimos os resultados das probas de seguranza de aplicacións dinámicas (DAST) ao panel de seguridade do equipo ademais de SAST, a exploración de contedores e a análise de dependencias.
Engadir metadatos a un informe de exploración de contedores
ÚLTIMO, OURO
Nesta versión, o Informe de exploración de contedores contén máis metadatos. Engadimos compoñente afectado (unha función de Clair) nos metadatos existentes: prioridade, ID (con referencia a mitre.org) e nivel afectado (por exemplo, debian:8).
Engadir un tipo de informe de métricas ás solicitudes de combinación
PREMIUM, ULTIMATE, PRATA, OURO
GitLab xa ofrece varios tipos de informes que se poden incluír directamente nas solicitudes de combinación: desde informes ata calidade do código и probas unitarias na fase de verificación ata SAST и DAST en fase de protección.
Aínda que estes son informes importantes, tamén se necesita información básica que se adapte a diferentes escenarios. En GitLab 11.10, proporcionamos informes de métricas directamente na solicitude de combinación, que espera un par clave-valor simple. Deste xeito, os usuarios seguen os cambios ao longo do tempo, incluídas as métricas personalizadas e os cambios nas métricas para unha solicitude de combinación específica. O uso da memoria, as probas especializadas de carga de traballo e os estados de saúde pódense converter en métricas sinxelas que se poden ver directamente nas solicitudes de combinación xunto con outros informes integrados.
Soporte para proxectos Maven de varios módulos para a exploración de dependencias
ÚLTIMO, OURO
Con esta versión, os proxectos Maven de varios módulos admiten a dixitalización de dependencias de GitLab. Anteriormente, se un submódulo tiña unha dependencia doutro submódulo do mesmo nivel, non podía permitir a carga desde o repositorio central de Maven. Agora créase un proxecto Maven de varios módulos con dous módulos e unha dependencia entre os dous módulos. As dependencias entre os módulos irmáns están agora dispoñibles no repositorio local de Maven para que a construción poida continuar.
Os usuarios poden cambiar a ruta de clonación en CI
Por defecto, GitLab Runner clona o proxecto nunha subruta única $CI_BUILDS_DIR. Pero para algúns proxectos, como Golang, o código debe ser clonado nun directorio específico para que se poida construír.
En GitLab 11.10 introducimos a variable GIT_CLONE_PATH, que permite especificar un camiño específico onde GitLab Runner clona o proxecto antes de executar a tarefa.
Enmascaramento sinxelo de variables protexidas nos rexistros
GitLab ofrece varias formas защитить и limitar a zona variables en GitLab CI/CD. Pero as variables aínda poden acabar nos rexistros de compilación, de forma intencionada ou accidental.
GitLab toma en serio a xestión de riscos e a auditoría e segue engadindo funcións de conformidade. En GitLab 11.10, introducimos a capacidade de enmascarar certos tipos de variables nos rexistros de rastrexo de traballos, engadindo un nivel de protección contra o contido destas variables que se inclúen accidentalmente nos rexistros. E agora GitLab máscaras automaticamente moitas variables de token incorporadas.
Activa ou desactiva DevOps automático a nivel de equipo
Con Auto DevOps nun proxecto de GitLab.com, podes asumir fluxos de traballo de DevOps modernos desde a compilación ata a entrega sen complicacións.
A partir de GitLab 11.10, podes activar ou desactivar Auto DevOps para todos os proxectos do mesmo grupo.
Páxina de licenza simplificada e mellorada
STARTER, PREMIUM, ULTIMATE
Para que a xestión das claves de licenza sexa máis cómoda e sinxela, redeseñamos a páxina de licenzas no panel de administración e destacamos os elementos máis importantes.
Actualiza o selector de atallos para as implementacións de Kubernetes
Os paneis de implementación mostran información sobre todas as implementacións de Kubernetes.
Nesta versión, cambiamos a forma en que asignamos atallos ás implementacións. Os partidos xa están dispoñibles por app.example.com/app и app.example.com/env ou app. Isto evitará os conflitos de filtrado e o risco de implantacións incorrectas asociadas ao proxecto.
A integración de Kubernetes con GitLab permítelle utilizar a función RBAC mediante unha conta de servizo e un espazo de nomes dedicado para cada proxecto de GitLab. A partir desta versión, para obter a máxima eficiencia, estes recursos só se crearán cando sexan necesarios para a súa implantación.
Ao implementar Kubernetes, GitLab CI creará estes recursos antes da implantación.
Os clústeres de nivel de grupo agora admiten a instalación de GitLab Runner. Os corredores de Kubernetes a nivel de grupo aparecen para os proxectos fillos como corredores de grupo etiquetados cluster и kubernetes.
Funcións implementadas con GitLab sen servidor, agora mostra o número de chamadas recibidas para unha función concreta. Para iso, cómpre instalar Prometheus no clúster onde está instalado Knative.
Control de parámetros git clean para traballos de CI/CD de GitLab
Por defecto, GitLab Runner execútase git clean durante o proceso de carga de código ao executar un traballo en GitLab CI/CD. A partir de GitLab 11.10, os usuarios poden controlar os parámetros pasados a un equipo git clean. Isto é útil para equipos con corredores dedicados, así como para equipos que recollen proxectos de grandes monorepositorios. Agora poden controlar o proceso de descarga antes de executar scripts. Nova variable GIT_CLEAN_FLAGS o valor predeterminado é -ffdx e acepta todos os parámetros de comando posibles [git clean](https://git-scm.com/docs/git-clean).
Os contornos seguros poden requirir un recurso de autorización externo adicional para acceder ao proxecto. Engadimos soporte para un nivel adicional de control de acceso en 10.6 e recibiu moitas solicitudes para abrir esta funcionalidade en Core. Temos o pracer de presentar a autorización externa e unha capa adicional de seguridade para as instancias do núcleo, xa que esta función é necesaria para os participantes individuais.
O rol de programador pode crear proxectos en grupos desde a versión 10.5, e agora isto é posible en Core. A creación de proxectos é unha característica clave para a produtividade en GitLab e, ao incluír esta función en Core, agora é máis fácil que os membros de exemplo fagan algo novo.
Hoxe publicamos GitLab Runner 11.10! GitLab Runner é un proxecto de código aberto que se usa para executar traballos de CI/CD e enviar os resultados a GitLab.
A lista completa de cambios pódese atopar no rexistro de cambios de GitLab Runner: REGISTRO DE CAMBIOS.
Corrección da devolución project_id na API de busca de blob en Elasticsearch
STARTER, PREMIUM, ULTIMATE
Corriximos un erro na API de busca de blobs de Elasticsearch que devolvía 0 por erro project_id. Será necesario reindexar Elasticsearchpara obter os valores correctos project_id despois de instalar esta versión de GitLab.
Melloras ómnibus
CORE, STARTER, PREMIUM, ULTIMATE
Fixemos as seguintes melloras en Omnibus en GitLab 11.10:
En GitLab 11.5 Engadimos este requisito á documentación xeográfica: gitlab-ee#8053.
En GitLab 11.6sudo gitlab-rake gitlab:geo:check comproba se o almacenamento hash está activado e se migran todos os proxectos. Cm. gitlab-ee#8289. Se estás a usar Geo, realiza esta comprobación e migra o antes posible.
En GitLab 11.8 aviso de desactivación permanente gitlab-ee!8433 mostrarase na páxina Área de administración > Geo > Nodosse non se permiten as comprobacións anteriores.
En GitLab 12.0 Geo utilizará os requisitos de almacenamento hash. Cm. gitlab-ee#8690.
Canonical anunciou o fin do soporte estándar para Ubuntu 14.04 Abril de 2019. Recomendamos aos usuarios que actualicen a unha versión LTS compatible: Ubuntu 16.04 ou Ubuntu 18.04.
Data de eliminación: 22 maio 2019
Limitar o número máximo de canalizacións creadas por unha presentación
Anteriormente, GitLab creou canalizacións para HEAD cada rama do envío. Isto é útil para os desenvolvedores que realizan varios cambios á vez (por exemplo, nunha rama de funcións e a develop).
Pero ao empurrar un gran repositorio onde hai moitas ramas activas (por exemplo, para moverse, espellar ou bifurcar), non é necesario crear unha canalización para cada rama. A partir de GitLab 11.10 creamos máximo 4 canalizacións ao enviar.
Data de eliminación: 22 maio 2019
Rutas de código heredadas de GitLab Runner
Desde Gitlab 11.9 GitLab Runner usa novo método clonar/chamar ao repositorio. Actualmente GitLab Runner usará o método antigo se non se admite o novo. Ver máis en esta tarefa.
En GitLab 11.0, cambiamos a vista de configuración do servidor de métricas para GitLab Runner. metrics_server será eliminado a favor de listen_address en GitLab 12.0. Ver máis en esta tarefa.
Estes camiños non estarán dispoñibles en GitLab 12.0. Como usuario, non necesitas cambiar nada, só asegúrate de que a túa instancia de GitLab estea executando a versión 11.9+ cando actualices a GitLab Runner 12.0.
Data de eliminación: 22 2019 de xuño, o
Opción obsoleta para a función de punto de entrada para GitLab Runner
En GitLab 12.0, cambiaremos ao comportamento correcto coma se a configuración da función estivese desactivada. Ver máis en esta tarefa.
Data de eliminación: 22 2019 de xuño, o
Compatibilidade obsoleta para unha distribución de Linux que chegou a EOL para GitLab Runner
Algunhas distribucións de Linux nas que pode instalar GitLab Runner cumpriron o seu propósito.
En GitLab 12.0, GitLab Runner xa non distribuirá paquetes a estas distribucións de Linux. Pódese atopar unha lista completa das distribucións que xa non son compatibles no noso documentación. Grazas a Javier Ardo (Javier Jardón) por a súa contribución!
Data de eliminación: 22 2019 de xuño, o
Eliminando comandos antigos de GitLab Runner Helper
Eliminando o mecanismo git clean heredado de GitLab Runner
En GitLab Runner 11.10 ofrecemos a oportunidade configurar como Runner executa un comando git clean. Ademais, a nova estratexia de limpeza elimina o uso git reset e pon o mando git clean despois do paso de carga.
Dado que este cambio de comportamento pode afectar a algúns usuarios, preparamos unha configuración FF_USE_LEGACY_GIT_CLEAN_STRATEGY. Se establece o valor true, restaurará a estratexia de limpeza antiga. Podes atopar máis información sobre o uso de parámetros de función en GitLab Runner en documentación.
En GitLab Runner 12.0, eliminaremos a compatibilidade coa estratexia de limpeza antiga e a posibilidade de restaurala mediante un parámetro de función. Ver máis detalles en esta tarefa.
Data de eliminación: 22 2019 de xuño, o
Sección Información do sistema no panel de administración
GitLab presenta información sobre a súa instancia de GitLab en admin/system_info, pero esta información pode non ser precisa.
libre: Repositorios privados ilimitados e número ilimitado de colaboradores do proxecto. Os proxectos pechados teñen acceso a funcións de nivel libreTer proxectos abertos ter acceso a funcións de nivel ouro.
Bronce: Para equipos que necesitan acceso a funcións avanzadas de fluxo de traballo.
prata: Para equipos que necesitan capacidades de DevOps máis robustas, cumprimento e soporte máis rápido.
ouro: Adecuado para moitos traballos de CI/CD. Todos os proxectos abertos poden usar as funcións Gold de balde, independentemente do plan.