La version 13.4 est sortie avec le stockage HashiCorp pour les variables CI, l’agent Kubernetes et un centre de sécurité, ainsi que des fonctionnalités activables dans Starter
Chez GitLab, nous réfléchissons toujours à la manière d'aider les utilisateurs à réduire les risques, à augmenter l'efficacité et à accélérer les livraisons sur votre plateforme préférée. Ce mois-ci, nous avons ajouté de nombreuses nouvelles fonctionnalités utiles qui renforcent les capacités de sécurité, réduisent le nombre de vulnérabilités, améliorent l'efficacité, simplifient l'utilisation de GitLab et aident votre équipe à livrer des fonctionnalités encore plus rapidement. Nous espérons que les principales fonctionnalités de cette version vous seront utiles, ainsi que 53 autres nouvelles fonctionnalités, ajoutées dans cette version.
Fonctionnalités de sécurité améliorées
Nous nous efforçons d'ajouter plusieurs nouvelles fonctionnalités à GitLab DevSecOps chaque mois, et cette version ne fait pas exception. dans le cadre de la construction et du déploiement. De plus, les organisations qui souhaitent maintenir la séparation des responsabilités en matière de déploiement de code peuvent maintenant . Ce rôle correspond au et permettra de valider les merge requests (appelées « demandes de fusion » dans la version française de GitLab) et de déployer du code dans des environnements protégés, tout en ne donnant pas accès à la modification du code lui-même.
Une autre façon de réduire les risques est d'utiliser le nouveau . Les opérateurs peuvent déployer des clusters Kubernetes depuis GitLab sans avoir à ouvrir l'accès à leur cluster à l'ensemble d'Internet. Nous introduisons également une prise en charge automatique du contrôle de version pour les nouveaux fichiers d'état Terraform avec pour soutenir la conformité aux exigences et la facilité de débogage. Enfin, le tableau de bord de sécurité de l'instance est devenu un avec des rapports de vulnérabilités et des paramètres de sécurité.
Une utilisation plus conviviale et efficace de GitLab
Nous avons amélioré notre recherche globale en ajoutant , permettant un accès facile aux derniers tickets, groupes, projets, paramètres et sections d'aide. Nous sommes ravis d'annoncer que des redirections ont été ajoutées dans GitLab Pages pour rediriger des pages et des répertoires spécifiques au sein du site, ce qui permettra aux utilisateurs de déployer plus efficacement leurs sites. Et pour ceux qui souhaitent obtenir des informations détaillées sur le déploiement, cette version permet !
Les embarcations à code source ouvert
Nous présentons , ajouté par . Les indicateurs de couverture des tests unitaires du code modifié donnent aux développeurs une vue d'ensemble de la couverture de code lors de la révision ; cette information aide à accélérer la révision et à réduire le temps de fusion et de déploiement du nouveau code. Et nous et prévoyons .
Et ce n'est que le début !
Comme toujours, il y a trop peu de place dans le récapitulatif général, alors qu'il y a beaucoup de fonctionnalités intéressantes dans la version 13.4. Voici encore quelques-unes :
- .
Si vous souhaitez savoir à l'avance ce qui vous attend dans le prochain déploiement, regardez .
.
de ce mois —
Fabio a apporté une contribution significative dans — une fonctionnalité attendue depuis longtemps par la communauté GitLab. C'est vraiment une contribution importante avec des changements non triviaux qui ont nécessité une coopération continue avec les membres de l'équipe GitLab et ont touché de nombreux domaines du projet, tels que l'UX, le frontend et le backend.
Principales fonctionnalités de la version GitLab 13.4
Utilisez les clés HashiCorp Vault dans les tâches CI
(PREMIUM, ULTIMATE, SILVER, GOLD)
Dans la version 12.10, GitLab a introduit la possibilité d'obtenir et de transmettre des clés dans les tâches CI à l'aide du gestionnaire de tâches GitLab. Nous élargissons maintenant , ajoutant une nouvelle syntaxe secrets dans le fichier .gitlab-ci.yml. Cela facilitera la configuration et l'utilisation du stockage HashiCorp avec GitLab.
et .
Nous vous présentons l'Agent Kubernetes GitLab
(PREMIUM, ULTIMATE)
L'intégration de GitLab avec Kubernetes permet depuis longtemps de déployer sur des clusters Kubernetes sans nécessiter de configuration manuelle. Beaucoup d'utilisateurs apprécient la simplicité d'utilisation de cette association, tandis que d'autres ont rencontré certaines difficultés. Pour l'intégration actuelle, votre cluster doit être accessible depuis Internet afin que GitLab puisse y accéder. Pour de nombreuses organisations, cela n'est pas possible, car elles limitent l'accès aux clusters pour des raisons de sécurité, de conformité ou de régulation. Pour contourner ces restrictions, les utilisateurs doivent créer leurs propres outils au-dessus de GitLab, sinon ils ne pourraient pas profiter de cette fonctionnalité.
Aujourd'hui, nous vous présentons GitLab Kubernetes Agent – un nouveau moyen de déployer sur des clusters Kubernetes. L'agent fonctionne à l'intérieur de votre cluster, donc vous n'aurez pas besoin de l'ouvrir à Internet. L'agent coordonne le déploiement en demandant de nouvelles modifications à GitLab, au lieu que GitLab envoie des mises à jour au cluster. Peu importe la méthode GitOps que vous utilisez, GitLab est fait pour vous.
Veuillez noter qu'il s'agit de la première version de l'agent. Actuellement, nous avons mis l'accent sur la configuration et la gestion des déploiements par le code pour GitLab Kubernetes Agent. Certaines fonctionnalités existantes de l'intégration Kubernetes, comme les tableaux de déploiement et les applications gérées par GitLab, ne sont pas encore supportées. , que ces fonctionnalités seront ajoutées à l'agent dans de futures versions, ainsi que de nouvelles intégrations axées sur la sécurité et la conformité.
et .
Accordez aux utilisateurs des permissions de déploiement sans accès au code
(PREMIUM, ULTIMATE, SILVER, GOLD)
Auparavant, le système de permissions dans GitLab ne permettait pas de bien partager les responsabilités au sein de votre équipe entre ceux qui sont responsables du développement et ceux qui sont responsables du déploiement. Avec la version 13.4 de GitLab, vous pouvez donner l'autorisation de valider les merge requests pour le déploiement, ainsi que de déployer effectivement du code à des personnes qui n'écrivent pas de code, tout en ne leur accordant pas les droits d'accès de mainteneur (dans la localisation française de GitLab, « mainteneur »).
et .
Centre de sécurité
(ULTIMATE, GOLD)
Auparavant, la gestion des vulnérabilités au niveau de l'instance était limitée tant en fonctionnalité qu'en flexibilité. L'interface se composait d'une seule page rassemblant les détails des vulnérabilités, des graphiques de métriques et des paramètres. Il n'y avait pas beaucoup de place pour développer ces fonctionnalités ou utiliser d'autres outils de sécurité.
Nous avons apporté des changements fondamentaux à la gestion de la sécurité et à sa transparence dans GitLab. Le tableau de bord de sécurité de l'instance a été transformé en un véritable centre de sécurité. Le plus grand changement est l'introduction d'une nouvelle structure de menu : au lieu d'une seule page, vous voyez maintenant séparément le tableau de bord de sécurité, le rapport sur les vulnérabilités et la section des paramètres. Bien que la fonctionnalité soit restée inchangée, cette division permettra d'améliorer cette section, ce qui aurait été difficile autrement. Cela crée également une base pour l'ajout futur d'autres fonctionnalités liées à la sécurité.
La section dédiée au rapport sur les vulnérabilités dispose maintenant de plus d'espace pour afficher des détails importants. Elle regroupe les vulnérabilités actuellement présentes sur la liste des vulnérabilités du projet. Le transfert des widgets avec les métriques de vulnérabilités dans une section séparée crée un tableau de bord de sécurité pratique. C'est désormais une toile pour de futures visualisations — non seulement pour la gestion des vulnérabilités, mais aussi pour toutes les métriques liées à la sécurité. Enfin, une zone distincte pour les paramètres crée un espace commun pour tous les paramètres de sécurité au niveau de l'instance, pas seulement pour la gestion des vulnérabilités.
et .
Fonctionnalités activables maintenant dans GitLab Starter
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
GitLab 11.4 a été publié . Dans la version 12.2, nous avons introduit des stratégies pour elles et , et dans la version 13.1, nous avons ajouté et pour différents environnements.
Plus tôt cette année, GitLab s'est engagé en open source. Dans cette version, nous avons achevé le transfert des fonctionnalités activables dans le plan Starter et continuerons à les transférer dans le Core avec . Nous sommes ravis d'offrir cette possibilité à un plus grand nombre d'utilisateurs et voulons savoir comment vous allez les utiliser.
et .
Navigation rapide depuis la barre de recherche
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Parfois, lors de la navigation dans GitLab, vous souhaitez accéder directement à un projet spécifique plutôt qu'à la page des résultats de recherche.
Avec le panneau de recherche globale, vous pouvez rapidement accéder aux derniers tickets, groupes, projets, paramètres et sections d'aide. Vous pouvez même utiliser le raccourci clavier /, pour déplacer le curseur vers la barre de recherche, rendant ainsi votre navigation dans GitLab encore plus efficace !
et .
Affichage de la couverture du code dans les différences des demandes de fusion
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Lors de la révision d'une demande de fusion, il peut être difficile de déterminer si le code modifié est couvert par des tests unitaires. Au lieu de cela, les examinateurs peuvent s'appuyer sur la couverture générale et exiger son augmentation avant de valider la demande de fusion. Cela peut entraîner une approche désordonnée en matière d'écriture de tests, ce qui n'améliore en réalité ni la qualité du code ni sa couverture par des tests.
Maintenant, lors de la consultation de la différence d'une demande de fusion, vous verrez une représentation visuelle de la couverture du code. De nouvelles annotations permettront de comprendre rapidement si le code modifié est couvert par le test unitaire, ce qui aidera à accélérer la révision du code ainsi que le temps de fusion et de déploiement du nouveau code.
Merci et Siemens pour cette fonctionnalité !
et .
Plus d'environnements et de projets dans le panneau des environnements
(PREMIUM, ULTIMATE, SILVER, GOLD)
Depuis la version 12.5 de GitLab, grâce au vous pouviez suivre l'état des environnements, mais pas plus de sept environnements dans trois projets. Nous avons amélioré ce panneau dans la version 13.4 en le divisant en pages, afin de vous aider à gérer vos environnements à grande échelle. Vous pouvez désormais voir plus d'environnements dans un plus grand nombre de projets.
et .
GitLab a accepté la gestion du fournisseur GitLab Terraform
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Récemment, nous et prévoyons . Au cours du dernier mois, nous avons accepté 21 demandes de fusion et fermé 31 tickets, y compris certaines anciennes erreurs et fonctionnalités manquantes telles que . Vous pouvez dans la documentation de Terraform.
et .
Tests de fuzzing API avec des spécifications OpenAPI ou un fichier HAR
(ULTIMATE, GOLD)
Le test de fuzzing API est un excellent moyen de détecter des erreurs et des vulnérabilités dans vos applications web et API que d'autres scanners et méthodes de test pourraient manquer.
Le test de fuzzing API dans GitLab permet de fournir ou de votre application, puis génère automatiquement des données d'entrée aléatoires conçues pour tester les cas limites et déceler des erreurs. Les résultats s'affichent immédiatement dans votre pipeline.
C'est notre première version du test de fuzzing API, et nous serions ravis de savoir ce que vous en pensez. Pour le test de fuzzing, nous avons encore , sur lesquelles nous nous baserons pour le lancement de cette fonctionnalité.
et .
Aperçu des nouveaux graphiques sur le tableau de bord des métriques
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Auparavant, créer un graphique sur le tableau de bord des métriques dans GitLab était une tâche complexe. Après avoir créé une métrique dans le fichier YAML du tableau de bord, vous deviez apporter des modifications à master, sans avoir la possibilité de vérifier que le graphique nouvellement créé fonctionne exactement comme vous le souhaitiez. À partir de cette version, vous pouvez prévisualiser les modifications lors de la création du graphique, vous donnant un aperçu du résultat avant de soumettre les modifications au fichier YAML du tableau de bord.
et .
Données de couverture de code par les tests pour tous les projets du groupe
(PREMIUM, ULTIMATE, SILVER, GOLD)
Lorsque vous gérez de nombreux projets dans GitLab, vous avez besoin d'une source unique d'information sur l'évolution de la couverture de code de tous les projets au fil du temps. Auparavant, afficher ces informations nécessitait un travail manuel épuisant et fastidieux : il fallait télécharger les données de couverture de code de chaque projet et les combiner dans un tableau.
Avec la version 13.4, il est désormais possible de rassembler facilement et rapidement dans .csv tous les données de couverture de code de tous les projets du groupe ou d'un échantillon de projets. Cette fonctionnalité est un modèle MVC, suivie de la possibilité .
et .
Prise en charge de nouveaux langages pour des tests de fuzzing complets
(ULTIMATE, GOLD)
Cette version introduit la prise en charge de plusieurs nouveaux langages pour les tests de fuzzing visant une couverture complète.
Vous pouvez désormais évaluer toutes les possibilités du fuzz testing dans vos applications Java, Rust et Swift et détecter les erreurs et vulnérabilités que d'autres analyseurs et méthodes de test peuvent manquer.
et .
Alertes sur la page d'accueil des environnements
(PREMIUM, ULTIMATE, SILVER, GOLD)
La page des environnements montre l'état général de vos environnements. Dans cette version, nous avons amélioré cette page en ajoutant l'affichage des alertes. Les alertes déclenchées, ainsi que l'état de vos environnements, vous aideront à réagir plus rapidement aux situations qui se présentent.
et .
Les pipelines imbriqués peuvent désormais lancer leurs propres pipelines imbriqués
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Avec l'utilisation de pipelines imbriqués, il est désormais possible de lancer de nouveaux pipelines à l'intérieur des pipelines enfants. Ce niveau supplémentaire de profondeur peut être utile si vous avez besoin de flexibilité pour générer un nombre variable de pipelines.
Auparavant, lors de l'utilisation de pipelines imbriqués, chaque pipeline enfant nécessitait un déclencheur défini manuellement dans le pipeline parent. Maintenant, vous pouvez créer des pipelines imbriqués qui déclencheront dynamiquement n'importe quel nombre de nouveaux pipelines imbriqués. Par exemple, si vous avez un monorepo, vous pouvez générer dynamiquement le premier pipeline imbriqué, qui créera lui-même le nombre nécessaire de nouveaux pipelines basés sur les changements dans la branche.
et .
Navigation améliorée entre les pipelines parents et imbriqués
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Auparavant, la navigation entre les pipelines parents et imbriqués n'était pas très pratique — il fallait de nombreux clics pour atteindre le pipeline souhaité. Il était également difficile de comprendre quelle tâche avait déclenché ce pipeline. Maintenant, il sera beaucoup plus facile de voir les relations entre les pipelines parents et imbriqués.
et .
Les tâches de matrice parallèles affichent des variables pertinentes dans le nom de la tâche
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Si vous avez utilisé , vous avez peut-être remarqué qu'il était difficile de déterminer quelle variable de matrice avait été utilisée pour une tâche spécifique, car les noms des tâches ressemblaient à matrix 1/4Dans la version 13.4, vous verrez les valeurs pertinentes des variables qui ont été utilisées dans cette tâche, au lieu du nom générique de la tâche. Par exemple, si votre objectif est le débogage pour l'architecture x86, alors la tâche s'appellera matrix: debug x86.
et .
Autres améliorations dans GitLab 13.4
Connexion du compte Atlassian
(CORE, STARTER, PREMIUM, ULTIMATE)
Les utilisateurs de GitLab peuvent désormais connecter leurs comptes GitLab à leur compte Atlassian Cloud. Cela permettra de se connecter à GitLab avec les identifiants Atlassian et jettera les bases pour de futures améliorations de l'intégration et d'autres produits de la gamme Atlassian.
et .
Exporter la liste de tous les commits de fusion
(ULTIMATE, GOLD)
Les organisations soucieuses de la conformité ont besoin d'un moyen de montrer aux auditeurs une vue d'ensemble complète des composants liés à tout changement spécifique en production. Dans le cadre de GitLab, cela signifie rassembler en un seul endroit tout : les demandes de fusion, les tickets, les pipelines, les analyses de sécurité et d'autres données sur le commit. Jusqu'à présent, vous deviez soit rassembler cela manuellement dans GitLab, soit configurer vos outils pour collecter les informations, ce qui n'était pas très efficace.
Vous pouvez désormais collecter et exporter ces données par programmation pour répondre aux exigences d'audit ou effectuer d'autres analyses. Pour exporter la liste de tous les commits de fusion pour le groupe actuel, vous devez vous rendre dans et cliquer sur le bouton Liste de tous les commits de fusion. Le fichier résultant contiendra tous les commits des demandes de fusion, leur auteur, l'ID de la demande de fusion associée, le groupe, le projet, et d'autres informations sur la validation.
et .
Sortie de la liste et gestion des jetons d'accès personnels via l'API
(ULTIMATE, GOLD)
La gestion de l'accès à l'espace de noms GitLab est une partie essentielle de l'activité de conformité. Des principes de moindre privilège à la désactivation de l'accès basé sur des délais - plusieurs exigences peuvent être liées aux jetons d'accès personnels dans GitLab. Pour faciliter la maintenance et la gestion de toutes ces informations d'identification utilisateur dans votre espace de noms, nous avons fourni la possibilité d'afficher la liste de tous les jetons d'accès personnels et de manière optionnelle. via l'API.
Ces améliorations de l'API GitLab permettent aux utilisateurs de lister et de révoquer leurs propres jetons d'accès personnels, tandis que les administrateurs peuvent lister et révoquer les jetons de leurs utilisateurs. Cela facilitera la tâche aux administrateurs pour voir qui a accès à leur espace de noms, prendre des décisions sur l'octroi d'accès en fonction des données des utilisateurs, ainsi que révoquer les jetons d'accès personnels qui pourraient avoir été compromis ou qui ne respectent pas les politiques de gestion des accès de l'entreprise.
et .
Tickets associés et autres fonctionnalités désormais dans GitLab Core
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Il y a quelques mois, nous avons annoncé un plan pour . En travaillant à la réalisation de cette promesse, nous avons créé , et (dans la localisation russe de GitLab, « tableau de discussion ») disponibles dans le plan Core. Cela ne s'applique qu'aux relations de type « associé à », tandis que les relations de type « bloque » et « bloqué par » restent dans les plans payants.
et .
Affichage du nom de la branche source dans la barre latérale de la demande de fusion
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Lors de la révision des modifications de code, des discussions et des commits de la demande de fusion, il est souvent souhaitable de faire un checkout local de la branche pour une révision plus approfondie. Cependant, trouver le nom de la branche devient de plus en plus difficile à mesure que le contenu de la description de la demande de fusion s'allonge.
Nous avons ajouté le nom de la branche dans la barre latérale de la demande de fusion, le rendant accessible à tout moment et éliminant le besoin de faire défiler toute la page. Tout comme le lien vers la demande de fusion, la section avec la branche source contient un bouton pratique « copier ».
Merci pour sa contribution exceptionnelle au développement de cette fonctionnalité !
et .
Indication de la présence de fichiers repliés dans les diff de la demande de fusion
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Les demandes de fusion qui apportent des modifications à plusieurs fichiers compressent parfois les différences des fichiers volumineux afin d'améliorer les performances d'affichage. Lorsque cela se produit, il est possible de manquer accidentellement un fichier lors de la révision, en particulier dans les demandes de fusion contenant de nombreux fichiers. À partir de la version 13.4, les demandes de fusion marqueront les différences contenant des fichiers compressés, ce qui vous permettra de ne pas manquer ces fichiers lors de la révision du code. Pour encore plus de clarté, nous prévoyons d'ajouter une mise en évidence de ces fichiers dans une future version. Restez à l'écoute des mises à jour dans .
et .
Avertissement concernant les fichiers compressés dans les différences de la demande de fusion
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Dans la section des différences des demandes de fusion, les fichiers volumineux sont compressés pour améliorer les performances. Cependant, lors de la révision du code, certains fichiers peuvent être manqués lorsque le réviseur parcourt la liste des fichiers, car tous les fichiers volumineux sont compressés.
Nous avons ajouté un avertissement visible en haut de la page des différences de la demande de fusion pour informer les utilisateurs qu'il existe un fichier compressé dans cette section. Ainsi, vous ne manquerez aucune modification dans la demande de fusion lors de la révision.
et .
Récupération automatique du dépôt du cluster Gitaly
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Auparavant, lorsque le nœud principal du cluster Gitaly était déconnecté, les dépôts sur ce nœud étaient marqués comme disponibles en lecture seule. Cela empêchait la perte de données dans les situations où des modifications avaient été effectuées sur le nœud et n'avaient pas encore été répliquées. Lorsque le nœud se reconnectait, GitLab ne se rétablissait pas automatiquement, et les administrateurs devaient lancer manuellement le processus de synchronisation ou accepter la perte de données. D'autres situations, telles que l'échec d'une tâche de réplication sur un nœud secondaire, pouvaient également conduire à des dépôts obsolètes ou disponibles en lecture seule. Dans ce cas, le dépôt restait obsolète jusqu'à ce qu'une opération d'écriture suivante soit effectuée, déclenchant la tâche de réplication.
Pour résoudre ce problème Il planifie désormais une tâche de réplication lorsqu'il détecte un dépôt obsolète sur un nœud et la dernière version du dépôt sur un autre. Cette tâche de réplication met automatiquement à jour le dépôt, ce qui élimine le besoin de restaurer manuellement les données. La restauration automatique permet également de remettre rapidement les nœuds secondaires à jour si la tâche de réplication échoue, au lieu d'attendre la prochaine opération d'écriture. Étant donné que de nombreux clusters Gitaly stockent un grand nombre de dépôts, cela réduit considérablement le temps que les administrateurs et les ingénieurs en fiabilité consacrent à la récupération des données après une erreur.
De plus, la réparation automatique déclenche la réplication des dépôts sur tout nouveau nœud Gitaly ajouté au cluster, ce qui élimine le travail manuel lors de l'ajout de nouveaux nœuds.
et .
Marquez la tâche à faire comme réalisée sur la page de conception
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Une communication efficace dans GitLab repose sur des listes de tâches à faire. Si vous êtes mentionné dans un commentaire, il est crucial d'avoir la possibilité de passer à la tâche et de soit commencer à travailler, soit la marquer comme déjà réalisée. Il est également important de pouvoir s'assigner une tâche lorsque vous devez travailler sur quelque chose ou y revenir plus tard.
Auparavant, vous ne pouviez pas ajouter des tâches ou les marquer comme terminées en travaillant sur des conceptions. Cela perturbait gravement l'efficacité de la communication entre les équipes produits, car les tâches à faire sont un élément crucial du flux de travail dans GitLab.
Dans la version 13.4, les conceptions rattrapent les commentaires sur les tickets en termes d'utilisation des tâches, rendant leur utilisation plus cohérente et efficace.
et .
Guide amélioré de dépannage pour CI/CD
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Nous avons amélioré le guide de dépannage pour GitLab CI/CD en ajoutant des informations supplémentaires sur les problèmes courants que vous pourriez rencontrer. Nous espérons que la documentation améliorée sera une ressource précieuse pour vous aider à configurer et à exécuter rapidement et facilement GitLab CI/CD.
et .
Les demandes de fusion ne tombent plus de la file d'attente des fusions
(PREMIUM, ULTIMATE, SILVER, GOLD)
Auparavant, les demandes de fusion pouvaient tomber de la file d'attente par accident en raison de commentaires tardifs. Si la demande de fusion était déjà dans la file d'attente et que quelqu'un ajoutait un commentaire créant une nouvelle discussion non résolue, la demande de fusion était considérée comme non valide pour la fusion et tombait de la file d'attente. Maintenant, après qu'une demande de fusion soit ajoutée à la file d'attente, de nouveaux commentaires peuvent être ajoutés sans craindre d'interrompre le processus de fusion.
et .
Affichage dans la demande de fusion de la valeur de couverture du code pour la tâche
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Les développeurs doivent pouvoir voir la valeur de couverture du code après la fin du pipeline, même dans des scénarios complexes tels que lorsque le pipeline fonctionne avec plusieurs tâches qu'il faut analyser pour calculer la valeur de couverture. Auparavant, le widget de la demande de fusion affichait seulement une moyenne de ces valeurs, ce qui signifiait qu'il fallait naviguer vers la page de la tâche puis revenir à la demande de fusion pour obtenir les valeurs intermédiaires de couverture. Pour vous faire gagner du temps et vous éviter ces étapes superflues, nous avons ajouté dans le widget l'affichage de la moyenne de couverture, ainsi que son évolution entre les branches cible et source, et un infobulle montrant la valeur de couverture pour chaque tâche, sur la base de laquelle la moyenne a été calculée.
et .
Suppression des paquets du registre des paquets lors de la visualisation d'un groupe
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Le registre des paquets GitLab est un endroit pour stocker et distribuer des paquets dans différents formats. Lorsque votre projet ou groupe contient de nombreux paquets, vous devez rapidement identifier les paquets inutilisés et les supprimer afin d'éviter qu'ils ne soient téléchargés par d'autres utilisateurs. Vous pouvez supprimer des paquets de votre registre via ou via l'interface utilisateur du registre des paquets. Cependant, jusqu'à présent, vous n'avez pas pu supprimer des paquets lors de la visualisation d'un groupe via l'interface utilisateur. En conséquence, vous deviez supprimer les paquets superflus un par un pour chaque projet, ce qui était inefficace.
Maintenant, vous pouvez supprimer des paquets en visualisant le registre des paquets du groupe. Il vous suffit de vous rendre sur la page du registre des paquets du groupe, de filtrer les paquets par nom et de supprimer tous ceux qui ne sont pas nécessaires.
et .
Mise à l'échelle des paquets Conan au niveau du projet
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Vous pouvez utiliser le dépôt Conan dans GitLab pour publier et distribuer des dépendances C/C++. Cependant, auparavant, les paquets ne pouvaient être mis à l'échelle qu'au niveau d'une instance, car le nom du paquet Conan pouvait contenir au maximum 51 caractères. Si vous vouliez publier un paquet depuis un sous-groupe, par exemple gitlab-org/ci-cd/package-stage/feature-testing/conan, cela était presque impossible.
Maintenant, vous pouvez mettre à l'échelle des paquets Conan au niveau du projet, ce qui permet de publier et de distribuer facilement les dépendances de vos projets.
et .
Support de nouveaux gestionnaires de paquets et langages pour l'analyse des dépendances
(ULTIMATE, GOLD)
Nous sommes ravis d'ajouter l'analyse des dépendances pour les projets écrits en C, C++, C# et .Net, utilisant NuGet 4.9+ ou des gestionnaires de paquets Conan, à notre liste . Vous pouvez maintenant inclure l'analyse des dépendances comme partie de l'étape Secure, afin de vérifier les dépendances ajoutées via des gestionnaires de paquets pour des vulnérabilités connues. Les vulnérabilités trouvées s'afficheront dans votre merge request avec le niveau de leur dangerosité, vous permettant de connaître les risques potentiels d'une nouvelle dépendance avant l'exécution du merge. Vous pouvez également configurer votre projet pour exiger pour les dépendances présentant des vulnérabilités de niveau critique (Critical), élevé (High) ou inconnu (Unknown).
et .
Notifications lors du changement de la configuration de merge request à 'Fusionner lors de la réussite du pipeline'
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Auparavant, dans la configuration de la merge request Fusionner quand le pipeline se termine (Merge When Pipeline Succeeds, MWPS) aucune notification par email n'était envoyée. Vous deviez vérifier manuellement l'état ou attendre une notification de l'exécution du merge. Dans cette version, nous sommes ravis de présenter la contribution de l'utilisateur , qui a résolu ce problème en ajoutant l'envoi automatique de notifications à tous ceux qui sont abonnés à la merge request lorsque le réviseur change la configuration de merge en MWPS.
et .
Création de clusters EKS avec une version Kubernetes spécifiée par l'utilisateur
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Les utilisateurs de GitLab peuvent désormais choisir la version de Kubernetes qui sera fournie par EKS ; vous pouvez choisir entre les versions 1.14 à 1.17.
et .
Création d'incidents en tant que types de tickets
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Chaque problème rencontré ne déclenche pas immédiatement l'envoi d'alertes : les utilisateurs signalent des pannes, tandis que les membres des équipes analysent les problèmes de performance. Désormais, les incidents sont une forme de ticket, ce qui permettra à vos équipes de les créer rapidement dans le cadre de leur flux de travail habituel. Cliquez sur Nouvelle tâche de n'importe où dans GitLab, et dans le champ Type sélectionnez Incident.
et .
Mention des alertes GitLab en Markdown
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Nous avons amélioré les alertes GitLab en ajoutant un nouveau type de mention spécialement pour elles en version Markdown de GitLab, ce qui facilite le partage des alertes et leur mention. Utilisez ^alert#1234, pour mentionner une alerte dans n'importe quel champ avec un balisage Markdown : dans les incidents, tickets ou demandes de merge. Cela vous aidera également à identifier les tâches créées à partir d'alertes, et non de tickets ou de demandes de merge.
et .
Consultation de la charge des alertes des incidents
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
La description de l'alerte contient des informations critiques pour le diagnostic des pannes et la récupération, et ces informations doivent être facilement accessibles afin que vous n'ayez pas à changer d'outils ou d'onglets en travaillant sur la résolution d'un incident. Les incidents créés à partir d'alertes affichent la description complète de l'alerte dans l'onglet Détails de l'alerte.
Recherche avancée 75 % plus rapide
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
GitLab, en tant qu'application unique, a la capacité unique de rendre la recherche de contenu dans l'ensemble du flux de travail DevOps rapide. Dans GitLab 13.4, la recherche avancée fournit des résultats 75 % plus rapidement lorsqu'elle , comme sur GitLab.com.
et .
Consultation des projets supprimés pour les administrateurs
(CORE, STARTER, PREMIUM, ULTIMATE)
La possibilité de reporter la suppression d'un projet a été Cependant, auparavant, il n'était pas possible de voir en un seul endroit tous les projets en attente de suppression. Désormais, les administrateurs des instances GitLab peuvent consulter tous les projets en attente de suppression au même endroit, avec des boutons pour restaurer facilement ces projets.
Cette fonctionnalité permet aux administrateurs de mieux contrôler la suppression des projets en rassemblant toutes les informations nécessaires en un seul endroit et en offrant la possibilité d'annuler des actions de suppression indésirables.
Merci pour cette fonctionnalité !
et .
Le support des règles de push pour le groupe a été ajouté dans l'API
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
Auparavant, les règles de push de groupe ne pouvaient être configurées qu'en visitant chaque groupe individuellement via l'interface utilisateur de GitLab et en appliquant ces règles. Maintenant, vous pouvez gérer ces règles via l'API pour soutenir vos outils personnalisés et automatiser GitLab.
et .
Révocation des jetons d'accès personnels pour le stockage de crédits autogéré
(ULTIMATE)
fournit aux administrateurs les informations nécessaires pour gérer les crédits des utilisateurs de leur instance GitLab. Étant donné que les organisations centrées sur la conformité diffèrent par la rigueur de leurs règles de gestion des crédits, nous avons ajouté un bouton permettant aux administrateurs de révoquer, si nécessaire, le jeton d'accès personnel (PAT) d'un utilisateur. Désormais, les administrateurs peuvent facilement révoquer des PAT potentiellement compromis. Cette fonctionnalité est utile pour les organisations qui ont besoin d'options plus flexibles pour garantir le respect des exigences afin de minimiser les distractions pour leurs utilisateurs.
et .
Fichier de configuration pour l'éditeur de sites statiques
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Dans GitLab 13.4, nous introduisons une nouvelle manière de configurer l'éditeur de sites statiques. Bien que le fichier de configuration ne conserve ni ne récupère aucun paramètre dans cette version, nous posons les bases pour une configuration future du comportement de l'éditeur. Dans les versions suivantes, nous ajouterons dans le fichier .gitlab/static-site-editor.yml des paramètres pour définir , sur lequel , redéfinition des paramètres de syntaxe Markdown et d'autres paramètres de l'éditeur.
et .
Édition de la partie d'introduction du fichier avec l'éditeur de sites statiques
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
La partie d'introduction (front matter) est un moyen flexible et pratique de définir des variables de page dans des fichiers de données destinés à être traités par un générateur de sites statiques. Elle est généralement utilisée pour définir le titre de la page, le modèle de mise en page ou l'auteur, mais peut également être utilisée pour passer tout type de métadonnées au générateur lors du rendu de la page en HTML. Inclusions au tout début de chaque fichier de données, la partie d'introduction est généralement formatée en YAML ou JSON et nécessite une syntaxe cohérente et précise. Les utilisateurs peu familiers avec les règles syntaxiques spécifiques peuvent introduire involontairement une mise en forme invalide, ce qui peut entraîner des problèmes de formatage ou même des échecs de construction.
Le mode d'édition WYSIWYG de l'éditeur de sites statiques retire déjà la partie d'introduction de l'éditeur pour prévenir ces erreurs de formatage. Cependant, cela ne vous permet pas de modifier les valeurs stockées dans cette partie sans basculer en mode édition de code source. Dans GitLab 13.4, vous pouvez accéder à n'importe quel champ et éditer sa valeur dans une interface familière basée sur des formulaires. En appuyant sur le bouton Paramètres (Settings) un panneau s'ouvrira affichant le champ de formulaire pour chaque clé définie au début. Les champs sont remplis avec la valeur actuelle, et pour modifier l'un d'eux, il suffit de la saisir dans le formulaire web. Cette édition de la partie d'introduction permet d'éviter les complexités de syntaxe et vous donne un contrôle total sur le contenu, tout en garantissant un formatage uniforme du résultat final.
et .
GitLab pour Jira et DVCS Connector maintenant dans Core
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Pour les utilisateurs de Jira dans GitLab : et permettent d'afficher des informations sur les commits et les merge requests de GitLab directement dans Jira. En combinaison avec notre intégration intégrée avec Jira, vous pouvez facilement naviguer entre les deux applications pendant votre travail.
Ces fonctionnalités étaient auparavant disponibles uniquement dans notre plan Premium, mais elles sont maintenant accessibles à tous les utilisateurs !
et .
Vote majoritaire pour les transactions du cluster Gitaly (version bêta)
(CORE, STARTER, PREMIUM, ULTIMATE)
Le cluster Gitaly permet de répliquer des dépôts Git sur plusieurs nœuds Gitaly « chauds ». Cela améliore la résilience en éliminant les points de défaillance uniques. , introduites dans GitLab 13.3, déclenchent une diffusion large des modifications sur tous les nœuds Gitaly du cluster, mais seuls les nœuds Gitaly qui votent en accord avec le nœud principal conservent les modifications sur disque. Si tous les nœuds répliques ne parviennent pas à un consensus, une seule copie de la modification sera enregistrée sur disque, créant un point de défaillance unique jusqu'à l'achèvement de la réplication asynchrone.
Le vote majoritaire augmente la résilience en exigeant le consensus de la majorité des nœuds (et non de tous) avant de sauvegarder les modifications sur disque. Si cette fonctionnalité commutée est activée, l'enregistrement doit réussir sur plusieurs nœuds. Les nœuds non d'accord se synchronisent automatiquement par réplication asynchrone avec les nœuds ayant formé un quorum.
et .
Support d'un schéma personnalisé pour la validation JSON dans Web IDE
(PREMIUM, ULTIMATE, SILVER, GOLD)
Les projets où les gens écrivent des configurations au format JSON ou YAML sont souvent sujets à des problèmes, car il est facile de faire une faute de frappe et de casser quelque chose. Vous pouvez écrire des outils de vérification qui détectent ces problèmes dans le pipeline CI, mais utiliser un fichier de schéma JSON peut s'avérer utile pour fournir de la documentation et des suggestions.
Les participants au projet peuvent définir dans leur dépôt le chemin vers le schéma personnalisé dans le fichier .gitlab/.gitlab-webide.yml, qui indique le schéma et le chemin vers les fichiers à valider. Lors du chargement d'un fichier spécifique dans Web IDE, des retours et des vérifications supplémentaires seront visibles pour aider à créer le fichier.
et .
Le plafond de bifurcation des graphes acycliques dirigés (DAG) a été porté à 50
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Si vous utilisez des pipelines (Directed Acyclic Graph (DAG)), vous avez peut-être remarqué que la limite de 10 tâches que la tâche peut indiquer dans needs:, trop strict. Dans la version 13.4, la limite par défaut a été augmentée de 10 à 50 pour permettre des réseaux de dépendances plus complexes entre les tâches de vos pipelines.
Si vous êtes administrateur d'une instance GitLab, vous pouvez augmenter cette limite encore plus en configurant une fonctionnalité optionnelle, bien que nous ne reflétions pas de support officiel pour cela.
et .
Comportement amélioré besoins pour les tâches manquées
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Dans certains cas, une tâche manquée dans le pipeline pouvait être incorrectement considérée comme réussie pour les dépendances spécifiées dans besoins, ce qui entraînait le démarrage des tâches suivantes, ce qui ne devrait pas se produire. Ce comportement a été corrigé dans la version 13.4, et besoins traite maintenant correctement les cas de tâches manquées.
et .
Verrouillez le dernier artefact de tâche pour éviter sa suppression
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab verrouille désormais automatiquement le dernier artefact d'une tâche et d'un pipeline sur n'importe quelle branche active, demande de fusion ou balise, pour éviter sa suppression après expiration. Il devient plus simple d'établir des règles d'expiration plus agressives pour nettoyer les vieux artefacts. Cela aide à réduire la consommation d'espace disque et garantit que vous disposez toujours d'une copie du dernier artefact du pipeline.
et .
Guide CI/CD pour l'optimisation des pipelines
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
L'optimisation des pipelines CI/CD peut améliorer la vitesse de livraison et réduire les coûts. Nous avons amélioré notre documentation en ajoutant un guide succinct pour maximiser les bénéfices de l'optimisation de vos pipelines.
et .
Le rapport de test est trié par statut du test
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
C'est un moyen simple de voir les résultats de tous les tests dans le pipeline. Cependant, avec un grand nombre de tests, trouver les tests échoués peut prendre beaucoup de temps. D'autres problèmes qui peuvent rendre l'utilisation du rapport difficile incluent les difficultés de défilement des longues sorties de traçage et l'arrondi du temps à zéro pour les tests exécutés en moins d'une seconde. Maintenant, par défaut, le rapport de test place d'abord les tests échoués en haut du rapport, puis classe les tests par durée. Cela facilite la recherche des échecs et des tests longs. De plus, la durée des tests est maintenant affichée en millisecondes ou en secondes, ce qui rend leur lecture beaucoup plus rapide, et les problèmes de défilement précédents ont également été résolus.
et .
Limites de taille des fichiers chargés dans le registre de paquets
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Il existe maintenant des limites sur la taille des fichiers de paquets pouvant être chargés dans le registre de paquets GitLab. Des limites ont été ajoutées pour optimiser les performances du registre de paquets et éviter les abus. Les limites dépendent du format du paquet. Pour GitLab.com, les tailles maximales des fichiers sont :
- Conan : 250 Mo
- Maven : 3 Go
- NPM : 300 Mo
- NuGet : 250 Mo
- PyPI : 3 Go
Pour les instances GitLab personnalisées, les valeurs par défaut sont les mêmes. Cependant, l'administrateur peut mettre à jour les limites via .
et .
Utilisez CI_JOB_TOKEN pour publier des paquets PyPI
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Vous pouvez utiliser le registre GitLab PyPI pour créer, publier et partager des paquets Python avec le code source et les pipelines CI/CD. Cependant, auparavant, vous ne pouviez pas vous authentifier dans le registre à l'aide d'une variable d'environnement prédéfinie CI_JOB_TOKEN. En conséquence, vous deviez utiliser vos identifiants personnels pour mettre à jour le registre PyPI, ou vous choisissiez peut-être de ne pas utiliser le registre du tout.
Il est maintenant plus facile d'utiliser GitLab CI/CD pour publier et installer des paquets PyPI à l'aide d'une variable d'environnement prédéfinie. CI_JOB_TOKEN.
et .
Profils de scanner DAST à la demande
(ULTIMATE, GOLD)
Pour le scan DAST à la demande, qui a été , des profils de scanner DAST ont été ajoutés. Ils élargissent les possibilités de configuration de cette analyse, permettant de créer rapidement plusieurs profils pour couvrir différents types d'analyse. Dans la version 13.4, le profil du scanner inclut à l'origine un paramètre de délai d'attente pour le robot d'exploration, qui détermine combien de temps le robot DAST doit fonctionner lorsqu'il essaie de découvrir toutes les pages du site analysé. Le profil comprend également un paramètre de délai d'attente pour le site cible, afin de définir combien de temps le scanner doit attendre avant d'interrompre l'analyse si le site ne répond pas avec un code d'état 200 ou 300. Au fur et à mesure que nous améliorerons encore cette fonctionnalité dans les prochaines versions, d'autres paramètres de configuration seront ajoutés au profil du scanner.
et .
Un simple fichier de configuration de redirections pour GitLab Pages
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Si vous utilisez GitLab Pages et souhaitez mieux gérer les changements d'URL, vous avez peut-être remarqué qu'il était impossible de gérer les redirections sur votre site GitLab Pages. GitLab permet désormais de configurer des règles pour rediriger une URL vers une autre pour votre site Pages en ajoutant un fichier de configuration dans le référentiel. Cette fonctionnalité a été rendue possible grâce à la participation de Kevin Barnett (), notre Eric Eastwood () et l'équipe GitLab. Merci à tous pour votre contribution.
et .
État Terraform géré par GitLab
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
L'accès aux versions précédentes de l'état Terraform est nécessaire à la fois pour les besoins de conformité et pour le débogage si nécessaire. La prise en charge de la gestion des versions de l'état Terraform géré par GitLab est disponible à partir de GitLab 13.4. La gestion des versions est activée automatiquement pour les nouveaux fichiers d'état Terraform. Les fichiers d'état Terraform existants seront dans une version ultérieure.
et .
Détails importants sur les alertes d'incidents
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Lors du traitement des incidents, vous devez facilement identifier combien de temps une alerte a été ouverte et combien de fois un événement s'est produit. Ces détails sont souvent cruciaux pour déterminer l'impact sur le client et ce que votre équipe doit prioriser. Sur le nouveau panneau des détails de l'incident, nous affichons l'heure de début de l'alerte, le nombre d'événements et un lien vers l'alerte d'origine. Ces informations sont disponibles pour les incidents générés à partir des alertes.
et .
Configuration et modification du paramètre de gravité de l'incident
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Le paramètre 'gravité de l'incident' permet aux spécialistes de la réponse et aux parties prenantes d'évaluer l'impact de l'interruption de service, ainsi que les méthodes et l'urgence de la réponse. Au fur et à mesure que votre équipe partage ses résultats pendant la résolution de l'incident et la restauration du service, elle peut modifier ce paramètre. Vous pouvez désormais éditer la gravité de l'incident dans le panneau latéral droit de la page 'Détails de l'incident', et le niveau de gravité est affiché dans la liste des incidents.
et .
Création, modification et suppression des règles de sécurité réseau des conteneurs
(ULTIMATE, GOLD)
Cette amélioration de l'éditeur de règles de sécurité réseau des conteneurs permet aux utilisateurs de créer, modifier et supprimer facilement leurs règles directement depuis l'interface utilisateur de GitLab. Les fonctionnalités de l'éditeur incluent le mode .yaml pour les utilisateurs expérimentés et un éditeur de règles avec une interface intuitive pour ceux qui sont moins familiers avec les règles réseau. Vous pouvez trouver de nouvelles options de gestion des règles dans la section Sécurité et conformité > Gestion des menaces > Règles (Sécurité & Conformité > Gestion des menaces > Politiques).
et .
Prise en charge du stockage d'objets blob Azure
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab et GitLab Runner prennent désormais en charge , ce qui facilite le déploiement des services GitLab dans Azure.
Les instances de GitLab prennent en charge Azure pour tous les types de stockage d'objets, y compris les fichiers LFS, les artefacts CI et . Pour configurer le stockage d'objets blob Azure, suivez les instructions d'installation ou .
Les gestionnaires de tâches GitLab prennent également en charge Azure pour le stockage Le stockage Azure peut être configuré via la section .
et .
Packages Omnibus ARM64 pour Ubuntu et OpenSUSE
(CORE, STARTER, PREMIUM, ULTIMATE)
En réponse à la demande croissante de support pour le lancement de GitLab sur l'architecture ARM 64 bits, nous sommes heureux d'annoncer la disponibilité du package officiel Ubuntu 20.04 Omnibus ARM64. Un grand merci à Zitai Chen et Guillaume Gardet pour leur précieuse contribution — leurs demandes de fusion ont joué un rôle clé à cet égard !
Pour télécharger et installer le package pour Ubuntu 20.04, rendez-vous sur notre et sélectionnez Ubuntu.
et .
Support de l'authentification via cartes intelligentes pour le chart Helm de GitLab
(PREMIUM, ULTIMATE)
Les cartes intelligentes, comme les cartes d'accès commun (CAC), peuvent désormais être utilisées pour l'authentification sur une instance de GitLab déployée via un chart Helm. Les cartes intelligentes s'authentifient dans la base de données locale à l'aide de certificats X.509. Grâce à cela, le support des cartes intelligentes dans le chart Helm est désormais conforme au support des cartes intelligentes disponible dans les déploiements Omnibus.
et .
Des notes de version détaillées et des instructions de mise à jour/in installation peuvent être lues dans le post original en anglais : .
La traduction de l'anglais a été réalisée par , , et .
Source : habr.com
