Détection rapide des fuites de secrets
Il peut sembler qu'une petite erreur — transmettre accidentellement des identifiants dans un dépôt partagé. Cependant, les conséquences peuvent être graves. Une fois qu'un attaquant a accès à votre mot de passe ou clé API, il peut prendre le contrôle de votre compte, vous bloquer et utiliser votre argent de manière frauduleuse. De plus, l'effet domino est possible : l'accès à un compte ouvre l'accès à d'autres. Les enjeux sont élevés, il est donc crucial de détecter une fuite de secrets le plus tôt possible.
Dans cette version, nous introduisons l'option dans le cadre de nos fonctionnalités SAST. Chaque commit est scanné lors d'une tâche CI/CD à la recherche de secrets. S'il y a un secret, le développeur reçoit un avertissement dans la demande de fusion. Il peut alors annuler immédiatement les identifiants compromis et en créer de nouveaux.
Assurer une gestion du changement adéquate
À mesure que la taille et la complexité augmentent, il devient de plus en plus difficile de maintenir la cohérence entre les différentes parties de l'organisation. Plus il y a d'utilisateurs dans l'application et plus les revenus sont élevés, plus les conséquences d'une fusion de code incorrect ou non sécurisé sont sérieuses. Pour de nombreuses organisations, garantir un processus de révision avant la fusion du code est une exigence stricte, car les risques sont très élevés.
Dans GitLab 11.9, plus de contrôle et une structure plus efficace grâce à . Auparavant, pour obtenir une approbation, il suffisait de mentionner une personne ou un groupe (chaque membre pouvant donner son approbation). Désormais, il est possible d'ajouter plusieurs règles afin qu'une demande de fusion requière l'approbation de personnes spécifiques ou même de plusieurs membres d'un groupe particulier. De plus, la fonctionnalité de propriétaires de code est intégrée dans les règles d'approbation, permettant d'identifier facilement la personne qui a donné l'approbation.
Cela permet aux organisations de mettre en œuvre des processus d'approbation complexes tout en conservant la simplicité d'une application unique GitLab, où les tâches, le code, les pipelines et les données de surveillance sont visibles et accessibles pour la prise de décision et l'accélération du processus d'approbation.
ChatOps est maintenant en open source
GitLab ChatOps est un outil d'automatisation efficace qui permet d'exécuter n'importe quel job CI/CD et de demander son statut directement dans des applications de chat telles que Slack et Mattermost. , ChatOps faisait partie de l'abonnement GitLab Ultimate. En se basant sur et , nous déplaçons parfois les fonctionnalités vers le bas et jamais vers le haut.
Dans le cas de ChatOps, nous avons réalisé que cette fonctionnalité pourrait être utile à tous, et que la participation de la communauté pourrait bénéficier à la fonctionnalité elle-même.
Dans GitLab 11.9, nous , et donc, il est maintenant disponible gratuitement pour une utilisation dans GitLab Core autogéré et sur GitLab.com, et est ouvert à la communauté.
Et bien plus encore !
Il y a tant de fonctionnalités incroyables dans cette version : par exemple, , et , — nous avons hâte d'en parler !
L'employé le plus valorisé () de ce mois est Marcel Amirault ()
Marcel a constamment contribué à améliorer la documentation de GitLab. Il pour améliorer la qualité et l'utilisabilité de nos documents. Domo arigato [merci beaucoup (jap.) — note du trad.] Marcel, nous l'apprécions sincèrement !
Fonctionnalités principales ajoutées dans la version GitLab 11.9
Détection des secrets et des informations d'identification dans les dépôts
(ULTIMATE, GOLD)
Les développeurs transmettent parfois involontairement des secrets et des informations d'identification dans des dépôts distants. Si d'autres personnes ont accès à cette source, ou si le projet est open source, des informations confidentielles peuvent être divulguées et utilisées par des attaquants pour accéder à des ressources telles que des environnements de déploiement.
GitLab 11.9 propose un nouveau test — 'Détection des Secrets'. Il scanne le contenu du dépôt à la recherche de clés API et d'autres informations qui ne devraient pas s'y trouver. GitLab affiche les résultats dans le rapport SAST dans le widget de la demande de fusion, dans les rapports de pipeline et sur les tableaux de bord de sécurité.
Si vous avez déjà activé SAST pour votre application, vous n'avez rien à faire, profitez simplement de cette nouvelle fonctionnalité. Elle est également incluse dans la configuration par défaut.
Règles de résolution des demandes de fusion
(PREMIUM, ULTIMATE, SILVER, GOLD)
La révision de code est un élément essentiel de tout projet réussi, mais il n'est pas toujours clair qui doit s'occuper de la révision des modifications. Il est souvent souhaitable d'inclure des réviseurs de différentes équipes : l'équipe de développement, l'équipe d'interaction avec les utilisateurs, l'équipe de production.
Les règles d'approbation permettent d'améliorer le processus d'interaction entre les personnes participant à la révision de code : elles déterminent le nombre de personnes habilitées à approuver et le nombre minimal d'approbations nécessaires. Les règles d'approbation sont affichées dans le widget de la demande de fusion, ce qui permet ainsi de désigner rapidement le prochain réviseur.
Dans GitLab 11.8, les règles d'approbation étaient désactivées par défaut. À partir de la version GitLab 11.9, elles sont disponibles par défaut. Dans GitLab 11.3, nous avons introduit l'option pour désigner les membres de l'équipe responsables de certains codes au sein du projet. La fonctionnalité Code Owners est intégrée aux règles d'approbation, ce qui facilite toujours la recherche des bonnes personnes pour réviser les modifications.
La migration de ChatOps vers Core
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Initialement introduit dans GitLab Ultimate 10.6, ChatOps a été déplacé vers GitLab Core. GitLab ChatOps offre la possibilité de lancer des tâches GitLab CI via Slack grâce à la fonctionnalité .
Nous ouvrons le code source de cette fonctionnalité conformément à notre . En l'utilisant plus souvent, la communauté contribuera davantage.
Audit des paramètres des fonctionnalités
(PREMIUM, ULTIMATE, SILVER, GOLD)
Des opérations telles que l'ajout, la suppression ou la modification des paramètres des fonctionnalités sont désormais enregistrées dans le journal d'audit de GitLab, ce qui permet de voir ce qui a été modifié et quand. Vous avez rencontré un incident et devez vérifier ce qui a changé récemment ? Ou avez-vous simplement besoin, dans le cadre d'un audit, d'examiner comment les paramètres des fonctionnalités ont été modifiés ? C'est désormais très facile.
Correction des vulnérabilités des demandes de fusion
(ULTIMATE, GOLD)
Pour remédier rapidement aux vulnérabilités du code, le processus doit être simple. Il est important de simplifier les corrections de sécurité, permettant ainsi aux développeurs de se concentrer sur leurs tâches directes. Dans GitLab 11.7, nous , mais il devait être téléchargé, appliqué localement et ensuite déplacé dans le dépôt distant.
Dans GitLab 11.9, ce processus est automatisé. Corrigez les vulnérabilités sans quitter l'interface web de GitLab. Une demande de fusion est créée directement à partir de la fenêtre d'informations sur les vulnérabilités, et cette nouvelle branche contiendra déjà le correctif. Après avoir vérifié si le problème a été résolu, ajoutez le correctif à la branche principale, si le pipeline est en ordre.
Affichage des résultats de l'analyse des conteneurs sur le tableau de bord de sécurité du groupe
(ULTIMATE, GOLD)
Le tableau de bord de sécurité du groupe permet aux spécialistes de se concentrer sur les questions les plus pertinentes, offrant une vue claire et détaillée de toutes les vulnérabilités susceptibles d'affecter les applications. C'est pourquoi il est important que le tableau contienne toutes les informations nécessaires au même endroit et permette aux utilisateurs d'examiner les données en profondeur avant de corriger les vulnérabilités.
Dans GitLab 11.9, les résultats de l'analyse des conteneurs ont été ajoutés au tableau de bord, en plus des résultats SAST et de l'analyse des dépendances déjà présents. Maintenant, l'ensemble de la vue est regroupé au même endroit, quel que soit l'origine du problème.
Modèles CI/CD pour les tâches de sécurité
(ULTIMATE, GOLD)
Les fonctionnalités de sécurité de GitLab évoluent très rapidement et nécessitent constamment des mises à jour pour maintenir l'efficacité et la protection du code. Modifier la définition d'un job est difficile lorsque l'on gère plusieurs projets. Et nous comprenons également : personne ne souhaite risquer d'utiliser la dernière version de GitLab sans être assuré de sa compatibilité totale avec l'instance actuelle de GitLab.
C'est précisément pour cette raison que nous avons introduit dans GitLab 11.7 un nouveau mécanisme de définition des jobs à l'aide de .
À partir de GitLab 11.9, nous proposerons des modèles intégrés pour tous les jobs de sécurité : par exemple, sast et analyse_des_dépendances, - compatibles avec la version correspondante de GitLab.
Intégrez-les directement dans votre configuration, et elles seront mises à jour avec le système à chaque mise à jour vers une nouvelle version de GitLab. Les configurations de pipeline restent inchangées.
La nouvelle façon de définir les jobs de sécurité est officielle et ne prend pas en charge d'autres définitions de jobs ou fragments de code précédents. Il convient de mettre à jour la définition dès que possible pour utiliser le nouveau mot-clé
template. Le support de toute autre syntaxe pourrait être supprimé dans GitLab 12.0 ou dans d'autres futures versions.
Autres améliorations dans GitLab 11.9
Répondre au commentaire
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab dispose de discussions sur des thèmes. Jusqu'à présent, l'utilisateur qui écrit le commentaire initial devait décider dès le départ s'il avait besoin d'une discussion.
Nous avons assoupli cette restriction. Prenez n'importe quel commentaire dans GitLab (sur des tâches, des demandes de fusion et des épiques) et répondez-y pour démarrer une discussion. Cela permet une interaction plus organisée entre les équipes.
Modèles de projets pour .NET, Go, iOS et Pages
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Pour faciliter la création de nouveaux projets par les utilisateurs, nous proposons plusieurs nouveaux modèles de projets :
- Initial , incluant une application de base avec CI.
- Modèle prêt à l'emploi combinant et GitLab CI/CD.
- , prête pour une personnalisation initiale dans GitLab. Veuillez noter que, comme un runner MacOS est nécessaire pour construire l'iOS, vous devrez fournir votre propre serveur de construction si vous souhaitez l'utiliser avec GitLab CI/CD.
- sont configurés pour travailler avec Netlify.
Exiger l'approbation des demandes de fusion par les Code Owners
(PREMIUM, ULTIMATE, SILVER, GOLD)
Il n'est pas toujours évident de savoir qui approuve une demande de fusion.
Maintenant, GitLab prend en charge l'exigence d'approuver une demande de fusion, en fonction des fichiers modifiés par la demande, grâce à . Les Code Owners sont désignés par un fichier appelé CODEOWNERS, dont le format est similaire à gitattributes.
Le support pour l'attribution automatique des Code Owners en tant que responsables de l'approbation de la demande de fusion a été ajouté dans .
Déplacement de fichiers dans l'IDE Web
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Dorénavant, en renommant un fichier ou un répertoire, il est possible de le déplacer de l'IDE Web vers le dépôt sous un nouveau chemin.
Étiquettes par ordre alphabétique
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Les étiquettes GitLab sont incroyablement polyvalentes, et les équipes leur trouvent constamment de nouvelles applications. Par conséquent, les utilisateurs ajoutent souvent beaucoup d'étiquettes aux tâches, aux demandes de fusion ou aux épiques.
Dans GitLab 11.9, nous avons légèrement simplifié l'utilisation des étiquettes. Dans les tâches, les demandes de fusion et les épiques, les étiquettes affichées sur la barre latérale sont classées par ordre alphabétique. Cela s'applique également à l'affichage de la liste de ces objets.
Commentaires rapides lors du filtrage des actions par tâche
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Nous avons récemment introduit une fonctionnalité permettant aux utilisateurs de filtrer le fil d'activités par tâches, merge requests ou épiques, ce qui leur permet de se concentrer uniquement sur les commentaires ou les notes système. Ce paramètre est conservé pour chaque utilisateur dans le système, et il arrive qu'un utilisateur ne comprenne pas que, en consultant une tâche plusieurs jours plus tard, il voit un fil filtré. Il a l'impression de ne pas pouvoir laisser de commentaire.
Nous avons amélioré cette interaction. Désormais, les utilisateurs peuvent rapidement basculer en mode leur permettant de laisser des commentaires sans faire défiler le fil jusqu'en haut. Cela concerne les tâches, les merge requests et les épiques.
Modifier l'ordre des épiques enfants
(ULTIMATE, GOLD)
Nous avons récemment publié , permettant d'utiliser des épiques de leurs épiques (en plus des tâches enfants des épiques).
Il est maintenant possible de modifier l'ordre des épiques enfants par simple glisser-déposer, comme pour les tâches enfants. Les équipes peuvent utiliser cet ordre pour refléter les priorités ou définir l'ordre d'exécution des travaux.
Messages système personnalisés en en-tête et pied de page dans le web et les e-mails
(CORE, STARTER, PREMIUM, ULTIMATE)
Auparavant, nous avons ajouté une fonctionnalité permettant aux messages personnalisés d'en-tête et de pied de page d'apparaître sur chaque page dans GitLab. Ils ont été accueillis chaleureusement, et les équipes les utilisent pour partager des informations importantes : par exemple, des messages système relatifs à leur instance GitLab.
Nous sommes heureux d'introduire cette fonctionnalité dans Core, permettant ainsi à encore plus de personnes de l'utiliser. De plus, nous permettons aux utilisateurs d'afficher les mêmes messages dans tous les e-mails envoyés via GitLab pour assurer la cohérence avec un autre point de contact utilisateur avec GitLab.
Filtrer par tâches confidentielles
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Les tâches confidentielles sont un outil utile pour les équipes, permettant de tenir des discussions privées sur des sujets délicats au sein d'un projet ouvert. En particulier, elles sont idéales pour travailler sur des vulnérabilités de sécurité. Jusqu'à présent, la gestion des tâches confidentielles n'était pas très facile.
Dans GitLab 11.9, la liste des tâches GitLab peut désormais être filtrée par tâches confidentielles ou non confidentielles. Cela concerne également la recherche de tâches via l'API.
Merci pour la contribution de Robert Schilling ()!
Édition de domaine Knative après déploiement
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Spécifier un domaine personnalisé lors de l'installation de Knative permet de servir différentes applications/fonctions serverless avec un point de terminaison unique.
L'intégration de Kubernetes dans GitLab permet maintenant de modifier/mettre à jour un domaine personnalisé après le déploiement de Knative dans un cluster Kubernetes.
Vérification du format du certificat CA de Kubernetes
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Lors de l'ajout d'un cluster Kubernetes existant, GitLab vérifie désormais que le certificat CA fourni a un format PEM valide. Cela élimine les erreurs potentielles lors de l'intégration de Kubernetes.
Extension de l'outil de comparaison de merge requests à l'ensemble du fichier
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
En examinant les modifications dans une merge request, il est désormais possible d'étendre l'outil de comparaison pour chaque fichier afin d'afficher l'ensemble du fichier pour plus de contexte, et de laisser des commentaires dans les lignes non modifiées.
Exécution de jobs spécifiques par merge requests uniquement en cas de modification de fichiers spécifiques
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Dans GitLab 11.6, nous avons ajouté la possibilité de définir pour les jobs des pipelines, permettant aux utilisateurs d'exécuter des tâches spécifiques uniquement lors de la création d'une merge request.
Nous étendons maintenant cette fonctionnalité : une logique de connexion a été ajoutée , et les utilisateurs peuvent exécuter des jobs spécifiques uniquement pour les merge requests et uniquement en cas de modification de fichiers spécifiques.
Merci pour la contribution de Hiroyuki Sato ()!
Surveillance automatique de GitLab avec Grafana
(CORE, STARTER, PREMIUM, ULTIMATE)
Grafana fait désormais partie de notre package Omnibus, ce qui facilite la compréhension du fonctionnement de votre instance.
Configurez grafana['enable'] = true dans gitlab.rb, et Grafana sera accessible à l'adresse : https://your.gitlab.instance/-/grafana. Dans un avenir proche, nous introduirons aussi « prêt à l'emploi ».
Vue des épics principaux dans la barre latérale des épics
(ULTIMATE, GOLD)
Nous avons récemment présenté , permettant d'utiliser des épics d'épics.
Dans GitLab 11.9, nous avons simplifié le mécanisme d'affichage de cette relation. Désormais, non seulement l'épic parent d'un épic donné est visible, mais aussi l'ensemble de l'arbre des épics dans la barre latérale droite. Il est possible de voir si ces épics sont fermés ou non, et même de naviguer directement vers eux.
Lien vers une nouvelle tâche à partir d'une tâche déplacée et fermée
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Dans GitLab, il est facile de déplacer une tâche vers un autre projet à l'aide de la barre latérale ou d'une action rapide. En coulisses, la tâche existante est fermée et une nouvelle tâche est créée dans le projet cible avec toutes les données copiées, y compris les notes système et les attributs de la barre latérale. C'est une fonctionnalité géniale.
Étant donné qu'il existe une note système concernant le déplacement, les utilisateurs qui consultent une tâche fermée sont souvent confus : ils ne peuvent pas comprendre que la tâche a été fermée en raison de son déplacement.
Dans cette version, nous indiquons directement sur l'icône en haut de la page de la tâche fermée qu'elle a été déplacée, et nous incluons également un lien intégré vers la nouvelle tâche, afin que quiconque a accès à l'ancienne puisse rapidement accéder à la nouvelle.
Intégration de YouTrack
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab s'intègre à de nombreux systèmes externes de suivi des tâches, ce qui facilite l'utilisation de GitLab par les équipes pour d'autres fonctions tout en conservant leur outil de gestion des tâches préféré.
Dans cette version, nous avons ajouté la possibilité d'intégrer YouTrack de JetBrains.
Merci à Kotau Yauhen pour sa contribution ()!
Redimensionnement de l'arbre des fichiers dans la demande de fusion
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Lors de la consultation des modifications d'une demande de fusion, il est désormais possible de redimensionner l'arbre des fichiers afin d'afficher de longs noms de fichiers ou de gagner de la place sur les petits écrans.
Accès aux derniers tableaux de tâches
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
Les tableaux de tâches sont très pratiques, et les équipes en créent plusieurs pour chaque projet et groupe. Récemment, nous avons ajouté un tableau de recherche pour filtrer rapidement tous les tableaux qui vous intéressent.
Dans GitLab 11.9, nous avons également introduit la section Récents dans le menu déroulant. Ainsi, vous pouvez rapidement accéder aux tableaux avec lesquels vous avez récemment interagi.
Possibilité pour les développeurs de créer des branches protégées
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Les branches protégées empêchent de déplacer ou de fusionner du code non révisé. Toutefois, si personne n'est autorisé à déplacer des branches protégées, alors personne ne peut créer une nouvelle branche protégée : par exemple, une branche de version.
Dans GitLab 11.9, les développeurs peuvent créer des branches protégées à partir de branches déjà protégées via GitLab ou l'API. L'utilisation de Git pour déplacer une nouvelle branche protégée est toujours limitée — afin de ne pas créer accidentellement de nouvelles branches protégées.
Dé-duplication des objets Git pour des branches ouvertes (Beta)
(CORE, STARTER, PREMIUM, ULTIMATE)
La branche permet à toute personne de participer à des projets open source : sans autorisation d'écriture, simplement en copiant le dépôt dans un nouveau projet. Stocker des copies complètes de dépôts Git souvent bifurqués n'est pas efficace. Maintenant, grâce à Git alternatives les branches partagent des objets communs du projet parent dans le pool d'objets pour réduire les exigences de stockage disque.
Les pools d'objets pour les branches ne sont créés que pour des projets ouverts lorsque le stockage haché est connecté. Les pools d'objets sont activés avec le paramètre de la fonction object_pools.
Filtrage de la liste des requêtes de fusion par les personnes approbatrices assignées
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
La révision du code est une pratique courante pour tout projet réussi, mais il peut être difficile pour le réviseur de suivre les requêtes de fusion.
Dans GitLab 11.9, la liste des requêtes de fusion est filtrée par la personne approbatrice assignée. Vous pouvez ainsi trouver les requêtes de fusion qui vous ont été ajoutées en tant que réviseur.
Merci pour la contribution de Glavin Wiechert ()!
Raccourcis clavier pour le fichier suivant et précédent dans la requête de fusion
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Lors de l'examen des modifications dans la requête de fusion, vous pouvez rapidement naviguer entre les fichiers en utilisant ]ou j pour aller au fichier suivant et [ ou k pour revenir au fichier précédent.
Simplification .gitlab-ci.yml pour des projets serverless
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Créé sur la base des fonctionnalités GitLab CI, le modèle serverless gitlab-ci.yml a été considérablement simplifié. Pour introduire de nouvelles fonctionnalités dans les versions futures, il n’est pas nécessaire de modifier ce fichier.
Support pour les noms d'hôtes Ingress
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Lors du déploiement du contrôleur Kubernetes Ingress, certaines plateformes retournent une adresse IP (par exemple, GKE de Google), tandis que d'autres retournent un nom DNS (par exemple, EKS d'AWS).
Notre intégration Kubernetes prend désormais en charge les deux types de points de terminaison à afficher dans la section clusters .
Merci pour la contribution d'Aaron Walker ()!
Restriction d'accès à JupyterHub uniquement pour les membres du groupe/projet
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Déployer JupyterHub grâce à l'intégration de GitLab avec Kubernetes est un excellent moyen de maintenir et d'utiliser Jupyter Notebook au sein de grandes équipes. Il est également utile de contrôler l'accès lors de la transmission de données sensibles ou personnelles.
Dans GitLab 11.9, l'accès aux instances JupyterHub déployées via Kubernetes est limité aux membres du projet ayant un niveau d'accès « développeur » (via un groupe ou un projet).
Plages horaires personnalisables pour les schémas du tableau de bord de sécurité
(ULTIMATE, GOLD)
Le tableau de bord de sécurité du groupe inclut un schéma de vulnérabilités pour passer en revue l'état actuel de la sécurité des projets du groupe. C'est très utile pour les directeurs de la sécurité afin d'ajuster les processus et de comprendre le mécanisme de travail de l'équipe.
Dans GitLab 11.9, il est désormais possible de choisir la plage horaire pour ce schéma de vulnérabilités. Par défaut, il s'agit des 90 derniers jours, mais vous pouvez définir une plage de 60 ou 30 jours, selon le niveau de détail requis.
Cela n'affecte pas les données dans les compteurs ou dans la liste, uniquement les points de données affichés sur le schéma.
Ajout d'un job de construction Auto DevOps pour les tags
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
L'étape de construction automatique d'Auto DevOps crée une construction de votre application en utilisant le Dockerfile du projet ou le paquet de construction Heroku.
Dans GitLab 11.9, l'image Docker obtenue, intégrée dans le pipeline de tags, est nommée de manière similaire aux noms d'images traditionnels à l'aide du tag de commit au lieu du commit SHA.
Merci pour la contribution d'Aaron Walker!
Mise à jour de Code Climate vers la version 0.83.0
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
GitLab utilise pour vérifier comment les modifications affectent l'état de votre code et de votre projet.
Dans GitLab 11.9, nous avons mis à jour le moteur vers la dernière version (), pour offrir les avantages d'un langage supplémentaire et du support d'analyse statique pour la qualité du code GitLab.
Merci pour la contribution du membre de l'équipe GitLab Core, Takuya Noguchi ()!
Mise à l'échelle et défilement du tableau de bord des métriques
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Lors de l'exploration des anomalies de performance, il est souvent utile de se pencher plus attentivement sur les différentes parties d'une métrique donnée.
Avec GitLab 11.9, les utilisateurs pourront mettre à l'échelle des périodes spécifiques sur le tableau de bord des métriques, faire défiler toute la période de temps et revenir facilement à l'affichage de l'intervalle de temps d'origine. Cela permet d'explorer facilement et rapidement les événements requis.
SAST pour TypeScript
(ULTIMATE, GOLD)
est un langage de programmation relativement nouveau basé sur .
Dans GitLab 11.9, la fonction de Test de Sécurité Statique des Applications (SAST) analyse et détecte les vulnérabilités dans le code TypeScript, les affichant dans le widget de la demande de fusion, au niveau du pipeline et dans le tableau de bord de sécurité. La définition actuelle du job sast n'a pas besoin d'être modifiée, et elle est également activée automatiquement dans .
SAST pour les projets Maven multi-modules
(ULTIMATE, GOLD)
Les projets Maven sont souvent organisés de manière à regrouper dans un seul référentiel. Auparavant, GitLab ne pouvait pas correctement analyser de tels projets, et les développeurs ainsi que les spécialistes de la sécurité ne recevaient pas de rapports sur les vulnérabilités.
GitLab 11.9 propose un soutien renforcé pour la fonction SAST dans cette configuration de projet spécifique, permettant de les tester pour déceler des vulnérabilités dans l'état initial. Grâce à la flexibilité des analyseurs, la configuration est déterminée automatiquement, et vous n'avez rien à modifier pour visualiser les résultats concernant les applications Maven multi-modules. Comme d'habitude, des améliorations similaires sont également disponibles dans le cadre de .
GitLab Runner 11.9
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Nous avons également lancé GitLab Runner 11.9 aujourd'hui ! GitLab Runner est un projet open source utilisé pour exécuter des tâches CI/CD et renvoyer les résultats dans GitLab.
Voici quelques changements dans GitLab Runner 11.9 :
- .
- et .
- . Cela exclut également .
- pour supporter , qui sera présent dans GitLab 11.10.
- .
- .
- Déplacement de plusieurs scripts — y compris et — vers Go.
- .
- .
- .
La liste complète des changements peut être trouvée dans le journal des modifications de GitLab Runner : .
Améliorations du schéma GitLab
(CORE, STARTER, PREMIUM, ULTIMATE)
Des améliorations ont été apportées au chart GitLab :
- Ajout de la prise en charge de Google Cloud Memorystore.
- Les paramètres de Cron job , car ils sont utilisés par plusieurs services.
- Le registre a été mis à jour vers la version 2.7.1.
- Un nouveau paramètre a été ajouté pour garantir la compatibilité du registre GitLab avec les versions de Docker jusqu'à 1.10. Pour l'activer, définissez
registry.compatibility.schema1.enabled: true.
Amélioration des performances
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Nous continuons à améliorer les performances de GitLab à chaque version pour des instances de GitLab de toute taille. Voici quelques améliorations dans GitLab 11.9 :
- .
- .
- .
- .
Améliorations d'Omnibus
(CORE, STARTER, PREMIUM, ULTIMATE)
Les améliorations Omnibus de GitLab 11.9 incluent :
- GitLab 11.9 inclut , , dont la dernière version inclut l'MFA pour Team Edition, des performances améliorées des images et bien plus encore. Cette version inclut également ; une mise à jour est recommandée.
- Un nouveau paramètre a été ajouté pour garantir la compatibilité du registre GitLab avec les versions de Docker jusqu'à 1.10. Pour l'activer, définissez
registry['compatibility_schema1_enabled'] = true dans gitlab.rb. - Le registre GitLab exporte désormais des métriques Prometheus et est automatiquement surveillé par le .
- Ajout d'un support pour Google Cloud Memorystore, qui nécessite .
opensslmis à jour vers la version 1.0.2r,nginx— vers la version 1.14.2,python— vers la version 3.4.9,jemalloc— vers la version 5.1.0,docutils— vers la version 0.13.1,gitlab-monitor— vers la version 3.2.0.
Fonctionnalités obsolètes
GitLab Geo permettra le stockage haché dans GitLab 12.0
GitLab Geo nécessite pour atténuer la condition de concurrence sur les nœuds secondaires. Cela a été noté dans .
Dans GitLab , nous avons ajouté cette exigence à la documentation Geo : .
Dans GitLab sudo gitlab-rake gitlab: geo: check vérifie si le stockage haché est activé et si tous les projets sont transférés. Voir. . Si vous utilisez Geo, veuillez effectuer cette vérification et migrer dès que possible.
Dans GitLab un avertissement désactivable en permanence sera affiché sur la page Admin Area › Geo › Nodes, si les vérifications mentionnées ci-dessus ne sont pas autorisées.
Dans GitLab Geo utilisera les exigences du stockage haché. Voir. .
Date de retrait : 22 juin 2019.
Intégration Hipchat
Hipchat . De plus, dans la version 11.9, .
Date de retrait : 22 mars 2019.
Support de CentOS 6 pour GitLab Runner via Docker executor
GitLab Runner ne prend pas en charge CentOS 6 lorsqu'il est utilisé avec Docker dans GitLab 11.9. Cela résulte de la mise à jour de la bibliothèque de base de Docker, qui ne prend plus en charge CentOS 6. Pour plus de détails, consultez .
Date de retrait : 22 mars 2019.
Les chemins de code legacy obsolètes de GitLab Runner
À partir de Gitlab 11.9, GitLab Runner utilise de clonage/appel de référentiel. Actuellement, GitLab Runner utilisera l'ancienne méthode si la nouvelle n'est pas prise en charge.
Dans GitLab 11.0, nous avons modifié la configuration du serveur de métriques pour GitLab Runner. metrics_server sera supprimé au profit de listen_address dans GitLab 12.0. Pour plus de détails, consultez . Et encore plus de détails dans .
À partir de la version 11.3, GitLab Runner a commencé à prendre en charge , ce qui a conduit à de nouvelles configurations pour . Il y a un tableau des changements et des instructions pour la transition vers la nouvelle configuration. Pour plus de détails, consultez .
Ces chemins ne sont plus disponibles dans GitLab 12.0. En tant qu'utilisateur, vous n'avez rien à changer, juste vous assurer que l'instance GitLab fonctionne avec la version 11.9+ lors de la mise à jour vers GitLab Runner 12.0.
Date de retrait : 22 juin 2019.
Paramètre obsolète pour la fonctionnalité de point d'entrée pour GitLab Runner
Dans la version 11.4, GitLab Runner a introduit le paramètre de fonctionnalité pour corriger des problèmes comme et .
Dans GitLab 12.0, nous passerons à un comportement correct, comme si le paramètre de fonctionnalité était désactivé. Pour plus de détails, consultez .
Date de retrait : 22 juin 2019.
Support obsolète pour les distributions Linux arrivées à EOL pour GitLab Runner
Certaines distributions Linux sur lesquelles GitLab Runner peut être installé ont atteint leur fin de vie.
Dans GitLab 12.0, GitLab Runner ne distribuera plus de paquets pour ces distributions Linux. Vous pouvez trouver une liste complète des distributions qui ne sont plus prises en charge dans notre . Merci à Javier Ardo () pour sa !
Date de retrait : 22 juin 2019.
Suppression des anciennes commandes GitLab Runner Helper
Dans le cadre des efforts pour soutenir , il a fallu abandonner certaines anciennes commandes utilisées pour .
Dans GitLab 12.0, GitLab Runner s'exécute avec de nouvelles commandes. Cela concerne uniquement les utilisateurs qui redéfinissent . Pour plus de détails, consultez .
Date de retrait : 22 juin 2019.
Les développeurs peuvent supprimer des tags Git dans GitLab 11.10
La suppression ou la modification des notes de version pour les tags Git dans les branches non protégées a historiquement été limitée aux .
Étant donné que les développeurs peuvent ajouter des tags ainsi que modifier et supprimer des branches non sécurisées, ils doivent être en mesure de supprimer des tags Git. Dans GitLab 11.10 à notre modèle d'autorisations pour améliorer le flux de travail et aider les développeurs à mieux et plus efficacement utiliser les tags.
Si vous souhaitez maintenir cette restriction pour les mainteneurs et les propriétaires, utilisez .
Date de retrait : 22 avril 2019
Prise en charge de Prometheus 1.x dans Omnibus GitLab
À partir de GitLab , la version intégrée de Prometheus 1.0 est exclue de Omnibus GitLab. . Cependant, le format des métriques n'est pas compatible avec la version 1.0. Les versions existantes peuvent être mises à niveau vers 2.0 et, si nécessaire, les données peuvent être transférées .
Dans les versions de GitLab Prometheus 2.0 sera installé automatiquement, si aucune mise à jour n'a encore eu lieu. Les données de Prometheus 1.0 seront perdues, car elles ne seront pas transférées.
Date de retrait : 22 juin 2019.
TLS v1.1
À partir de GitLab pour améliorer la sécurité. Cela résout de nombreux problèmes, y compris Heartbleed, et rend GitLab 'prêt à l'emploi' conforme à la norme PCI DSS 3.1.
Pour désactiver immédiatement TLS v1.1, définissez nginx['ssl_protocols'] = "TLSv1.2" dans gitlab.rband et exécutez gitlab-ctl reconfigure.
Date de retrait : 22 juin 2019.
Modèle OpenShift pour installer GitLab
Officiel — méthode recommandée pour exécuter GitLab sur Kubernetes, y compris .
pour l'installation de GitLab est obsolète et ne sera plus pris en charge dans .
Date de retrait : 22 juin 2019.
Les précédentes définitions des jobs de sécurité
Avec l'introduction toutes les précédentes définitions de jobs deviendront obsolètes et seront supprimées dans GitLab 12.0 ou ultérieure.
Mettez à jour les définitions des jobs pour utiliser la nouvelle syntaxe et profiter de toutes les nouvelles fonctionnalités de sécurité offertes par GitLab.
Date de suppression : 22 juin 2019.
La section Infos système dans le panneau d'administration
GitLab fournit des informations sur votre instance GitLab dans admin/system_info, mais ces informations peuvent être inexactes.
Nous du panneau d'administration dans GitLab 12.0 et recommandons d'utiliser .
Date de retrait : 22 juin 2019.
Source : habr.com
