GitLab version 13.5, quoi de neuf ?

La version de Gitlab 13.5 est sortie très récemment et nous vous en avons fait comme à notre habitue un récapitulatif autour des principales évolutions et mise jours. Nous parlerons en l’occurence de Wikis, de visualisation des coûts, des namespaces, des nouvelles fonctionnalités pour les pipelines / jobs, de l’auto devops et de quelques bonus que nous avons mis plus bas dans cet article !

Wikis accessibles au niveau des groupes (Premium et Ultimate)

Les wikis sont essentiels à de nombreuses équipes pour planifier et documenter leur travail. Ils sont si populaires qu’ils sont consultés plus d’un million de fois chaque mois sur GitLab.com. Malgré cela, ils ont toujours été limités au niveau des projets.

Suite à une très forte demande de la communauté, les wikis sont maintenant disponibles au niveau des groupes à partir du tiers Premium.

Aperçu des coûts de vos clusters avec Gitlab 13.5

De nombreux utilisateurs créent leurs propres scripts pour mieux comprendre les coûts de leurs clusters. Dorénavant, avec GitLab en version 13.5, vous pouvez voir un aperçu de ces coûts et de l’utilisation des ressources directement depuis l’interface utilisateur de GitLab. Cette intégration s’appuie sur le « modèle de coût » de Kubecost et vous donne des informations flexibles sur différents niveaux : coûts mensuels, coûts de vos applications gérées par GitLab… Vous pouvez même créer des tableaux personnalisés plus élaborés avec les métriques fournies par Kubecost et Prometheus.

Personnalisation des namespaces des clusters managés

Lors de la création de clusters managés GitLab, vous pouvez désormais choisir d’utiliser un namespace unique par projet ou par environnement. Alors que les namespaces uniques par projet simplifient la recherche d’applications, les namespaces séparés par environnement fournissent une sécurité supplémentaire.

Gitlab 13.5 apporte des fonctionnalités supplémentaires pour les pipelines et les jobs

Logs des jobs pré-repliés

Les logs des jobs contiennent très souvent de très longues sections, rendant l’analyse laborieuse.

Vous pouvez maintenant définir si une section doit être repliée par défaut dans les logs. Il suffit d’ajouter [collapse=true] dans vos jobs :

job1:
  script:
    - echo -e "section_start:`date +%s`:my_first_section[collapsed=true]\r\e[0KHeader of the 1st collapsible section"
    - echo 'this line should be hidden automatically after loading the job log'
    - echo -e "section_end:`date +%s`:my_first_section\r\e[0K"

Mise en cache optionnelle pour les pipelines en échec

Lorsqu’une pipeline récupère beaucoup de dépendances externes (telle que NPM) et qu’elle réussie, ces dépendances sont mises en cache, ce qui permet de gagner un temps précieux. Ce n’était malheureusement pas le cas lorsque la pipeline échouaient. GitLab 13.5 vous permet dorénavant de les mettre en cache peu importe qu’une pipeline réussie ou échoue.

Suivi du stockage des PipelineArtifact

Auparavant, les PipelineArtifacts n’étaient pas pris en compte dans les quotas de stockage, ce qui pouvait fausser le calcul de l’espace réellement disponible. Ils sont maintenant annotés du label « Artifact », ce qui vous permet de savoir précisément combien d’espace ils occupent.

Auto DevOps

Upgrade de l’Auto DevOps avec Helm 3

Jusqu’à présent, dans les environnements Kubernetes, l’Auto DevOps nécessitait l’installation de Helm 2 sur le cluster, ce qui présentait un risque de sécurité étant donné les droits d’accès root de Tiller.

La version actuelle de GitLab supporte enfin Helm 3, qui n’exige plus l’installation de Tiller.

Déploiement partiel compatible avec Kubernetes 1.6

Les clusters de GKE ont été automatiquement mis à niveau vers Kubernetes 1.16 début octobre. L’Auto DevOps a été mis à jour pour supporter cette version pour les déploiements partiels afin de continuer à fonctionner comme prévu.

Le contrôle d’accès aux branches peut outrepasser l’approbation du propriétaire du code (Premium et Ultimate)

Par défaut, une merge request sur une branche protégée doit être approuvée par son propriétaire, ceci afin de vérifier la qualité du code et de mettre en place des contrôles de conformité. Cependant, cela manque de flexibilité pour des cas tels que la mise à jour des tags ou des versions sur vos branches par défaut par exemple.

Dans la dernière version de GitLab, vous pouvez désigner un utilisateur comme étant « autorisé à pousse » et lui permettre ainsi de se passer de l’approbation du propriétaire.

Améliorations majeures dans la stratégie de nettoyage de la Container Registry

Vous avez peut-être déjà rencontré un problème dans lequel la stratégie de nettoyage fonctionnait mais n’était que partiellement terminée. Cela se produit lorsqu’une stratégie tente de supprimer de nombreuses images et qu’elle est interrompue (timeout).

Dorénavant, si cela se produit, elle continuera à supprimer les tags lors de sa prochaine exécution, et un avertissement vous signalera qu’il reste des règles partiellement exécutées. Vous pourrez ainsi décider d’intervenir manuellement ou non.

Avec GitLab 13.5, les Feature Flags sont maintenant disponibles pour tous les tiers

En mars 2020, GitLab a annoncé rendre progressivement open-source 18 fonctionnalités. Ce mois-ci, ce sont les Feature Flags qui sont concernés.

Avec les Feature Flags, vous pouvez déployer les nouvelles fonctionnalités de votre application en plus petits lots en les activant ou les désactivant pour des sous-ensembles d’utilisateurs, ce qui vous aide à obtenir une livraison continue. Les Feature Flags vous aident à réduire les risques, en vous permettant de faire des tests contrôlés et de séparer la livraison des fonctionnalités du lancement chez le client.

Package Registry générique

GitLab supporte une large variété de langages dans son offre de Package Registry. Cependant, vous souhaitez peut-être stocker d’autres types de binaires dans GitLab qui ne sont pas encore supportés.

Dans GitLab 13.5, vous avez maintenant la possibilité d’ajouter tous types de binaires à une Package Registry générique, et ce quel que soit leur langage.

Attacher des assets binaires aux releases

Si vous n’utilisiez pas actuellement GitLab pour vos releases parce que vous ne pouviez pas y attacher de binaires, vous n’avez plus d’excuse. Vous pouvez dorénavant attacher des binaires à un tag de release depuis le « gitlab-cy.yml ». Cela étend le support des Release Assets pour inclure des binaires, plutôt que des liens vers des assets ou du code source, et rend encore plus facile l’automatisation de votre processus de publication.

GitLab 13.5 : les nouveautés côté services

Installation de l’agent GitLab Kubernetes avec GitLab Omnibus (Premium et Ultimate)

Le mois dernier, GitLab a introduit l’Agent GitLab Kubernetes pour les instances autogérées installées avec Helm.

L’Agent est maintenant compatible avec les instances Omnibus.

Démarrer rapidement avec GitLab et Terraform

Un nouveau template de CI/CD vous permet de configurer des pipelines Terraform sans aucun travail manuel, réduisant ainsi le frein à l’adoption de Terraform.

Petits plus de Gitlab 13.5

Marquer les merge requests en tant que « Brouillon » d’un simple clic

Dorénavant, au lieu d’éditer une merge request et de préfixer son titre avec draft (anciennement wip), vous pouvez directement cliquer sur le bouton « Mark as draft » en haut à droite de la page de merge request.

Supprimer les labels des issues d’un simple clic

Pour supprimer un label d’une issue, il fallait habituellement : trois clics, aller chercher une nouvelle liste de labels sur le serveur, et effectuer une recherche pour trouver ledit label. C’était peu intuitif et inefficace ! Ce n’est peut-être pas révolutionnaire, mais vous pouvez maintenant supprimer un label d’une issue d’un simple clic.

Gitlab 13.5 offre une vraie navigation dans le wiki

Si vous avez plusieurs niveaux de pages, il peut être difficile de naviguer ou de trouver des pages dans un wiki. La navigation a été repensée et s’affiche maintenant de façon hiérarchique dans la barre latérale.

Vous pouvez retrouver l’article complet de cette release sur le blog de GitLab.