La version 13.4 a été publiée avec le stockage HashiCorp pour les variables CI, l'agent Kubernetes et le centre de sécurité, ainsi que des fonctionnalités commutables dans Starter
Chez GitLab, nous réfléchissons toujours à la manière dont nous pouvons aider les utilisateurs à réduire les risques, à améliorer l'efficacité et à améliorer la vitesse de livraison sur votre plateforme préférée. Ce mois-ci, nous avons ajouté de nombreuses nouvelles fonctionnalités utiles qui étendent les capacités de sécurité, réduisent le nombre de vulnérabilités, augmentent l'efficacité, simplifient le travail avec GitLab et aident votre équipe à fournir des fonctionnalités encore plus rapidement. Nous espérons que les principales fonctionnalités de cette version vous seront utiles, ainsi que 53 autres nouveautés, ajouté dans cette version.
Fonctionnalités de sécurité avancées
Nous essayons d'ajouter plusieurs nouvelles fonctionnalités à GitLab DevSecOps chaque mois, et cette version ne fait pas exception. dans le cadre de l'assemblage et du déploiement. De plus, les organisations qui souhaitent prendre en charge la séparation des responsabilités de déploiement de code peuvent désormais . Ce rôle correspond et vous permettra de confirmer les demandes de fusion (dans la localisation russe de GitLab « demandes de fusion ») et de déployer du code dans des environnements protégés, sans donner accès à la modification du code lui-même.
Une autre façon de réduire les risques consiste à utiliser de nouveaux . Les équipes opérationnelles peuvent déployer des clusters Kubernetes depuis GitLab sans avoir à exposer leur cluster à l'ensemble d'Internet. Nous introduisons également la prise en charge du contrôle de version automatique pour les nouveaux fichiers d'état Terraform avec pour prendre en charge la conformité et la facilité de débogage. Enfin, le tableau de bord de sécurité de l'instance est devenu avec des rapports de vulnérabilité et des paramètres de sécurité.
Travail plus pratique et efficace avec GitLab
Nous avons amélioré notre recherche globale pour inclure , vous permettant de naviguer facilement vers les derniers tickets, groupes, projets, paramètres et rubriques d'aide. Nous sommes ravis d'annoncer que les pages GitLab pour rediriger des pages et des répertoires individuels au sein du site, ce qui permettra aux utilisateurs de déployer plus efficacement leurs sites. Et pour ceux qui souhaitent recevoir des informations détaillées sur le déploiement, cette version permet !
Contributions open source
Nous représentons que j'ai ajouté . Les marques sur la couverture des tests unitaires du code modifié donnent aux développeurs une idée claire de la couverture du code lors de la révision ; ces informations permettent d'accélérer les révisions et de réduire le temps de fusion et de déploiement du nouveau code. Et nous aussi et planifier .
Et ce n'est que le début!
Comme toujours, il y a trop peu d'espace dans l'aperçu général, mais la version 13.4 contient de nombreuses fonctionnalités intéressantes. En voici quelques autres :
- .
Si vous souhaitez savoir à l'avance ce qui vous attend suivant relâchez, jetez un oeil .
.
ce mois-ci -
Fabio a contribué de manière significative в - une fonctionnalité attendue depuis très longtemps dans la communauté GitLab. Il s'agit d'une contribution vraiment importante avec des changements non triviaux qui ont nécessité une collaboration constante avec les membres de l'équipe GitLab et ont affecté de nombreux domaines du projet tels que l'UX, le front-end et le back-end.
Principales fonctionnalités de la version GitLab 13.4
Utiliser les clés HashiCorp Vault dans les tâches CI
(PREMIUM, ULTIME, ARGENT, OR)
Dans la version 12.10, GitLab a introduit la possibilité de recevoir et de transférer des clés vers des tâches CI à l'aide du gestionnaire de tâches GitLab (GitLab runner). Maintenant, nous nous agrandissons , ajoutant une nouvelle syntaxe secrets déposer .gitlab-ci.yml. Cela facilitera la configuration et l'utilisation du référentiel HashiCorp avec GitLab.
и .
Présentation de l'agent GitLab Kubernetes
(PREMIUM, ULTIME)
L'intégration de GitLab avec Kubernetes permet depuis longtemps de déployer sur des clusters Kubernetes sans avoir besoin de configuration manuelle. De nombreux utilisateurs ont apprécié la facilité d'utilisation de cet ensemble, tandis que d'autres ont rencontré quelques difficultés. Pour l'intégration actuelle, votre cluster doit être accessible depuis Internet pour que GitLab puisse y accéder. Pour de nombreuses organisations, cela n'est pas possible car elles restreignent l'accès aux clusters pour des raisons de sécurité, de conformité ou de réglementation. Pour contourner ces restrictions, les utilisateurs devaient créer leurs outils sur GitLab, sinon ils ne pourraient pas utiliser cette fonctionnalité.
Aujourd'hui, nous présentons l'agent GitLab Kubernetes, une nouvelle façon de déployer sur des clusters Kubernetes. L'agent s'exécute à l'intérieur de votre cluster, vous n'avez donc pas besoin de l'exposer à l'ensemble d'Internet. L'agent coordonne le déploiement en demandant de nouvelles modifications à GitLab, plutôt que GitLab envoyant des mises à jour au cluster. Quelle que soit la méthode GitOps que vous utilisez, GitLab a ce qu'il vous faut.
Veuillez noter qu'il s'agit de la première version de l'agent. Notre objectif actuel pour GitLab Kubernetes Agent est de configurer et de gérer les déploiements via du code. Certaines fonctionnalités d'intégration Kubernetes existantes, telles que les cartes de déploiement et les applications gérées par GitLab, ne sont pas encore prises en charge. que ces fonctionnalités seront ajoutées à l'agent dans les prochaines versions, ainsi que de nouvelles intégrations axées sur la sécurité et la conformité.
и .
Accorder aux utilisateurs des autorisations de déploiement sans accès au code
(PREMIUM, ULTIME, ARGENT, OR)
Auparavant, le système d'autorisations de GitLab rendait difficile la répartition correcte des responsabilités au sein de votre équipe entre les responsables du développement et ceux responsables du déploiement. Avec la sortie de GitLab 13.4, vous pouvez donner l'autorisation d'approuver les demandes de fusion pour le déploiement, ainsi que de déployer réellement du code à des personnes qui n'écrivent pas le code, sans leur donner les droits d'accès du responsable (dans la localisation russe de GitLab « mainteneur » ).
и .
Centre de sécurité
(ULTIME, OR)
Auparavant, la gestion des vulnérabilités au niveau des instances était limitée en termes de fonctionnalités et de flexibilité. L'interface était une seule page combinant les détails des vulnérabilités, des graphiques de métriques et des paramètres. Il n'y a pas beaucoup de place pour développer ces fonctionnalités ou utiliser d'autres fonctionnalités de sécurité.
Nous avons apporté des changements fondamentaux à la façon dont nous gérons la sécurité et la transparence dans GitLab. Le panneau de sécurité de l'instance a été transformé en un centre de sécurité complet. Le changement le plus important est l'introduction d'une nouvelle structure de menu : au lieu d'une seule page, vous voyez désormais séparément le tableau de bord de sécurité, le rapport de vulnérabilité et la section des paramètres. Bien que la fonctionnalité n'ait pas changé, la diviser en plusieurs parties permettra d'apporter des améliorations à cette section qui seraient autrement difficiles. Cela ouvre également la voie à l’ajout d’autres fonctionnalités liées à la sécurité à l’avenir.
La section dédiée au rapport de vulnérabilité dispose désormais de plus d'espace pour afficher les détails importants. Voici les vulnérabilités qui figurent actuellement sur la liste des vulnérabilités du projet. Le déplacement des widgets avec des mesures de vulnérabilité vers une section distincte crée un panneau de contrôle de sécurité pratique. Il s'agit désormais d'un canevas pour les visualisations futures, non seulement pour la gestion des vulnérabilités, mais aussi pour toutes les mesures liées à la sécurité. Enfin, une zone de paramètres distincte crée un espace commun pour tous les paramètres de sécurité au niveau de l'instance, et pas seulement pour la gestion des vulnérabilités.
и .
Les fonctionnalités commutables sont désormais dans GitLab Starter
(STARTER, PREMIUM, ULTIMATE, BRONZE, ARGENT, OR)
GitLab 11.4 est sorti . Dans la version 12.2, nous avons introduit des stratégies pour eux и , et en 13.1, ils ont ajouté и pour différents environnements.
Plus tôt cette année, GitLab s'est engagé en open source. Dans cette version, nous avons terminé la migration des fonctionnalités commutables vers le plan Starter et continuerons de les migrer vers Core à partir de . Nous sommes ravis de proposer cette fonctionnalité à davantage d'utilisateurs et souhaitons savoir comment vous l'utilisez.
и .
Navigation rapide depuis la barre de recherche
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Parfois, lorsque vous naviguez sur GitLab, vous souhaitez accéder directement à un projet spécifique plutôt qu'à la page des résultats de recherche.
À l’aide de la barre de recherche globale, vous pouvez accéder rapidement aux derniers tickets, groupes, projets, paramètres et rubriques d’aide. Vous pouvez même utiliser un raccourci clavier /pour déplacer votre curseur sur la barre de recherche pour naviguer encore plus efficacement dans GitLab !
и .
Affichage de la couverture du code dans les différences de demande de fusion
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Lors de l'examen d'une demande de fusion, il peut être difficile de déterminer si le code modifié est couvert par les tests unitaires. Au lieu de cela, les réviseurs peuvent s'appuyer sur la couverture globale et demander qu'elle soit augmentée avant d'approuver une demande de fusion. Cela peut conduire à une approche aléatoire de l'écriture des tests, qui n'améliorera pas réellement la qualité du code ou la couverture des tests.
Désormais, lorsque vous visualisez une différence de demande de fusion, vous verrez un affichage visuel de la couverture du code. De nouvelles marques vous permettront de comprendre rapidement si le code modifié est couvert par un test unitaire, ce qui contribuera à accélérer la révision du code et le temps de fusion et de déploiement du nouveau code.
merci et Siemens pour cette fonctionnalité !
и .
Plus d'environnements et de projets dans le panneau Environnements
(PREMIUM, ULTIME, ARGENT, OR)
Depuis la sortie de GitLab 12.5 en utilisant vous pouvez surveiller 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 paginant pour vous aider à maintenir et gérer vos environnements à grande échelle. Vous pouvez désormais voir davantage d'environnements dans davantage de projets.
и .
GitLab prend le contrôle du fournisseur GitLab Terraform
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Nous récemment et planifier . Au cours du mois dernier, nous avons accepté 21 demandes de fusion et clôturé 31 tickets, y compris des bugs de longue date et des fonctionnalités manquantes telles que . Tu peux dans la documentation Terraform.
и .
Tests d'API fuzzing avec les spécifications OpenAPI ou le fichier HAR
(ULTIME, OR)
Les tests de fuzzing des API sont un excellent moyen de détecter les bogues et les vulnérabilités de vos applications Web et de vos API que d'autres scanners et méthodes de test pourraient manquer.
Les tests de fuzzing d'API dans GitLab vous permettent de fournir ou votre application, puis génère automatiquement des données d'entrée aléatoires conçues pour tester les cas extrêmes et trouver des bogues. Les résultats sont immédiatement visibles dans votre pipeline.
Il s'agit de notre première version de test de fuzz de l'API et nous aimerions connaître votre avis. Nous en avons plus en stock pour les tests de fuzz , sur lequel nous nous baserons sur la sortie de cette fonctionnalité.
и .
Aperçu des nouveaux graphiques dans le panneau des métriques
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Auparavant, créer un graphique dans le tableau de bord des métriques de GitLab n'était pas une tâche facile. Après avoir créé la métrique dans le fichier YAML du tableau de bord, vous avez apporté des modifications à master, sans pouvoir vérifier que le graphique nouvellement créé fonctionne exactement comme vous le souhaitez. À partir de cette version, vous pouvez prévisualiser les modifications au fur et à mesure que vous créez le graphique, pour avoir une idée du résultat avant d'envoyer les modifications au fichier YAML du tableau de bord.
и .
Données sur la couverture du code par les tests pour tous les projets du groupe
(PREMIUM, ULTIME, ARGENT, OR)
Lorsque vous gérez un grand nombre de projets dans GitLab, vous avez besoin d'une source unique d'informations sur l'évolution de la couverture du code au fil du temps dans tous les projets. Auparavant, l'affichage de ces informations nécessitait un travail manuel fastidieux et chronophage : il fallait télécharger les données de couverture de code de chaque projet et les combiner dans un tableau.
Dans la version 13.4, il est devenu possible d'assembler facilement et rapidement .csv fichier avec toutes les données sur la couverture du code pour tous les projets du groupe ou pour une sélection de projets. Cette fonctionnalité est MVC, elle sera suivie de la possibilité .
и .
Prise en charge de nouvelles langues pour des tests de fuzz complets
(ULTIME, OR)
Cette version introduit la prise en charge de plusieurs nouveaux langages pour les tests fuzz visant une couverture complète.
Vous pouvez désormais évaluer toutes les capacités des tests de fuzzing dans vos applications Java, Rust et Swift et rechercher des erreurs et des vulnérabilités que d'autres scanners et méthodes de test pourraient manquer.
и .
Alertes sur la page principale de l'environnement
(PREMIUM, ULTIME, ARGENT, OR)
La page Environnements affiche 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 à prendre rapidement des mesures pour corriger les situations qui surviennent.
и .
Les pipelines imbriqués peuvent désormais exécuter leurs propres pipelines imbriqués
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
En utilisant des pipelines imbriqués, il est désormais possible d'exécuter de nouveaux pipelines à l'intérieur de pipelines enfants. Le niveau de profondeur supplémentaire 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 qu'une tâche de déclenchement soit définie manuellement dans le pipeline parent. Vous pouvez désormais créer des pipelines imbriqués qui lanceront dynamiquement un nombre illimité de nouveaux pipelines imbriqués. Par exemple, si vous disposez d'un mono-dépôt, vous pouvez générer dynamiquement le premier sous-pipeline, qui créera lui-même le nombre requis de nouveaux pipelines en fonction des modifications apportées à la branche.
и .
Navigation améliorée entre les pipelines parents et imbriqués
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Auparavant, la navigation entre les pipelines parents et imbriqués n'était pas très pratique : il fallait beaucoup de clics pour accéder au pipeline souhaité. Il n’était pas non plus facile de déterminer quelle tâche avait lancé le pipeline. Il sera désormais beaucoup plus facile de voir les connexions entre les pipelines parents et imbriqués.
и .
Les emplois matriciels parallèles affichent les variables pertinentes dans le titre du poste
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Si vous avez utilisé , vous avez peut-être remarqué qu'il était difficile de déterminer quelle variable matricielle était utilisée pour un travail particulier, car les noms des travaux ressemblaient à matrix 1/4. Dans la version 13.4, vous verrez les valeurs de variables pertinentes 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 de déboguer l'architecture x86, le travail s'appellera matrix: debug x86.
и .
Autres améliorations dans GitLab 13.4
Connecter un compte Atlassian
(CORE, STARTER, PREMIUM, ULTIMATE)
Les utilisateurs de GitLab pourront désormais connecter leurs comptes GitLab à leur compte Atlassian Cloud. Cela vous permettra de vous connecter à GitLab avec vos informations d'identification Atlassian et jettera également les bases de futures améliorations de l'intégration. et avec d'autres produits de la gamme Atlassian.
и .
Exporter une liste de tous les commits de fusion
(ULTIME, OR)
Les organisations axées sur la conformité ont besoin d'un moyen de montrer aux auditeurs une vision globale des composants associés à tout changement donné dans la production. Dans GitLab, cela signifie tout collecter en un seul endroit : demandes de fusion, tickets, pipelines, analyses de sécurité et autres données de validation. Jusqu'à présent, vous deviez soit les collecter 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 une liste de tous les commits de fusion pour le groupe actuel, vous devez accéder à et cliquez sur le bouton Liste de tous les commits de fusion. Le fichier résultant contiendra tous les commits de la demande de fusion, leur auteur, l'ID de la demande de fusion associée, le groupe, le projet, les confirmateurs et d'autres informations.
и .
Répertorier et gérer les jetons d'accès personnels via l'API
(ULTIME, OR)
La gestion de l'accès à l'espace de noms GitLab est une partie importante des efforts de conformité. Des principes du moindre privilège à la désactivation de l'accès temporisé, plusieurs exigences peuvent être associé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é de répertorier tous les jetons d'accès personnels et éventuellement via API.
Ces améliorations apportées à l'API GitLab permettent aux utilisateurs de répertorier et de révoquer leurs propres jetons d'accès personnels, et aux administrateurs de répertorier et de révoquer les jetons de leurs utilisateurs. Il sera désormais plus facile pour les administrateurs de voir qui a accès à leur espace de noms, de prendre des décisions d'accès basées sur les données des utilisateurs et de révoquer les jetons d'accès personnels qui pourraient avoir été compromis ou qui ne relèvent pas des politiques de gestion des accès de l'entreprise.
и .
Les problèmes associés et d'autres fonctionnalités sont désormais dans GitLab Core
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Il y a quelques mois, nous avons annoncé un plan visant à . En travaillant pour tenir cette promesse, nous avons fait , и (dans la localisation russe de GitLab « forum de discussion ») disponible dans le plan Core. Cela s'applique uniquement aux relations « liées à », les relations « bloquées » et « bloquées » restent dans les forfaits payants.
и .
Affichage du nom de la branche d'origine dans la barre latérale de la demande de fusion
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Lors de l’examen des modifications de code, des discussions et des validations de demandes de fusion, il est souvent souhaitable d’effectuer une vérification locale de la branche pour un examen plus approfondi. Cependant, trouver le nom du fil de discussion devient de plus en plus difficile à mesure que davantage de contenu est ajouté à la description de la demande de fusion et que vous devez faire défiler la page plus bas.
Nous avons ajouté le nom de la branche à la barre latérale de la demande de fusion, le rendant accessible à tout moment et éliminant le besoin de faire défiler la page entière. Tout comme le lien vers la demande de fusion, la section de la branche source contient un bouton « copier » pratique.
merci pour votre énorme contribution au développement de cette fonctionnalité !
и .
Indication de la présence de fichiers réduits dans les différences de demande de fusion
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Les demandes de fusion qui ajoutent des modifications à plusieurs fichiers réduisent parfois les différences de fichiers volumineux pour améliorer les performances de rendu. Lorsque cela se produit, il est possible d'ignorer accidentellement un fichier lors de la révision, en particulier dans les demandes de fusion comportant un grand nombre de fichiers. À partir de la version 13.4, les demandes de fusion signaleront les différences contenant des fichiers pliés, afin que vous ne manquiez pas ces fichiers lors de la révision du code. Pour encore plus de clarté, nous prévoyons d'ajouter une mise en évidence à ces fichiers dans une prochaine version. Restez à l'écoute des mises à jour sur .
и .
Avertissement sur la présence de fichiers réduits dans le diff d'une demande de fusion
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Dans la section des différences de demande de fusion, les fichiers volumineux sont réduits pour améliorer les performances. Cependant, lors de la révision du code, certains fichiers peuvent manquer lorsque le réviseur fait défiler la liste des fichiers, car tous les fichiers volumineux sont réduits.
Nous avons ajouté un avertissement visible en haut de la page des différences de demande de fusion pour informer les utilisateurs qu'il existe un fichier fusionné dans cette section. De cette façon, vous ne manquerez aucune modification apportée à la demande de fusion lors de l'examen.
и .
Récupération automatique du référentiel du cluster Gitaly
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Auparavant, lorsque le nœud principal d'un cluster Gitaly était hors ligne, les référentiels sur ce nœud étaient marqués en lecture seule. Cela a évité la perte de données dans les situations où des modifications sur le nœud n'avaient pas encore été répliquées. Lorsque le nœud est revenu en ligne, GitLab n'a pas été automatiquement restauré et les administrateurs ont dû démarrer 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, peuvent également entraîner la création de référentiels obsolètes ou en lecture seule. Dans ce cas, le référentiel restait obsolète jusqu'à ce que la prochaine opération d'écriture se produise, ce qui lancerait le travail de réplication.
Pour résoudre ce problème planifie désormais une tâche de réplication lorsqu'il détecte un référentiel obsolète sur un nœud et la dernière version du référentiel sur un autre. Ce travail de réplication maintient le référentiel à jour automatiquement, éliminant ainsi le besoin de restaurer manuellement les données. La récupération automatique garantit également que les nœuds secondaires sont rapidement mis à jour en cas d'échec d'une tâche de réplication, plutôt que d'attendre la prochaine opération d'écriture. Étant donné que de nombreux clusters Gilaly stockent un grand nombre de référentiels, cela réduit considérablement le temps passé par les administrateurs et les ingénieurs en fiabilité à récupérer les données après une erreur.
De plus, la réparation automatique démarre la réplication des référentiels sur tout nouveau nœud Gitaly ajouté au cluster, éliminant ainsi le travail manuel lors de l'ajout de nouveaux nœuds.
и .
Marquer une tâche à faire comme terminée sur la page de conception
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Une communication efficace dans GitLab est basée sur des listes de tâches. Si vous êtes mentionné dans un commentaire, il est essentiel de pouvoir accéder directement à une tâche et soit commencer à faire quelque chose, soit la marquer comme terminée. Il est également important de pouvoir s'attribuer une tâche lorsque vous devez travailler sur quelque chose ou y revenir plus tard.
Auparavant, vous ne pouviez pas ajouter de tâches ni les marquer comme terminées lorsque vous travailliez sur des conceptions. Cela a sérieusement perturbé l'efficacité de la communication entre les équipes produit, car les tâches sont un élément essentiel du flux de travail de GitLab.
Dans la version 13.4, les conceptions rattrapent les commentaires des tickets lors de l'utilisation des tâches, ce qui rend leur utilisation plus cohérente et efficace.
и .
Guide de dépannage amélioré pour CI/CD
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Nous avons amélioré le guide de dépannage pour GitLab CI/CD avec plus d'informations sur les problèmes courants que vous pouvez rencontrer. Nous espérons que la documentation améliorée sera une ressource précieuse pour vous aider à démarrer et à exécuter GitLab CI/CD rapidement et facilement.
и .
Les demandes de fusion ne sortent plus de la file d'attente de fusion
(PREMIUM, ULTIME, ARGENT, OR)
Auparavant, les demandes de fusion pouvaient être accidentellement retirées de la file d'attente de fusion en raison de commentaires tardifs. Si une demande de fusion était déjà dans la file d'attente et que quelqu'un y ajoutait un commentaire créant une nouvelle discussion non résolue, la demande de fusion était considérée comme inéligible pour une fusion et tomberait hors de la file d'attente. Désormais, une fois qu'une demande de fusion est ajoutée à la file d'attente de fusion, de nouveaux commentaires peuvent être ajoutés sans crainte de perturber le processus de fusion.
и .
Affichage de la valeur de couverture de code pour un travail dans une demande de fusion
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Les développeurs doivent être en mesure de voir la valeur de couverture du code une fois le pipeline terminé, même dans des scénarios complexes tels que l'exécution d'un pipeline avec plusieurs tâches qui doivent être analysées pour calculer la valeur de couverture. Auparavant, le widget de demande de fusion affichait uniquement la moyenne de ces valeurs, ce qui signifiait que vous deviez accéder à la page du travail et revenir à la demande de fusion pour obtenir des valeurs de couverture intermédiaires. Pour vous faire gagner du temps et éviter ces étapes supplémentaires, nous avons fait en sorte que le widget affiche la valeur de couverture moyenne, ses modifications entre les branches cible et source, ainsi qu'une info-bulle qui affiche la valeur de couverture pour chaque tâche sur la base de laquelle la moyenne a été calculée.
и .
Suppression de packages du registre de packages lors de l'affichage d'un groupe
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Le registre des packages GitLab est un endroit où stocker et distribuer des packages dans différents formats. Lorsque votre projet ou votre groupe contient de nombreux packages, vous devez identifier rapidement les packages inutilisés et les supprimer pour empêcher les utilisateurs de les télécharger. Vous pouvez supprimer des packages de votre registre via ou via l'interface utilisateur du registre de packages. Cependant, jusqu'à présent, vous ne pouviez pas supprimer des packages lors de l'affichage d'un groupe via l'interface utilisateur. En conséquence, vous deviez supprimer les packages inutiles projet par projet, ce qui était inefficace.
Vous pouvez désormais supprimer des packages lors de l'affichage du registre de packages d'un groupe. Accédez simplement à la page de registre des packages du groupe, filtrez les packages par nom et supprimez ceux dont vous n'avez pas besoin.
и .
Mise à l'échelle des packages Conan au niveau du projet
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Vous pouvez utiliser le référentiel Conan dans GitLab pour publier et distribuer des dépendances C/C++. Cependant, auparavant, les packages ne pouvaient évoluer qu'au niveau de l'instance, car le nom du package Conan ne pouvait comporter qu'un maximum de 51 caractères. Si vous souhaitiez publier un package à partir d'un sous-groupe, par exemple gitlab-org/ci-cd/package-stage/feature-testing/conan, c'était presque impossible à faire.
Vous pouvez désormais faire évoluer les packages Conan jusqu'au niveau du projet, ce qui facilite la publication et la distribution des dépendances de vos projets.
и .
Prise en charge de nouveaux gestionnaires de packages et langages pour l'analyse des dépendances
(ULTIME, OR)
Nous sommes ravis d'ajouter à notre liste les analyses de dépendances pour les projets de code C, C++, C# et .Net qui utilisent NuGet 4.9+ ou les gestionnaires de packages Conan. . Vous pouvez désormais activer l'analyse des dépendances dans le cadre de l'étape sécurisée pour vérifier les vulnérabilités connues dans les dépendances ajoutées via les gestionnaires de packages. Les vulnérabilités trouvées seront affichées dans votre demande de fusion avec leur niveau de gravité, afin que vous sachiez avant d'exécuter la fusion quels risques comporte la nouvelle dépendance. Vous pouvez également configurer votre projet pour exiger pour les dépendances présentant des vulnérabilités avec des niveaux de gravité critique (Critique), élevé (Élevé) ou inconnu (Inconnu).
и .
Notifications lors de la modification du paramètre de demande de fusion sur « Fusionner lorsque le pipeline se termine avec succès »
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Auparavant, lors de la définition des paramètres de demande de fusion Fusionner lorsque le pipeline est terminé (Fusionner lorsque le pipeline réussit, MWPS) aucune notification par courrier électronique n'a été envoyée. Vous deviez vérifier manuellement l'état ou attendre une notification de fusion. Avec cette version, nous sommes heureux de présenter les contributions des utilisateurs , qui a résolu ce problème en ajoutant des notifications automatiques à toutes les personnes abonnés à une demande de fusion lorsqu'un réviseur modifie le paramètre de fusion sur MWPS.
и .
Création de clusters EKS avec une version de Kubernetes spécifiée par l'utilisateur
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
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 et 1.17.
и .
Création d'incidents en tant que types de tickets
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Tous les problèmes qui surviennent ne déclenchent pas immédiatement des alertes : les utilisateurs signalent des pannes et les membres de l'équipe enquêtent sur les problèmes de performances. Les incidents sont désormais une sorte de ticket, ce qui permet à vos équipes de les créer rapidement dans le cadre de leur flux de travail normal. Cliquez sur Nouvelle tâche depuis n'importe où dans GitLab et sur le terrain type sélectionner Incident.
и .
Mentionner les alertes GitLab dans Markdown
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Nous avons amélioré les alertes GitLab en ajoutant un nouveau type de mention spécialement pour elles dans GitLab Markdown, ce qui facilite le partage et la mention des alertes. Utiliser ^alert#1234pour mentionner l'alerte dans n'importe quel champ Markdown : dans les incidents, les tickets ou les demandes de fusion. Cela vous aidera également à identifier les tâches créées à partir d'alertes plutôt que de tickets ou de demandes de fusion.
и .
Visualisation de la charge d'alerte par incident
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
La description de l'alerte contient des informations essentielles au dépannage et à la récupération, et ces informations doivent être facilement accessibles afin que vous n'ayez pas à changer d'outil ou d'onglet pendant que vous travaillez pour résoudre 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, ARGENT, OR)
GitLab, en tant qu'application unique, a la capacité unique de permettre une découverte rapide de contenu dans l'ensemble de votre flux de travail DevOps. Dans GitLab 13.4, la recherche avancée renvoie les résultats 75 % plus rapidement lorsqu'elle , comme sur GitLab.com.
и .
Affichage des projets supprimés pour les administrateurs
(CORE, STARTER, PREMIUM, ULTIMATE)
Il y avait une option pour reporter la suppression du projet . Cependant, auparavant, il n'était pas possible de voir tous les projets en attente de suppression au même endroit. Les administrateurs d'instances utilisateur GitLab peuvent désormais afficher tous les projets de suppression en attente au même endroit, ainsi que des boutons permettant de restaurer facilement ces projets.
Cette fonctionnalité donne aux administrateurs un meilleur contrôle sur la suppression de projets en collectant toutes les informations pertinentes en un seul endroit et en offrant la possibilité d'annuler les actions de suppression indésirables.
merci pour cette fonctionnalité !
и .
Ajout de la prise en charge des règles push de groupe à l'API
(STARTER, PREMIUM, ULTIMATE, BRONZE, ARGENT, OR)
Auparavant, les règles 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. Vous pouvez désormais gérer ces règles via une API pour prendre en charge vos outils personnalisés et l'automatisation GitLab.
и .
Révocation des jetons d'accès personnels pour le stockage des informations d'identification autogérées
(ULTIME)
Fournit aux administrateurs les informations dont ils ont besoin pour gérer les informations d’identification des utilisateurs pour leur instance GitLab. Étant donné que les organisations axées sur la conformité varient dans la rigueur de leurs politiques de gestion des informations d'identification, nous avons ajouté un bouton qui permet aux administrateurs de révoquer éventuellement le jeton d'accès personnel (PAT) d'un utilisateur. Les administrateurs peuvent désormais facilement révoquer les PAT potentiellement compromis. Cette fonctionnalité est utile pour les organisations qui souhaitent des options de conformité plus flexibles afin de minimiser les perturbations pour leurs utilisateurs.
и .
Fichier de configuration de l'éditeur de site statique
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Dans GitLab 13.4, nous introduisons une nouvelle façon de personnaliser l'éditeur de site statique. Bien que le fichier de configuration n'enregistre ni ne reçoive aucun paramètre dans cette version, nous préparons le terrain pour une future personnalisation du comportement de l'éditeur. Dans les prochaines versions, nous ajouterons au fichier .gitlab/static-site-editor.yml paramètres d'installation , sur lequel , remplaçant les paramètres de syntaxe Markdown et les autres paramètres de l'éditeur.
и .
Modification de la partie introductive d'un fichier à l'aide d'un éditeur de site statique
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Les éléments préliminaires constituent un moyen flexible et pratique de définir des variables de page dans des fichiers de données à traiter par le générateur de site statique. Il est généralement utilisé pour définir le titre de la page, le modèle de mise en page ou l'auteur, mais peut être utilisé pour transmettre tout type de métadonnées au générateur lors du rendu de la page en HTML. Incluse tout en haut de chaque fichier de données, la partie d'introduction est généralement au format YAML ou JSON et nécessite une syntaxe cohérente et précise. Les utilisateurs peu familiers avec les règles de syntaxe spécifiques peuvent saisir par inadvertance un balisage non valide, ce qui peut entraîner des problèmes de formatage, voire des échecs de construction.
Le mode d'édition WYSIWYG de l'éditeur de site statique supprime déjà l'intro de l'éditeur pour éviter ces erreurs de formatage. Cela vous empêche cependant de modifier les valeurs stockées dans cette partie sans revenir à l'édition en mode source. Dans GitLab 13.4, vous pouvez accéder à n'importe quel champ et modifier sa valeur dans une interface familière basée sur des formulaires. Lorsque le bouton est enfoncé réglages (Paramètres) un panneau s'ouvrira affichant un champ de formulaire pour chaque clé définie au début. Les champs sont renseignés avec la valeur actuelle et leur modification est aussi simple que de la saisir dans le formulaire Web. Modifier l'intro de cette manière évite une syntaxe complexe et vous donne un contrôle total sur le contenu tout en garantissant que le résultat final est formaté de manière cohérente.
и .
GitLab pour Jira et DVCS Connector est désormais dans Core
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Pour les utilisateurs de Jira sur GitLab : и vous permettent d'afficher des informations sur les commits GitLab et de fusionner les demandes directement dans Jira. En combinaison avec notre intégration Jira intégrée, vous pouvez facilement passer d'une application à l'autre pendant que vous travaillez.
Ces fonctionnalités n'étaient auparavant disponibles que dans notre forfait Premium, mais sont désormais disponibles pour tous les utilisateurs !
и .
Vote majoritaire pour les transactions du cluster Gitaly (bêta)
(CORE, STARTER, PREMIUM, ULTIMATE)
Un cluster Gitaly vous permet de répliquer des référentiels Git sur plusieurs nœuds Gitaly « chauds ». Cela augmente la tolérance aux pannes en éliminant les points de défaillance uniques. , introduit dans GitLab 13.3, entraîne la diffusion des modifications à tous les nœuds Gitaly du cluster, mais seuls les nœuds Gitaly qui votent en accord avec le nœud principal enregistrent les modifications sur le disque. Si tous les nœuds de réplication ne sont pas d'accord, une seule copie de la modification sera stockée sur le disque, créant ainsi un point de défaillance unique jusqu'à la fin de la réplication asynchrone.
Le vote majoritaire améliore la tolérance aux pannes en exigeant le consentement d'une majorité de nœuds (pas de tous) avant d'enregistrer les modifications sur le disque. Si cette fonctionnalité de bascule est activée, l'écriture doit réussir sur plusieurs nœuds. Les nœuds dissidents sont automatiquement synchronisés à l'aide d'une réplication asynchrone à partir des nœuds qui ont formé un quorum.
и .
Prise en charge des schémas personnalisés pour la validation JSON dans Web IDE
(PREMIUM, ULTIME, ARGENT, OR)
Les projets dans lesquels les utilisateurs écrivent des configurations en JSON ou YAML sont souvent sujets à des problèmes car il est facile de faire une faute de frappe et de casser quelque chose. Il est possible d'écrire des outils d'inspection pour détecter ces problèmes dans le pipeline CI, mais l'utilisation d'un fichier de schéma JSON peut être utile pour fournir de la documentation et des conseils.
Les participants au projet peuvent définir dans leur référentiel le chemin d'accès à un schéma personnalisé dans un fichier .gitlab/.gitlab-webide.yml, qui spécifie le schéma et le chemin d'accès aux fichiers à vérifier. Lorsque vous chargez un fichier spécifique dans l'IDE Web, vous verrez des commentaires et une validation supplémentaires pour vous aider à créer le fichier.
и .
La limite de branchement du graphique acyclique dirigé (DAG) a été augmentée à 50
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Si vous utilisez des convoyeurs (Graphique acyclique dirigé (DAG)), vous constaterez peut-être qu'il existe une limite de 10 tâches qu'une tâche peut spécifier dans needs:, trop sévère. Dans la version 13.4, la limite par défaut a été augmentée de 10 à 50 pour permettre des réseaux de relations plus complexes entre les tâches de vos pipelines.
Si vous êtes administrateur d'une instance GitLab personnalisée, vous pouvez augmenter encore cette limite en configurant une fonctionnalité de bascule, bien que nous n'offrions pas de support officiel pour cela.
и .
Comportement amélioré needs pour les devoirs manqués
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Dans certains cas, une tâche manquée dans un pipeline peut être considérée à tort comme réussie pour les dépendances spécifiées dans needs, ce qui a provoqué l'exécution des tâches suivantes, ce qui n'aurait pas dû se produire. Ce comportement a été corrigé dans la version 13.4, et needs gère désormais correctement les cas de tâches manquées.
и .
Épinglez le dernier artefact de quête pour éviter qu'il ne soit supprimé
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
GitLab verrouille désormais automatiquement le dernier travail réussi et l'artefact de pipeline sur toute branche active, demande de fusion ou balise pour empêcher sa suppression après expiration. Il devient plus facile de définir des règles d’expiration plus agressives pour nettoyer les anciens artefacts. Cela permet de réduire la consommation d'espace disque et garantit que vous disposez toujours d'une copie du dernier artefact du pipeline.
и .
Guide CI/CD pour l'optimisation des pipelines
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
L'optimisation de votre pipeline CI/CD peut améliorer la vitesse de livraison et économiser de l'argent. Nous avons amélioré notre documentation pour inclure un guide rapide permettant de tirer le meilleur parti de l'optimisation de vos pipelines.
и .
Rapport de test trié par statut de test
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
est un moyen simple de voir les résultats de tous les tests d’un pipeline. Cependant, avec un grand nombre de tests, la détection des tests ayant échoué peut prendre beaucoup de temps. D'autres problèmes qui peuvent rendre le rapport difficile à utiliser incluent la difficulté à faire défiler les sorties de trace longues et l'arrondi à zéro pour les tests exécutés en moins d'une seconde. Désormais, par défaut, lors du tri d'un rapport de test, il place d'abord les tests ayant échoué au début du rapport, puis trie les tests par durée. Cela facilite la détection des échecs et des tests longs. De plus, les durées des tests sont désormais affichées en millisecondes ou en secondes, ce qui les rend beaucoup plus rapides à lire, et les problèmes de défilement précédents ont également été résolus.
и .
Limites de taille des fichiers téléchargés dans le registre des packages
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Il existe désormais des limites sur la taille des fichiers de package pouvant être téléchargés dans le registre des packages GitLab. Des restrictions ont été ajoutées pour optimiser les performances du registre des packages et éviter les abus. Les limites varient en fonction du format du package. Pour GitLab.com, les tailles maximales de 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 restrictions en utilisant .
и .
Utilisez CI_JOB_TOKEN pour publier des packages PyPI
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Vous pouvez utiliser le référentiel GitLab PyPI pour créer, publier et partager des packages Python ainsi que du code source et des pipelines CI/CD. Cependant, auparavant, vous ne pouviez pas vous authentifier auprès du référentiel à l'aide d'une variable d'environnement prédéfinie. CI_JOB_TOKEN. En conséquence, vous avez dû utiliser vos informations d'identification personnelles pour mettre à jour le référentiel PyPI, ou vous avez peut-être décidé de ne pas utiliser le référentiel du tout.
Il est désormais plus facile d'utiliser GitLab CI/CD pour publier et installer des packages PyPI à l'aide d'une variable d'environnement prédéfinie CI_JOB_TOKEN.
и .
Profils de scanner DAST sur demande
(ULTIME, OR)
À l'analyse DAST à la demande qui a été , des profils de scanner DAST ont été ajoutés. Ils étendent les capacités de configuration de ces analyses, vous permettant de créer rapidement plusieurs profils pour couvrir plusieurs types d'analyse. Dans la version 13.4, le profil du robot d'exploration inclut de manière native un paramètre de délai d'expiration du robot qui définit la durée pendant laquelle le robot d'exploration DAST doit s'exécuter lorsqu'il tente de découvrir toutes les pages d'un site analysé. Le profil comprend également un paramètre de délai d'expiration du site cible pour définir combien de temps le robot d'exploration doit attendre qu'un site devienne accessible avant d'abandonner l'exploration si le site ne répond pas avec un code d'état 200 ou 300. À mesure que nous continuons à nous améliorer, cette fonctionnalité sera ajouté au profil du scanner dans les versions futures ; des paramètres de configuration supplémentaires seront ajoutés.
и .
Un simple fichier de configuration de redirection pour les pages GitLab
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Si vous utilisez GitLab Pages et souhaitez mieux gérer les changements d'URL, vous avez peut-être remarqué que la gestion des redirections sur votre site GitLab Pages n'était pas possible. GitLab vous 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 au référentiel. Cette fonctionnalité est rendue possible grâce à la contribution de Kevin Barnett (), notre Eric Eastwood () et les équipes GitLab. Merci à tous pour votre contribution.
и .
État Terraform géré par GitLab
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
L'accès aux versions précédentes de Terraform State est nécessaire à la fois pour la 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 fournie à partir de GitLab 13.4. La gestion des versions est automatiquement activée pour les nouveaux fichiers d'état Terraform. Les fichiers d'état Terraform existants seront dans une version ultérieure.
и .
Détails de notification d'incident important
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Lors du traitement des incidents, vous devez pouvoir déterminer facilement combien de temps une alerte est restée ouverte et combien de fois l'événement a été déclenché. Ces détails sont souvent essentiels pour déterminer l’impact sur le client et ce à quoi votre équipe doit s’attaquer en premier. Dans le nouveau panneau 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 d'alertes.
и .
Définition et modification du paramètre de gravité de l'incident
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
La dimension Gravité de l'incident permet aux intervenants et aux parties prenantes de déterminer l'impact d'une panne, ainsi que la méthode et l'urgence de la réponse. À mesure que votre équipe partage les résultats lors de la résolution des incidents et de la récupération, elle peut modifier ce paramètre. Vous pouvez désormais modifier la gravité d'un incident dans la barre latérale droite de la page Détails de l'incident, et la gravité s'affiche dans la liste des incidents.
и .
Création, modification et suppression de règles de sécurité du réseau de conteneurs
(ULTIME, OR)
Cette amélioration de l'éditeur de règles de Container Network Security 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 .yaml pour les utilisateurs expérimentés et un éditeur de règles avec une interface intuitive pour ceux qui découvrent 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é et conformité > Gestion des menaces > Politiques).
и .
Prise en charge du stockage blob Azure
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
GitLab et GitLab Runner prennent désormais en charge , ce qui facilite l'exécution des services GitLab sur Azure.
Les instances GitLab prennent en charge Azure pour tous les types de magasins d'objets, y compris les fichiers LFS, les artefacts CI et . Pour configurer le stockage Azure Blob, suivez les instructions d'installation ou .
Les processeurs de travaux GitLab prennent également en charge Azure pour le stockage . Le stockage Azure peut être configuré à l'aide de la section .
и .
Packages Omnibus ARM64 pour Ubuntu et OpenSUSE
(CORE, STARTER, PREMIUM, ULTIMATE)
En réponse à la demande croissante de prise en charge de l'exécution de GitLab sur une architecture ARM 64 bits, nous sommes heureux d'annoncer la disponibilité du package officiel ARM64 Ubuntu 20.04 Omnibus. Un grand merci à Zitai Chen et Guillaume Gardet pour leurs énormes contributions - leurs demandes de fusion ont joué un rôle clé à cet égard !
Pour télécharger et installer le package pour Ubuntu 20.04, accédez à notre et sélectionnez Ubuntu.
и .
Prise en charge de l'authentification par carte à puce pour le graphique GitLab Helm
(PREMIUM, ULTIME)
Les cartes à puce, telles que les Common Access Cards (CAC), peuvent désormais être utilisées pour s'authentifier auprès d'une instance GitLab déployée via la charte Helm. Les cartes à puce sont authentifiées par rapport à une base de données locale à l'aide de certificats X.509. Grâce à cela, la prise en charge des cartes à puce avec Helm Chart est désormais conforme à la prise en charge des cartes à puce disponible dans les déploiements Omnibus.
и .
Les notes de version détaillées et les instructions de mise à jour/installation peuvent être lues dans le message original en anglais : .
Nous travaillions sur la traduction de l'anglais , , и .
Source: habr.com