Détectez rapidement les secrets divulgués
Cela semblerait être une petite erreur de transmettre accidentellement des informations d'identification à un référentiel partagé. Toutefois, les conséquences peuvent être graves. Une fois que l’attaquant aura obtenu votre mot de passe ou votre clé API, il prendra possession de votre compte, vous bloquera et utilisera votre argent de manière frauduleuse. De plus, un effet domino est possible : l’accès à un compte ouvre l’accès aux autres. Les enjeux sont élevés, il est donc extrêmement important de découvrir les secrets divulgués le plus rapidement possible.
Dans cette version, nous introduisons l'option dans le cadre de notre fonctionnalité SAST. Chaque validation est analysée dans la tâche CI/CD à la recherche de secrets. Il y a un secret – et le développeur reçoit un avertissement dans la demande de fusion. Il révoque sur place les informations d’identification divulguées et en crée de nouvelles.
Assurer une bonne gestion du changement
À mesure qu’elle se développe et devient plus complexe, il devient plus difficile de maintenir la cohérence entre les différentes parties d’une organisation. Plus il y a d'utilisateurs de l'application et plus les revenus sont élevés, plus les conséquences de la fusion de codes incorrects ou dangereux sont graves. Pour de nombreuses organisations, garantir un processus de révision approprié avant de fusionner du code est une exigence stricte car les risques sont très élevés.
GitLab 11.9 vous offre plus de contrôle et une structure plus efficace, grâce à . Auparavant, pour obtenir une autorisation, il suffisait d'identifier un individu ou un groupe (dont chaque membre pouvait accorder une autorisation). Vous pouvez désormais ajouter plusieurs règles afin qu'une demande de fusion nécessite l'autorisation d'individus spécifiques ou même de plusieurs membres d'un groupe spécifique. De plus, la fonctionnalité Code Owners est intégrée aux règles de permis, ce qui facilite l'identification de la personne qui a délivré le permis.
Cela permet aux organisations de mettre en œuvre des processus de résolution complexes tout en conservant la simplicité d'une seule application GitLab où les problèmes, le code, les pipelines et les données de surveillance sont visibles et accessibles pour prendre des décisions et accélérer le processus de résolution.
ChatOps est désormais open source
GitLab ChatOps est un outil d'automatisation puissant qui vous permet d'exécuter n'importe quelle tâche CI/CD et d'interroger son état directement dans des applications de chat comme Slack et Mattermost. , ChatOps faisait partie de l'abonnement GitLab Ultimate. Basé и , nous déplaçons parfois les fonctionnalités d'un niveau vers le bas et jamais vers le haut.
Dans le cas de ChatOps, nous avons réalisé que cette fonctionnalité peut être utile à tout le monde et que la participation de la communauté peut bénéficier à la fonctionnalité elle-même.
Dans GitLab 11.9, nous , et il est donc désormais disponible gratuitement pour une utilisation dans GitLab Core autogéré et sur GitLab.com et ouvert à la communauté.
ногое ругое !
Il y a tellement de fonctionnalités intéressantes disponibles dans cette version, par ex. , и , - qu'on a hâte de vous en parler !
Employé le plus précieux () ce mois-ci est reconnu par Marcel Amirault ()
Marcel nous a constamment aidé à améliorer la documentation GitLab. Il pour améliorer la qualité et la convivialité de nos documents. Domo arigato [merci beaucoup (japonais) - env. trans.] Marcel, nous l'apprécions sincèrement !
Principales fonctionnalités ajoutées dans la version GitLab 11.9
Découverte de secrets et d'informations d'identification dans un référentiel
(ULTIME, OR)
Les développeurs divulguent parfois involontairement des secrets et des informations d'identification vers des référentiels distants. Si d'autres personnes ont accès à cette source ou si le projet est public, des informations sensibles sont alors exposées et peuvent être utilisées par des attaquants pour accéder à des ressources telles que des environnements de déploiement.
GitLab 11.9 a un nouveau test - « Détection secrète ». Il analyse le contenu du référentiel à 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 demande de fusion, les rapports de pipeline et 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é. Il est également inclus dans la configuration par défaut.
Règles de résolution des demandes de fusion
(PREMIUM, ULTIME, ARGENT, OR)
La révision du code est un élément essentiel de tout projet réussi, mais il n'est pas toujours clair qui doit réviser les modifications. Il est souvent souhaitable d’avoir des évaluateurs issus de différentes équipes : l’équipe de développement, l’équipe expérience utilisateur, l’équipe de production.
Les règles d'autorisation vous permettent d'améliorer le processus d'interaction entre les personnes impliquées dans la révision du code en définissant le cercle d'approbateurs autorisés et le nombre minimum d'autorisations. Les règles de résolution sont affichées dans le widget de demande de fusion afin que vous puissiez rapidement attribuer le réviseur suivant.
Dans GitLab 11.8, les règles d'autorisation étaient désactivées par défaut. À partir de GitLab 11.9, ils sont disponibles par défaut. Dans GitLab 11.3, nous avons introduit l'option pour identifier les membres de l'équipe responsables de codes individuels au sein d'un projet. La fonctionnalité Propriétaires de code est intégrée aux règles d'autorisation afin que vous puissiez toujours trouver rapidement les bonnes personnes pour examiner les modifications.
Déplacer ChatOps vers Core
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Initialement introduit dans GitLab Ultimate 10.6, ChatOps a été migré vers GitLab Core. GitLab ChatOps offre la possibilité d'exécuter des tâches GitLab CI via Slack à l'aide de la fonctionnalité .
Nous open sourceons cette fonctionnalité selon notre . En l'utilisant plus souvent, la communauté contribuera davantage.
Audit des paramètres de fonction
(PREMIUM, ULTIME, ARGENT, OR)
Les opérations telles que l'ajout, la suppression ou la modification des paramètres de fonctionnalité sont désormais enregistrées dans le journal d'audit GitLab, afin que vous puissiez voir ce qui a été modifié et quand. Il y a eu un accident et vous avez besoin de voir ce qui a changé récemment ? Ou avez-vous simplement besoin de vérifier comment les paramètres de fonction ont été modifiés dans le cadre d'un audit ? Maintenant, c'est très facile à faire.
Correction des vulnérabilités des demandes de fusion
(ULTIME, OR)
Pour résoudre rapidement les vulnérabilités du code, le processus doit être simple. Il est important de simplifier les correctifs de sécurité, afin de permettre aux développeurs de se concentrer sur leurs responsabilités. Dans GitLab 11.7, nous , mais il devait être téléchargé, appliqué localement, puis transféré vers le référentiel 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 la vulnérabilité, et cette nouvelle branche contiendra déjà le correctif. Après avoir vérifié si le problème est résolu, ajoutez le correctif à la branche amont si le pipeline est correct.
Affichage des résultats de l'analyse des conteneurs dans le panneau de sécurité du groupe
(ULTIME, OR)
Le tableau de bord de sécurité de l'équipe permet aux équipes de se concentrer sur les problèmes les plus critiques pour leur travail, en fournissant un aperçu clair et détaillé de toutes les vulnérabilités potentielles qui pourraient avoir un impact sur les applications. C'est pourquoi il est important que le tableau de bord contienne toutes les informations nécessaires en un seul endroit et permette aux utilisateurs d'explorer les données avant de résoudre 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 de l'analyse SAST et des dépendances existants. Désormais, l’ensemble de l’aperçu se trouve au même endroit, quelle que soit la source du problème.
Modèles CI/CD pour les tâches de sécurité
(ULTIME, OR)
Les fonctionnalités de sécurité de GitLab évoluent très rapidement et nécessitent des mises à jour constantes pour que votre code reste efficace et sécurisé. Changer la définition d’un métier est difficile lorsque l’on gère plusieurs projets. Et nous comprenons également que personne ne veut prendre le risque d’utiliser la dernière version de GitLab sans être sûr qu’elle est entièrement compatible avec l’instance actuelle de GitLab.
C'est pour cette raison que nous avons introduit dans GitLab 11.7 un nouveau mécanisme de définition de tâches utilisant .
À partir de GitLab 11.9, nous proposerons des modèles intégrés pour toutes les tâches de sécurité : par exemple, sast и dependency_scanning, - compatible avec la version correspondante de GitLab.
Incluez-les directement dans votre configuration et ils seront mis à jour avec le système chaque fois que vous passerez à une nouvelle version de GitLab. Les configurations du pipeline ne changent pas.
La nouvelle façon de définir les tâches de sécurité est officielle et ne prend en charge aucune autre définition de tâche ou extrait de code précédent. Vous devez mettre à jour votre définition dès que possible pour utiliser le nouveau mot-clé
template. La prise en charge de toute autre syntaxe peut être supprimée dans GitLab 12.0 ou dans d'autres versions futures.
Autres améliorations dans GitLab 11.9
Répondre au commentaire
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
GitLab a des discussions sur des sujets. Jusqu'à présent, la personne qui rédigeait le commentaire original devait décider dès le départ si elle souhaitait ou non une discussion.
Nous avons assoupli cette restriction. Prenez n'importe quel commentaire dans GitLab (sur les problèmes, les demandes de fusion et les épopées) et répondez-y, démarrant ainsi une discussion. De cette façon, les équipes interagissent de manière plus organisée.
Modèles de projet pour .NET, Go, iOS et Pages
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Pour permettre aux utilisateurs de créer plus facilement de nouveaux projets, nous proposons plusieurs nouveaux modèles de projet :
- Initiale , qui comprend une application de base avec CI.
- Un modèle prêt à l'emploi qui combine et GitLab CI/CD.
- , prêt pour la personnalisation initiale dans GitLab. Notez que puisque les builds iOS nécessitent un exécuteur MacOS dédié, vous devrez fournir votre propre serveur de build si vous souhaitez l'utiliser avec GitLab CI/CD.
- configuré pour fonctionner avec Netlify.
Exiger l'autorisation pour les demandes de fusion des propriétaires de code
(PREMIUM, ULTIME, ARGENT, OR)
Il n’est pas toujours évident de savoir qui approuve une demande de fusion.
GitLab prend désormais en charge l'exigence d'approbation d'une demande de fusion en fonction des fichiers modifiés par la demande, en utilisant . Les propriétaires de code sont attribués à l'aide d'un fichier appelé CODEOWNERS, le format est similaire à gitattributes.
La prise en charge de l'affectation automatique des propriétaires de code en tant que personnes responsables de l'approbation d'une demande de fusion a été ajoutée dans .
Déplacement de fichiers dans l'IDE Web
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Maintenant, après avoir renommé le fichier ou le répertoire, vous pouvez le déplacer de l'IDE Web vers le référentiel le long du nouveau chemin.
Balises par ordre alphabétique
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Les balises GitLab sont incroyablement polyvalentes et les équipes leur trouvent constamment de nouvelles utilisations. En conséquence, les utilisateurs ajoutent souvent de nombreuses balises à un problème, une demande de fusion ou une épopée.
Dans GitLab 11.9, nous avons rendu l'utilisation des étiquettes un peu plus facile. Pour les tickets, les demandes de fusion et les epics, les étiquettes affichées dans la barre latérale sont classées par ordre alphabétique. Ceci 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, GRATUIT, BRONZE, ARGENT, OR)
Nous avons récemment introduit une fonctionnalité qui permet aux utilisateurs de filtrer le flux d'activité par tâches, demandes de fusion ou épopées, ce qui leur permet de se concentrer uniquement sur les commentaires ou les notes système. Ce paramètre est enregistré pour chaque utilisateur du système, et il peut arriver qu'un utilisateur ne se rende pas compte que lorsqu'il consulte un problème plusieurs jours plus tard, il voit un flux filtré. Il a l'impression qu'il ne peut pas laisser de commentaire.
Nous avons amélioré cette interaction. Les utilisateurs peuvent désormais passer rapidement à un mode qui leur permet de laisser des commentaires sans revenir en haut du flux. Cela s'applique aux tâches, aux demandes de fusion et aux epics.
Changer l'ordre des épopées enfants
(ULTIME, OR)
Nous avons récemment publié , qui permettent l'utilisation d'epics of epics (en plus des tâches enfants d'epics).
Vous pouvez désormais réorganiser l'ordre des épopées enfants par simple glisser-déposer, tout comme pour les problèmes enfants. Les équipes peuvent utiliser l'ordre pour refléter la priorité ou déterminer l'ordre dans lequel le travail doit être effectué.
Messages système d'en-tête et de pied de page personnalisés sur le Web et par courrier électronique
(CORE, STARTER, PREMIUM, ULTIMATE)
Nous avons précédemment ajouté une fonctionnalité qui permet aux messages d'en-tête et de pied de page personnalisés d'apparaître sur chaque page de GitLab. Il a été chaleureusement accueilli et les équipes l'utilisent pour partager des informations importantes, telles que des messages système liés à leur instance GitLab.
Nous sommes ravis d'apporter cette fonctionnalité à Core afin qu'encore plus de personnes puissent l'utiliser. De plus, nous permettons aux utilisateurs d'afficher éventuellement les mêmes messages dans tous les e-mails envoyés via GitLab pour plus de cohérence entre les autres points de contact GitLab de l'utilisateur.
Filtrer par tâches confidentielles
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Confidential Issues est un outil utile permettant aux équipes de permettre des discussions privées sur des sujets sensibles au sein d'un projet ouvert. Ils sont notamment idéaux pour travailler sur les failles de sécurité. Jusqu’à présent, gérer des tâches sensibles n’était pas chose aisée.
Dans GitLab 11.9, la liste des problèmes GitLab est désormais filtrée par problèmes sensibles ou non sensibles. Cela s'applique également à la recherche de tâches à l'aide de l'API.
Merci à Robert Schilling pour sa contribution)!
Modification d'un domaine Knative après le déploiement
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
La spécification d'un domaine personnalisé lors de l'installation de Knative vous permet de servir diverses applications/fonctionnalités sans serveur à partir d'un point de terminaison unique.
L'intégration de Kubernetes dans GitLab vous permet désormais de modifier/mettre à jour le domaine utilisateur après le déploiement de Knative sur le cluster Kubernetes.
Vérification du format du certificat Kubernetes CA
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Lors de l'ajout d'un cluster Kubernetes existant, GitLab vérifie désormais que le certificat CA saisi est au format PEM valide. Cela élimine les erreurs potentielles liées à l’intégration de Kubernetes.
Extension de l'utilitaire de comparaison des demandes de fusion à l'ensemble du fichier
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Lors de l'affichage des modifications apportées à une demande de fusion, vous pouvez désormais étendre l'utilitaire de comparaison fichier par fichier pour afficher l'intégralité du fichier pour plus de contexte et laisser des commentaires sur les lignes inchangées.
Exécuter des tâches spécifiques basées sur des demandes de fusion uniquement lorsque certains fichiers changent
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
GitLab 11.6 a ajouté la possibilité de définir pour les tâches de pipeline afin que les utilisateurs puissent effectuer des tâches spécifiques uniquement lors de la création d'une demande de fusion.
Nous étendons maintenant cette fonctionnalité : une logique de connexion a été ajoutée , et les utilisateurs peuvent exécuter des tâches spécifiques uniquement pour les demandes de fusion et uniquement lorsque certains fichiers changent.
Merci pour la contribution Hiroyuki Sato ()!
Surveillance automatisée de GitLab avec Grafana
(CORE, STARTER, PREMIUM, ULTIMATE)
Grafana est désormais inclus dans notre package Omnibus, ce qui facilite la compréhension du fonctionnement de votre instance.
Personnaliser grafana['enable'] = true в gitlab.rb, et Grafana seront disponibles sur : https://your.gitlab.instance/-/grafana. Dans un avenir proche, nous allons également "hors de la boîte".
Afficher les épopées principales dans la barre latérale des épopées
(ULTIME, OR)
Nous avons récemment introduit , permettant l'utilisation d'épopées d'épopées.
Dans GitLab 11.9, nous avons facilité la visualisation de cette relation. Vous pouvez désormais voir non seulement l’épopée mère d’une épopée donnée, mais également l’intégralité de l’arbre épique dans la barre latérale de droite. Vous pouvez voir si ces épopées sont fermées ou non, et vous pouvez même y accéder directement.
Lien vers une nouvelle tâche à partir d'une tâche déplacée et fermée
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Dans GitLab, vous pouvez facilement déplacer un problème vers un autre projet à l'aide de la barre latérale ou d'une action rapide. En arrière-plan, 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é intéressante.
Étant donné qu'il existe une note système concernant le déplacement, les utilisateurs qui visualisent une tâche fermée sont confus et ne peuvent s'empêcher de se rendre compte que la tâche a été fermée en raison d'un déplacement.
Avec cette version, nous indiquons clairement dans l'icône en haut de la page d'un numéro fermé qu'il a été déplacé, et nous incluons également un lien intégré vers le nouveau numéro afin que toute personne arrivant sur l'ancien numéro puisse rapidement accédez au nouveau.
Intégration YouTrack
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
GitLab s'intègre à de nombreux systèmes externes de suivi des problèmes, ce qui permet aux équipes d'utiliser facilement GitLab pour d'autres fonctions tout en conservant l'outil de gestion des problèmes de leur choix.
Dans cette version, nous avons ajouté la possibilité d'intégrer YouTrack de JetBrains.
Nous tenons à remercier Kotau Jauchen pour sa contribution ()!
Redimensionner l'arborescence des fichiers de demande de fusion
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Lors de l'affichage des modifications apportées aux demandes de fusion, vous pouvez désormais redimensionner l'arborescence des fichiers pour afficher les noms de fichiers longs ou économiser de l'espace sur des écrans plus petits.
Accédez aux barres de tâches récentes
(STARTER, PREMIUM, ULTIMATE, BRONZE, ARGENT, OR)
Les tableaux de bord sont très utiles et les équipes créent plusieurs tableaux de bord pour chaque projet et groupe. Nous avons récemment ajouté une barre de recherche pour filtrer rapidement tous les panneaux qui vous intéressent.
Dans GitLab 11.9, nous avons également introduit une section Articles de dans la liste déroulante. De cette façon, vous pouvez accéder rapidement aux panneaux avec lesquels vous avez récemment interagi.
Possibilité pour les développeurs de créer des branches protégées
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Les branches protégées empêchent le déplacement ou la fusion du code non révisé. Cependant, 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 publication.
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 encore limitée pour éviter de créer accidentellement de nouvelles branches protégées.
Déduplication d'objets Git pour Open Forks (bêta)
(CORE, STARTER, PREMIUM, ULTIMATE)
Forking permet à n'importe qui de contribuer à des projets open source : sans autorisation en écriture, simplement en copiant le référentiel dans un nouveau projet. Le stockage de copies complètes des référentiels Git fréquemment dupliqués est inefficace. Maintenant avec Git alternatives Les forks partagent des objets communs du projet parent dans un pool d'objets pour réduire les besoins en stockage sur disque.
Les pools d'objets Fork sont créés uniquement pour les projets ouverts lorsque le stockage haché est activé. Les pools d'objets sont activés à l'aide d'un paramètre de fonction object_pools.
Filtrage de la liste des demandes de fusion par approbateurs attribués
(STARTER, PREMIUM, ULTIMATE, BRONZE, ARGENT, OR)
La révision du code est une pratique courante pour tout projet réussi, mais il peut être difficile pour un réviseur de suivre les demandes de fusion.
Dans GitLab 11.9, la liste des demandes de fusion est filtrée par approbateur attribué. De cette façon, vous pouvez trouver les demandes de fusion qui vous sont ajoutées en tant que réviseur.
Merci à Glewin Wiechert pour ses contributions ()!
Raccourcis pour le fichier suivant et précédent dans une demande de fusion
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Lors de l'affichage des modifications apportées à une demande de fusion, vous pouvez rapidement basculer entre les fichiers en utilisant ]ou j pour passer au fichier suivant et [ ou k pour aller au fichier précédent.
Simplification .gitlab-ci.yml pour les projets sans serveur
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Construit sur la fonctionnalité GitLab CI, modèle sans serveur gitlab-ci.yml grandement simplifié. Pour introduire de nouvelles fonctionnalités dans les versions futures, vous n'avez pas besoin d'apporter de modifications à ce fichier.
Prise en charge du nom d'hôte d'entrée
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Lors du déploiement d'un contrôleur Kubernetes Ingress, certaines plates-formes s'appuient sur une adresse IP (par exemple, GKE de Google), tandis que d'autres s'appuient sur 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 le projet.
Merci à Aaron Walker pour sa contribution ()!
Restreindre l'accès à la connexion JupyterHub aux membres de l'équipe/du projet uniquement
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Le déploiement de JupyterHub à l'aide de l'intégration Kubernetes de GitLab est un excellent moyen de maintenir et d'utiliser les notebooks Jupyter dans de grandes équipes. Il est également utile d’en contrôler l’accès lors de la transmission de données confidentielles ou personnelles.
Dans GitLab 11.9, la possibilité de se connecter aux instances JupyterHub déployées via Kubernetes est limitée aux membres du projet ayant un accès développeur (via un groupe ou un projet).
Plages de temps personnalisables pour les schémas de panneaux de sécurité
(ULTIME, OR)
Le tableau de bord de sécurité de l'équipe comprend une carte des vulnérabilités pour fournir un aperçu de l'état de sécurité actuel des projets de l'équipe. Ceci est très utile aux directeurs de sécurité pour mettre en place des processus et comprendre le fonctionnement de l’équipe.
Dans GitLab 11.9, vous pouvez désormais sélectionner la plage de temps pour cette carte de vulnérabilité. Par défaut, il s'agit des 90 derniers jours, mais vous pouvez définir la période sur 60 ou 30 jours, selon le niveau de détail dont vous avez besoin.
Cela n'affecte pas les données des compteurs ou de la liste, uniquement les points de données affichés dans le diagramme.
Ajout d'une tâche de build Auto DevOps pour les balises
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
L'étape de génération Auto DevOps crée une version de votre application à l'aide du Dockerfile de votre projet ou buildpack Heroku.
Dans GitLab 11.9, l'image Docker résultante intégrée dans le pipeline de balises est nommée de la même manière que les noms d'image traditionnels en utilisant une validation de balise au lieu d'une validation SHA.
Merci à Aaron Walker pour sa contribution !
Mettre à jour Code Climate vers la version 0.83.0
(STARTER, PREMIUM, ULTIMATE, BRONZE, ARGENT, OR)
gitlab ce 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'une prise en charge supplémentaire du langage et de l'analyse statique pour GitLab Code Quality.
Merci à Takuya Noguchi, membre de l'équipe GitLab Core, pour ses contributions ()!
Zoomer et faire défiler le panneau de métriques
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Lors de l’enquête sur les anomalies de performances, il est souvent utile d’examiner de plus près les différentes parties d’une métrique particulière.
Avec GitLab 11.9, les utilisateurs pourront zoomer sur des périodes individuelles dans le panneau de métriques, faire défiler une période entière et revenir facilement à la vue de l'intervalle de temps d'origine. Cela vous permet de rechercher rapidement et facilement les événements dont vous avez besoin.
SAST pour TypeScript
(ULTIME, OR)
est un langage de programmation relativement nouveau basé sur .
Dans GitLab 11.9, Static Application Security Testing (SAST) analyse et détecte les vulnérabilités dans le code TypeScript, en les démontrant dans le widget de demande de fusion, au niveau du pipeline et dans le tableau de bord de sécurité. Définition actuelle du poste sast pas besoin de changer, et il est également automatiquement inclus dans .
SAST pour les projets Maven multi-modules
(ULTIME, OR)
Les projets Maven sont souvent organisés pour combiner dans un seul référentiel. Auparavant, GitLab ne pouvait pas analyser correctement ces projets, et les développeurs et les spécialistes de la sécurité ne recevaient pas de rapports sur les vulnérabilités.
GitLab 11.9 offre une prise en charge étendue de la fonctionnalité SAST pour cette configuration de projet spécifique, offrant la possibilité de tester les vulnérabilités telles quelles. Grâce à la flexibilité des analyseurs, la configuration est déterminée automatiquement et vous n'avez rien à modifier pour afficher les résultats des applications Maven multi-modules. Comme d'habitude, des améliorations similaires sont également disponibles dans .
Exécuteur GitLab 11.9
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Aujourd'hui, nous avons également publié GitLab Runner 11.9 ! GitLab Runner est un projet open source et est utilisé pour exécuter des tâches CI/CD et renvoyer les résultats à GitLab.
Vous trouverez ci-dessous quelques-uns des changements apportés à GitLab Runner 11.9 :
- .
- и .
- ... c'est le même .
- pour le soutien , qui apparaîtra dans GitLab 11.10.
- .
- .
- Déplacement de plusieurs scripts - y compris и - en Go.
- .
- .
- .
La liste complète des modifications peut être trouvée dans le journal des modifications de GitLab Runner : .
Améliorations du schéma GitLab
(CORE, STARTER, PREMIUM, ULTIMATE)
Les améliorations suivantes ont été apportées au graphique GitLab :
- Ajout de la prise en charge de Google Cloud Memorystore.
- Paramètres de la tâche Cron , puisqu'ils sont utilisés par plusieurs services.
- Le registre a été mis à jour vers la version 2.7.1.
- Ajout d'un nouveau paramètre pour rendre le registre GitLab compatible avec les versions de Docker antérieures à 1.10. Pour l'activer, installez
registry.compatibility.schema1.enabled: true.
Amélioration des performances
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZE, ARGENT, OR)
Nous continuons d'améliorer les performances de GitLab avec chaque version pour les instances GitLab de toutes tailles. Voici quelques améliorations dans GitLab 11.9 :
- .
- .
- .
- .
Améliorations générales
(CORE, STARTER, PREMIUM, ULTIMATE)
GitLab 11.9 inclut les améliorations Omnibus suivantes :
- GitLab 11.9 inclut , , dont la dernière version inclut MFA pour Team Edition, des performances d'image améliorées, et bien plus encore. Cette version comprend également ; mise à jour recommandée.
- Ajout d'un nouveau paramètre pour rendre le registre GitLab compatible avec les versions de Docker antérieures à 1.10. Pour l'activer, installez
registry['compatibility_schema1_enabled'] = true в gitlab.rb. - Le registre GitLab exporte désormais les métriques Prometheus et est automatiquement surveillé par les flux entrants. .
- Ajout de la prise en charge de Google Cloud Memorystore, qui nécessite .
opensslmis à jour vers la version 1.0.2r,nginx- jusqu'à la version 1.14.2,python- jusqu'à la version 3.4.9,jemalloc- jusqu'à la version 5.1.0,docutils- jusqu'à la version 0.13.1,gitlab-monitor- jusqu'à la version 3.2.0.
Fonctionnalités obsolètes
GitLab Geo apportera le stockage haché à GitLab 12.0
GitLab Geo est requis pour atténuer la concurrence (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 migrés. Cm. . Si vous utilisez Geo, veuillez exécuter cette vérification et migrer dès que possible.
Dans GitLab avertissement définitivement désactivé sera affiché sur la page Zone d'administration › Géo › Nœudssi les vérifications ci-dessus ne sont pas autorisées.
Dans GitLab Geo utilisera les exigences de stockage hachées. Cm. .
Date de suppression : 22 Juin 2019 ville
Intégration Hipchat
Hipchat . De plus, dans la version 11.9 .
Date de suppression : 22 2019 Mars, l'
Prise en charge de CentOS 6 pour GitLab Runner à l'aide de l'exécuteur Docker
GitLab Runner ne prend pas en charge CentOS 6 lors de l'utilisation de Docker sur GitLab 11.9. Ceci est le résultat d'une mise à jour de la bibliothèque principale Docker, qui ne prend plus en charge CentOS 6. Pour plus de détails, consultez .
Date de suppression : 22 2019 Mars, l'
Chemins de code hérités de GitLab Runner
Depuis Gitlab 11.9, GitLab Runner utilise clonage/appel du 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 vue de configuration du serveur de métriques pour GitLab Runner. metrics_server sera supprimé au profit de listen_address dans GitLab 12.0. Voir plus dans . Et plus de détails dans .
Dans la version 11.3, GitLab Runner a commencé à prendre en charge , ce qui a conduit à de nouveaux paramètres pour . la il y a un tableau des changements et des instructions pour migrer vers la nouvelle configuration. Voir plus dans .
Ces chemins ne sont plus disponibles dans GitLab 12.0. En tant qu'utilisateur, vous n'avez rien d'autre à modifier que de vous assurer que votre instance GitLab exécute la version 11.9+ lors de la mise à niveau vers GitLab Runner 12.0.
Date de suppression : 22 Juin 2019 ville
Option obsolète pour la fonctionnalité de point d'entrée pour GitLab Runner
Paramètre de fonctionnalité introduit dans 11.4 GitLab Runner pour régler des problèmes comme и .
Dans GitLab 12.0, nous passerons au comportement correct comme si le paramètre de fonctionnalité était désactivé. Voir plus dans .
Date de suppression : 22 Juin 2019 ville
Prise en charge obsolète d'une distribution Linux qui a atteint la fin de vie de GitLab Runner
Certaines distributions Linux sur lesquelles vous pouvez installer GitLab Runner ont atteint leur objectif.
Dans GitLab 12.0, GitLab Runner ne distribuera plus de packages à ces distributions Linux. Une liste complète des distributions qui ne sont plus prises en charge peut être trouvée dans notre . Merci à Javier Ardo () pour lui !
Date de suppression : 22 Juin 2019 ville
Suppression des anciennes commandes GitLab Runner Helper
Dans le cadre de nos efforts pour soutenir dû abandonner certaines des anciennes commandes utilisées pour .
Dans GitLab 12.0, GitLab Runner est lancé à l'aide de nouvelles commandes. Cela n'affecte que les utilisateurs qui remplacent . Voir plus dans .
Date de suppression : 22 Juin 2019 ville
Les développeurs peuvent supprimer les balises Git dans GitLab 11.10
La suppression ou la modification des notes de version pour les balises Git dans les branches non cochées a toujours été limitée à : .
Étant donné que les développeurs peuvent ajouter des balises et modifier et supprimer des branches non protégées, les développeurs devraient pouvoir supprimer les balises Git. Dans GitLab 11.10 dans notre modèle d'autorisations pour améliorer le flux de travail et aider les développeurs à utiliser les balises mieux et plus efficacement.
Si vous souhaitez conserver cette restriction pour les responsables et les propriétaires, utilisez .
Date de suppression : 22 Avril 2019 ville
Prise en charge de Prometheus 1.x dans Omnibus GitLab
Commencer avec GitLab , la version intégrée de Prometheus 1.0 a été supprimée d'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 la version 2.0 et, si nécessaire, les données transférées .
En version GitLab Prometheus 2.0 sera automatiquement installé si la mise à jour n'a pas déjà été installée. Les données de Prometheus 1.0 seront perdues car... ne sont pas tolérés.
Date de suppression : 22 Juin 2019 ville
TLS v1.1
Commencer avec GitLab pour améliorer la sécurité. Cela résout de nombreux problèmes, notamment Heartbleed, et rend GitLab conforme à la norme PCI DSS 3.1 dès le départ.
Pour désactiver immédiatement TLS v1.1, définissez nginx['ssl_protocols'] = "TLSv1.2" в gitlab.rband et courir gitlab-ctl reconfigure.
Date de suppression : 22 Juin 2019 ville
Modèle OpenShift pour l'installation de GitLab
Officiel — la méthode recommandée pour exécuter GitLab sur Kubernetes, y compris .
pour installer GitLab est obsolète et ne sera plus pris en charge dans .
Date de suppression : 22 Juin 2019 ville
Définitions précédentes des emplois de sécurité
Avec une introduction toutes les définitions de tâches précédentes seront obsolètes et seront supprimées dans GitLab 12.0 ou version ultérieure.
Mettez à jour vos définitions de tâches pour utiliser la nouvelle syntaxe et profitez de toutes les nouvelles fonctionnalités de sécurité fournies par GitLab.
Date de suppression : 22 juin 2019
Section Informations système dans le panneau d'administration
GitLab présente des informations sur votre instance GitLab dans admin/system_info, mais ces informations peuvent ne pas être exactes.
Nous panneau d'administration dans GitLab 12.0 et nous vous recommandons d'utiliser .
Date de suppression : 22 Juin 2019 ville
Source: habr.com