La gestion des versions simplifiée
GitLab 11.7 présente des versions pour les plans commençant par Core. Les utilisateurs recevront désormais une distribution complète - le code source avec tous les artefacts du projet. Cela élimine la nécessité de collecter manuellement en un seul endroit le code source, le journal de génération, d'autres métadonnées ou artefacts liés à cette version. Cette fonctionnalité servira de base à une gestion des versions plus détaillée et sophistiquée à l'avenir.
La gestion de portefeuille prend désormais en charge des structures de répartition du travail plus complexes
Les épopées imbriquées à plusieurs niveaux sont le dernier ajout à la gestion de portefeuille dans GitLab, disponible dans le plan Ultimate. Les épopées imbriquées vous permettent de diviser le travail en structures à plusieurs niveaux pour créer des projets et des plans de travail plus complexes. Les épopées peuvent désormais contenir des tâches et d'autres épopées; une telle structure créera un lien direct entre la planification et les tâches de mise en œuvre.
Optimisation du développement JavaScript avec les registres de packages NPM
Gitlab 11.7 en termes de Premium ajoute des registres de packages NPM directement à GitLab, offrant un moyen standard et plus sécurisé de partager des packages NPM et de gérer leurs versions entre les projets. Fournissez simplement le nom du package et NPM avec GitLab fera tout ce dont vous avez besoin dans la même interface.
Et bien plus
Il est toujours difficile de choisir les fonctionnalités à inclure dans un bref aperçu de la version mensuelle, nous allons donc nommer quelques innovations plus intéressantes:
Fermeture d'une vulnérabilité à l'aide d'un fichier correctif : les outils de sécurité GitLab aident à détecter les vulnérabilités. Avec la sortie de GitLab 11.7, il est possible de remédier à la vulnérabilité et d'offrir une solution pour les projets Node.js gérés par Yarn. Jusqu'à présent, c'est la première fonctionnalité officielle qui couvre les vulnérabilités, mais certainement pas la dernière!
Intégration avec Kubernetes par API : pour ceux qui créent vraiment de nombreux clusters Kubernetes ou se considèrent comme un maître dans l'utilisation de Kubernetes, nous avons ajouté l'API Kubernetes, qui réduira considérablement le travail manuel et simplifiera la vie.
Visualisation des liens de pipelines inter-projets : grâce à notre nouvelle fonctionnalité - visualisation améliorée des pipelines inter-projets - toutes les informations nécessaires sont désormais à portée de main.
Vous trouverez ensuite une liste complète des innovations de la version GitLab 11.7!
Nous vous invitons à nos réunions
MortyChoi a ajouté la prise en charge des packages Go privés dans les sous-groupes . Merci pour cette contribution qui aidera à soutenir davantage ce langage populaire dans GitLab!
Principales caractéristiques de la sortie de GitLab 11.7
Libérez les versions de votre projet
(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)
Notre nouvelle fonctionnalité - Versions - vous permet de créer des versions dans GitLab et de les visualiser sur la page de présentation. Versions - «distribution» de l'état actuel du code, des liens et autres métadonnées ou artefacts liés à la version publiée du code. Les utilisateurs de votre projet peuvent désormais accéder facilement à sa dernière version publiée.
Documentation de sortie et ticket d'origine .
Épopées imbriquées en couches
(ULTIME, OR)
Les épopées et les tâches fonctionnent bien ensemble pour la flexibilité des plans de travail à long terme, mais jusqu'à présent, seules des structures à deux niveaux ont pu être créées avec leur aide.
Dans cette version, nous présentons des épopées imbriquées: elles peuvent désormais contenir des tâches et d'autres épopées, ce qui vous permettra de créer un système de répartition du travail à plusieurs niveaux. Ainsi, vous pourrez construire des plans stratégiques ou des objectifs organisationnels encore plus à long terme - pour créer des épopées de haut niveau avec plusieurs niveaux d'épopées à l'intérieur, divisant le travail en parties mesurables du point de vue de la livraison, jusqu'aux tâches.
Documentation sur les épopées et ticket original .
Afficher les relations de pipeline entre projets
(PREMIUM, ULTIME, ARGENT, OR)
Maintenant, dans le graphique de la page d'affichage des pipelines, vous pouvez étendre les dépendances entrantes et sortantes dans les pipelines interprojets et avoir une idée de tous les pipelines impliqués - quel que soit le projet dans lequel ils commencent ou se terminent.
Documentation sur les horaires des convoyeurs et le ticket d'origine .
Fermeture d'une vulnérabilité à l'aide d'un fichier correctif
(ULTIME, OR)
GitLab peut détecter différents types de vulnérabilités dans vos applications et suggérer des solutions possibles.
À partir de la version de GitLab 11.7, vous pouvez télécharger le fichier correctif et l'appliquer à votre référentiel à l'aide de la git apply . Soumettez ensuite les modifications au référentiel et le panneau de sécurité confirme que la vulnérabilité est corrigée. Cela simplifie le processus de résolution de ces problèmes et réduit le temps requis pour appliquer la solution. À l'heure actuelle, l'analyse des dépendances signale des vulnérabilités connues dans les projets NodeJS exécutant le gestionnaire de packages de yarn , et cela ne nécessite aucun effort supplémentaire. Le correctif apparaîtra dans la fenêtre des détails de la vulnérabilité lorsqu'il sera disponible.
Documentation des solutions proposées et du ticket d'origine .
Possibilité de définir des clés secrètes d'application avec des variables dans Kubernetes
(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)
Les opérateurs et les administrateurs doivent configurer des clés secrètes en dehors du référentiel d'applications afin de réduire le risque de divulgation de données sensibles. GitLab offre désormais la possibilité de configurer des clés secrètes en tant que variables d'environnement disponibles pour l'application dans votre cluster Kubernetes.
Il suffit de démarrer le nom de la variable avec K8S_SECRET_ , et le pipeline CI correspondant l'acceptera comme clé secrète de votre application Kubernetes.
Documentation sur la configuration des clés secrètes et un ticket original .
Registre des packages NPM
(PREMIUM, ULTIME, ARGENT, OR)
Les développeurs JavaScript ont besoin d'un moyen fiable et standardisé de partager des packages NPM et de gérer leurs versions entre projets. Le registre de packages pour NPM offre cette opportunité aux développeurs de services de bas niveau lors de la publication de leur code.
Dans la version 11.7 de GitLab, nous avons ajouté un registre des packages NPM intégrés à GitLab. Cela signifie que les développeurs peuvent désormais utiliser une convention de dénomination de package simple pour utiliser la bibliothèque dans n'importe quel projet Node.js, tandis que NPM et GitLab feront le reste. Tout cela est disponible via la même interface. Cette fonctionnalité sera disponible dans GitLab Premium.
Examinez l' exemple de projet dans lequel l'assemblage et l'insertion dans le Registre ont lieu.
Documentation sur le registre des packages NPM et le ticket d'origine .
Prise en charge API pour l'intégration de Kubernetes
(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)
Dans cette version, nous avons ajouté la prise en charge d'API pour l'intégration avec Kubernetes. Cela signifie que toutes les actions qui sont désormais disponibles dans l'interface graphique - ajouter, supprimer et répertorier les clusters Kubernetes - sont désormais disponibles via l'API. Cela donne aux équipes de développement la possibilité de créer des clusters au cours du processus de développement.
Documentation de l'API de cluster et ticket d'origine .
Autres améliorations dans GitLab 11.7
Fenêtre de filtre de recherche pour la navigation dans les tableaux de tâches
(DEMARREUR, PREMIUM, ULTIME, BRONZE, ARGENT, OR)
Les équipes de développement utilisent souvent plusieurs tableaux de tâches, ce qui complique la navigation dans la liste déroulante s'il y a trop de tâches. Dans cette version, nous avons ajouté un filtre de recherche pour résoudre ce problème. Maintenant, vous pouvez simplement entrer quelques caractères dans la zone de recherche pour réduire rapidement le nombre de tâches à celles qui vous intéressent, ce qui simplifiera considérablement la navigation.
Documentation sur la barre des tâches et le ticket d'origine .
Refonte de la liste des projets
(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)
Les projets sont l'un des principaux composants de GitLab, nous essayons donc d'améliorer l'apparence des listes de projets et de simplifier leur travail.
Dans GitLab 11.7, nous introduisons une nouvelle conception pour l'interface utilisateur des listes de projets, qui se concentre sur la lisibilité et fournit un bref rapport sur l'activité du projet. Nous avons ajouté une place pour des informations supplémentaires sur le projet et un espace vide à chaque ligne de la liste des projets, et nous prévoyons de continuer à améliorer la conception en fonction de vos commentaires.
Documentation du projet et ticket d'origine .
Prise en charge des boîtes aux lettres universelles, y compris Microsoft Exchange et Google Groupes pour les fonctionnalités utilisant le courrier électronique entrant
(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)
GitLab possède plusieurs fonctionnalités intéressantes qui utilisent le courrier électronique entrant, telles que la réponse par courrier électronique , la création de ticket par courrier électronique , la création de demande de fusion (dans la localisation russe de «demande de fusion» GitLab) par courrier électronique et l'assistance technique par courrier électronique . Auparavant, ces fonctionnalités ne pouvaient être utilisées que si votre serveur de messagerie prend en charge la fonction de sous-adressage.
À partir de cette version, GitLab prend en charge à la fois le sous-adressage et les boîtes aux lettres fourre-tout en utilisant un nouveau format de message qui permet l'intégration de GitLab avec encore plus de serveurs de messagerie, y compris Microsoft Exchange et Google Groupes qui ne prennent pas en charge le sous-adressage. .
Documentation par e - mail entrant et ticket d'origine .
(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)
Souvent, lorsque les équipes de développement commencent à utiliser GitLab, il peut s'avérer qu'elles utilisent différents outils et qu'elles ont hérité de données. Vous utilisez peut-être Jira en ce moment, mais vous souhaitez passer à la gestion des tâches dans GitLab.
À partir de cette version, cette transition est beaucoup plus facile. Étant donné que de nombreux systèmes de suivi des tâches prennent en charge l'exportation de fichiers CSV, vous pouvez désormais importer ces tâches dans GitLab, ce qui vous permet de continuer à travailler sur les tâches en cours en important des données héritées dans GitLab pour une recherche et une récupération supplémentaires si nécessaire. Cela fonctionnera avec Jira ou tout autre système de suivi des tâches prenant en charge l'exportation CSV.
GitLab a également déjà une fonctionnalité pour exporter des fichiers CSV .
Documentation pour l'importation de fichiers CSV et le ticket d'origine .
Génération d'une courte séquence SHA en tant que variable d'environnement
(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)
Dans Git, les SHA sont des pointeurs vers des objets spécifiques (tels que des validations) dans le référentiel Git, composé de 40 caractères. Souvent, il n'est pas nécessaire d'afficher la chaîne entière et vous souhaitez que seuls les huit premiers caractères du SHA soient affichés pour suivre rapidement le lien, bien que cette séquence ne soit pas unique. Nous avons ajouté la CI_COMMIT_SHORT_SHA environnement CI_COMMIT_SHORT_SHA pour le pipeline CI pour résoudre ce problème, qui vous permettra de générer la première partie de la validation SHA.
Documentation sur les variables d'environnement et le ticket d'origine .
Des restrictions plus strictes sur la confirmation de vos demandes de fusion
(DEMARREUR, PREMIUM, ULTIME, BRONZE, ARGENT, OR)
Une révision de code est une pratique qui doit être effectuée dans tout projet réussi par une personne qui n'est pas l'auteur du changement. Par défaut, la confirmation de vos demandes de fusion est interdite, cependant, la paternité de la demande de fusion, et non les commits qui y sont inclus, a été prise en compte dans cette restriction.
À partir de GitLab 11.7, les restrictions sur la confirmation de leurs demandes de fusion empêcheront également la confirmation des demandes de fusion par les personnes qui les ont apportées, de sorte que les demandes de fusion créées par plusieurs développeurs recevront des révisions et des confirmations complètement indépendantes.
Documentation sur la confirmation des demandes de fusion et un ticket original .
La prise en charge des autorisations pour le réseau comprend
(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)
Lorsque vous incluez des fichiers externes dans votre définition de pipeline à l'aide du mot clé include , ces fichiers sont demandés via HTTP / HTTPS. Vous pouvez désormais accéder aux fichiers YAML dans un autre projet sans accès public (par exemple, un projet privé sur GitLab.com) à l'aide des données d'autorisation avec lesquelles le pipeline fonctionne.
La documentation YAML comprend le ticket d'origine .
Filtrage des vulnérabilités de sécurité de groupe
(ULTIME, OR)
Les tableaux de bord de sécurité de groupe permettent aux équipes de sécurité de tout garder sous contrôle, montrant les vulnérabilités qui affectent leurs groupes.
Avec GitLab 11.7, les utilisateurs peuvent filtrer les vulnérabilités affichées par gravité, type de rapport et nom de projet. Grâce à cela, ils peuvent se concentrer sur ce dont ils ont besoin et accéder plus rapidement à leurs données, ce qui est particulièrement utile lorsqu'il y a beaucoup d'entrées dans la liste.
Documentation de visualisation de vulnérabilité et ticket original .
Afficher les résultats de l'analyse des dépendances dans un panneau de sécurité de groupe
(ULTIME, OR)
Le panneau de sécurité du groupe a été initialement publié uniquement avec des résultats SAST , de sorte que les utilisateurs ne pouvaient pas gérer d'autres types de vulnérabilités à l'aide de cette fonctionnalité.
Avec GitLab 11.7, les résultats de l' analyse des dépendances ont été ajoutés à l'ensemble de données disponible. Si vous utilisez déjà la nouvelle syntaxe de rapport , vous verrez automatiquement les résultats dans le panneau de sécurité. Le modèle Auto DevOps a également été mis à jour et nécessite désormais la version 11.5 ou supérieure de GitLab Runner pour exécuter correctement l'analyse des dépendances.
Documentation du panneau de sécurité du groupe et ticket d'origine .
Inclusion de fichiers CI / CD d'autres projets et modèles
(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)
Le mot clé include permet aux utilisateurs de créer dynamiquement des pipelines CI / CD avec l'inclusion de fichiers externes dans la configuration. Auparavant, cela n'était possible que pour les fichiers du référentiel de projet ou pour les fichiers distants téléchargés via HTTP.
Avec GitLab 11.7, les utilisateurs peuvent également inclure leurs fragments de configuration à partir d'autres projets et de modèles prédéfinis. GitLab inclura des extraits pour des travaux spécifiques, tels que sast ou dependency_scanning , afin que les utilisateurs puissent les référencer au lieu de copier et coller la définition actuelle. Les travaux seront automatiquement mis à jour vers la dernière version lors de la mise à jour de GitLab, il n'est donc pas nécessaire d'apporter des modifications manuellement.
La documentation YAML comprend le ticket d'origine .
Mode RBAC par défaut lors de la création d'un cluster Kubernetes
(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)
La sécurisation du cluster Kubernetes est essentielle pour contrôler et restreindre l'accès des utilisateurs au cluster et les actions autorisées par ces personnes.
À partir de GitLab 11.7, tous les clusters prendront en charge par défaut RBAC lors de la création, fournissant une infrastructure plus sécurisée et sécurisée.
Documentation de cluster et RBAC et ticket d'origine .
Prise en charge des packages Go privés dans les sous-groupes
(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)
Les packages Go hébergés sur GitLab peuvent être installés à l'aide de la commande go get , mais cela n'était pas pris en charge auparavant pour les projets privés dans les sous-groupes. À partir de GitLab 11.7, tout projet peut être utilisé en tant que package Go, y compris les projets privés dans des sous-groupes.
Les packages privés sont pris en charge par la commande go get à l'aide du .netrc et d'un jeton d'accès personnel dans le champ du password .
Merci à MortyChoi pour cette fonctionnalité!
Documentation du sous-groupe et ticket original .
Prise en charge des mesures NGINX Ingress 0.16.0+
(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)
Avec la sortie de NGINX Ingress 0.16.0 , les métriques Prometheus sont désormais intégrées de manière native , plutôt que de s'appuyer sur des outils d'exportation externes.
GitLab 11.7 inclut désormais la prise en charge des mesures exportées à partir de NGINX Ingress 0.16.0+ et détecte et affiche automatiquement le débit, la latence et les taux d'erreur de déploiement.
Documentation NGINX Ingress et ticket d'origine .
Ignorer les assemblys CI pendant le push git
(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)
Lorsque les utilisateurs ne voulaient pas exécuter le pipeline CI / CD pour une validation, ils pouvaient ajouter une note spéciale [ci skip] ou [skip ci] à la description de la validation. Cependant, de nombreux utilisateurs ne souhaitent pas ou ne peuvent pas modifier leurs descriptions de validation pour ajouter des informations supplémentaires.
À partir de GitLab 11.7 lors de l'utilisation de Git version 2.10 et supérieure, les utilisateurs peuvent utiliser les paramètres push de Git pour empêcher le pipeline de démarrer lors de l'envoi d'une validation à GitLab. Vous pouvez maintenant utiliser git push -o ci.skip pour atteindre le même objectif sans changer la description de la validation.
Merci à Jonathon Reinhart pour cette fonctionnalité!
Documentation pour les travaux CI manquants et le ticket d'origine .
GitLab Runner 11.7
(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)
Nous publions également GitLab Runner 11.7! GitLab Runner est un projet open source utilisé pour exécuter des travaux CI / CD et renvoyer les résultats à GitLab.
Les changements les plus importants:
Une liste de toutes les modifications peut être trouvée dans le CHANGELOG GitLab Runner.
Documentation de GitLab Runner .
Des notes de version détaillées et des instructions de mise à jour / d'installation peuvent être trouvées dans la publication originale en anglais: GitLab 11.7 livré avec les versions, les épopées enfant à plusieurs niveaux et le registre NPM .
Cattidourden , maryartkey , ainoneko et rishavant ont travaillé sur la traduction de l'anglais.