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, etc.

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 versions sur vos branches ou des tags par défaut par exemple.

Dans la dernière version de GitLab, vous pouvez désigner un utilisateur comme étant “autorisé à pousser” 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.

Les Feature Flags disponibles pour tous les tiers dans GitLab 13.5

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.