GitLab 12.6 publié avec les cotes de sécurité du projet et les documents de sortie

Les responsables du développement ont besoin d'une vue d'ensemble claire et compréhensible de l'état de sécurité de l' application et de la conformité aux exigences de leur projet. La version de décembre de GitLab vous aidera à suivre ces paramètres importants plus efficacement.

Statut de sécurité du projet

Dans la version 12.6, nous avons ajouté une nouvelle fonctionnalité au panneau de sécurité du projet , qui affiche une évaluation de l'état de sécurité de vos projets. Ainsi, les responsables du développement seront en mesure de comprendre rapidement quels projets peuvent être à risque et d'apporter l'attention nécessaire à des problèmes spécifiques.

Audit amélioré avec les documents de sortie

Presque chaque équipe d'entreprise doit documenter son travail et fournir la preuve que chaque version répond à toutes les exigences et procédures de l'organisation. Cela signifie souvent que l'entreprise dispose de processus manuels pour maintenir la documentation actuelle afin qu'elle soit disponible pour les futurs contrôles de conformité. GitLab 12.6 simplifie le processus d'audit grâce au fichier contenant les matériaux de la version - un objet JSON qui contient des liens vers des mailstones et des tickets liés à la version, ce qui aidera dans les futurs audits.

Gérez et distribuez efficacement les ressources C / C ++

De nombreuses équipes développent activement des applications C et C ++ hautes performances et ont besoin d'un outil pour gérer et distribuer facilement les fichiers compilés et les fichiers binaires du projet. Avec la version 12.6, il est devenu plus facile de travailler avec ces fichiers à la fois en public et en privé, grâce à l'intégration avec le populaire référentiel Conan . Désormais, les développeurs pourront utiliser tous les avantages du placement de code, des pipelines automatisés (dans la localisation russe des «lignes d'assemblage» GitLab) et des packages résultants dans une seule application, ce qui améliorera l'efficacité et la vitesse globales du développement.

Et encore plus!

Ce ne sont là que quelques-unes des nouvelles fonctionnalités de la version 12.6. Faites également attention à l' analyse des dépendances des projets Gradle en Java et à la prise en charge de la compression et de la fusion dans les chaînes de demandes de fusion (dans la localisation russe des «demandes de fusion» de GitLab).

L'inscription est ouverte pour la prochaine conférence des utilisateurs de GitLab Commit , qui aura lieu le 14 janvier à San Francisco.

Nous vous invitons à nos réunions , à GitLab Commit et vous demandons de remplir un sondage sur la sortie (en anglais).

MVP du mois - Fabio Huser

Fabio a introduit plusieurs demandes de fusion importantes dans 12.6: la possibilité de désactiver la notification de groupe , d' afficher la différence de couverture de test sur la page de demande de fusion , d' ajouter des sauts de page dans les versions et de prendre en charge Unify Circuit .

Merci Fabio et toute l'équipe Siemens!

Principales caractéristiques de la sortie de GitLab 12.6

Évaluation rapide des risques du projet avec évaluations de sécurité

(ULTIMATE, GOLD) Étape du cycle DevOps: "Secure"

Nous sommes heureux de présenter une nouvelle fonctionnalité sur le panneau de sécurité du groupe - l'évaluation de la sécurité. En plus de la liste existante des vulnérabilités et de l'historique, cette nouvelle partie du panneau de sécurité montre quels projets sont actuellement à risque, de sorte que vous pouvez immédiatement passer aux projets qui nécessitent une attention immédiate.

La vulnérabilité des vulnérabilités détectées affectera l'évaluation résultante - de A à F.Les projets seront regroupés en fonction de ces évaluations, ce qui permet de voir facilement la distribution des projets sans problèmes de sécurité actuels (grade A) à ceux avec au moins 1 vulnérabilité critique (grade F).

Documentation du panneau de sécurité du groupe et ticket d'origine .

Gestion des packages C / C ++ via Conan à l'aide du registre de packages GitLab

(PREMIUM, ULTIMATE, SILVER, GOLD) Étape du cycle DevOps: "Package"

Pour les éditeurs de logiciels, il est important d'avoir un moyen simple et sécurisé de gérer les dépendances. Les outils de gestion de packages, tels que Conan pour les développeurs C / C ++, fournissent un moyen standardisé de distribuer les bibliothèques et de gérer leurs versions entre les projets. Dans la version 12.6, nous sommes heureux de fournir un support de référentiel Conan intégré directement dans GitLab. Fournissez simplement l'adresse du serveur Conan distant au registre des packages GitLab - et vous pouvez immédiatement télécharger, installer et supprimer des packages, ainsi que publier vos bibliothèques.

Documentation sur l'utilisation de Conan et le ticket d'origine .

Filtrage des tickets et fusion des demandes de publication

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Étape du cycle DevOps: "Release"

Planifier et gérer les versions n'est pas une tâche facile. C'est pourquoi la possibilité de trouver rapidement des tickets et de fusionner les demandes liées à la sortie est si importante. Dans 12.6, nous avons ajouté le filtrage des tickets et des demandes de fusion par nom de version, ce qui vous aidera à trouver rapidement les tickets et les demandes de fusion associés.

Rechercher la documentation et le ticket d'origine .

Créez automatiquement des documents de version pour l'audit

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Étape du cycle DevOps: "Release"

Dans de nombreuses entreprises, lorsque de nouvelles modifications sont publiées, il est nécessaire de documenter la conformité avec tous les processus et ajustements nécessaires dans le cycle de vie du développement logiciel. Ce processus est souvent inefficace - et prend du temps. À partir de la version 12.6, la collection Evidence est apparue dans les versions de GitLab, où vous trouverez un instantané de toutes les métadonnées de version au format JSON. Cet instantané peut être utilisé pour les processus d'examen et la confirmation de la conformité, par exemple, pour l'audit.

Documentation des documents de sortie et du ticket d'origine .

Historique des validations combinées de squash et de fusion dans la chaîne de demande de fusion

(PREMIUM, ULTIMATE, SILVER, GOLD) Étape du cycle DevOps: "Release"

Squash-and-Merge vous permet de rassembler toutes les validations de votre demande de fusion en une seule afin d'avoir un historique soigné dans la branche par défaut, et de le faire sans perdre l'historique complet des validations. Dans cette version, nous avons ajouté la prise en charge de squash à la chaîne de demandes de fusion qui exécutent la génération en fonction du résultat de la demande de fusion avant son exécution, en veillant à ce que la branche principale reste verte. La combinaison de ces deux fonctionnalités fournira une branche principale en état de marche et un historique unifié des validations.

Documentation sur les convoyeurs basée sur la demande de fusion et le ticket d'origine .

Afficher les paramètres de sécurité et de conformité en un seul endroit

(ULTIMATE, GOLD) Étape du cycle DevOps: "Secure"

Nous sommes heureux de vous présenter une nouvelle façon d'afficher les analyses de sécurité à partir de la barre de navigation de gauche. Dans la section , l'option est apparue, où vous verrez toutes les analyses de sécurité disponibles, quelles analyses ont été configurées et des liens vers la documentation appropriée.

Veuillez noter que ce n'est que la première itération (MVC) de cette fonctionnalité, donc un paramètre plus complexe n'est pas encore disponible, par exemple, vous ne pouvez pas activer ou désactiver les analyses à partir de cet écran.

Documentation de vérification de la sécurité de l'application et ticket d'origine .

Travaillez plus efficacement avec Circuit

(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR) "Activation"

Unify Circuit est un système de communication et de collaboration utilisé par de nombreuses organisations. Comme avec les autres intégrations d'alerte GitLab, vous pouvez désormais configurer des hooks Web pour envoyer des alertes spécifiques à une conversation Circuit. Les liens dans les alertes mèneront à votre projet dans GitLab, éliminant ainsi la nécessité de passer à votre client de messagerie pour des mises à jour sur l'activité dans GitLab.

Merci à Fabio Huser pour cette contribution .

Documentation du circuit et ticket original

Autres améliorations dans GitLab 12.6

Conditions requises pour les nouveaux mots de passe utilisateur

(CORE, STARTER, PREMIUM, ULTIMATE) Étape du cycle DevOps: "Gérer"

Les organisations ont besoin d'un moyen de sécuriser leurs instances GitLab conformément aux procédures et réglementations internes. Une partie de ce travail est la sécurité des mots de passe. GitLab a récemment mis à jour ses guides de mots de passe basés sur le NIST SP 800-63B . Dans cette publication, le NIST recommande de définir des exigences de longueur et de complexité de mot de passe, mais ne recommande pas la rotation de mot de passe ou des exigences de complexité spécifiques (par exemple, un certain nombre de caractères spéciaux).

Sur cette base, GitLab présente un nouveau paramètre dans le panneau d'administration - la longueur minimale du mot de passe , qui sera appliquée aux nouveaux mots de passe, c'est-à-dire qu'il agira sur les nouveaux comptes ou lors du changement de mot de passe. Grâce à cela, GitLab deviendra plus sûr et les organisations pourront gérer la politique de mot de passe dans leurs instances, garantissant la conformité avec les exigences internes.

Documentation sur la limitation de la longueur des mots de passe et du ticket d'origine .

Exigence de mise à jour du jeton personnel

(ULTIMATE) Étape du cycle DevOps: "Gérer"

Les organisations axées sur la sécurité ont toujours utilisé des modifications d'informations d'identification régulières pour limiter le temps d'accès au système en cas de compromission des données. Bien que les directives d'organisations comme le NIST ne recommandent plus les changements périodiques, nous ajoutons toujours la possibilité de personnaliser l'exigence de mises à jour régulières des jetons personnels . Cela peut être nécessaire en raison de l'absence initiale de protection à deux facteurs, des exigences des utilisateurs ou de l'importance de changer pour certains cadres qui garantissent la conformité aux normes, telles que PCI .

Grâce à cette fonctionnalité, l'administrateur d'instance peut configurer la durée de vie des jetons d'accès personnels générés. L'application de la limite expirera automatiquement tous les jetons actuels, ils devront être régénérés et la durée de vie spécifiée sera appliquée aux nouveaux jetons. À son expiration, le jeton devra être généré à nouveau.

Documentation pour limiter la durée de vie des jetons et du ticket d'origine .

Protection des données du projet avec suppression réversible

(PREMIUM, ULTIMATE, SILVER, GOLD) Étape du cycle DevOps: "Gérer"

Jusqu'à ce moment, la suppression d'un projet via une interface utilisateur ou une API était immédiate et irréversible, sans possibilité de récupérer des données. Cela pourrait entraîner une perte de données par inadvertance, ce qui serait un pire scénario pour les développeurs.

Pour atténuer les risques avec la version 12.6, nous introduisons une suppression de projet réversible. Au lieu de supprimer immédiatement un projet ou un groupe, ils seront marqués pour suppression et supprimés après le nombre de jours de suppression réversible configuré. Par défaut, cela se produit après 7 jours. Si vous souhaitez laisser la suppression immédiate, remplacez la valeur de ce paramètre par 0.

Documentation sur la période de suppression réversible et le ticket d'origine .

Aperçu des spécifications OpenAPI

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Étape du cycle DevOps: "Créer"

La spécification OpenAPI (anciennement Swagger) est une norme populaire pour la création d'interfaces RESTful. Cependant, la lecture du code source YAML n'est pas si facile. Dans la version de GitLab 12.6, lors de l'affichage du fichier openapi.yml ou d'un autre fichier pris en charge, l'aperçu des spécifications sera dessiné sous la même forme que dans Swagger.

Merci à Roger Meier et Siemens pour cette contribution !

Aperçu de la documentation pour les spécifications OpenAPI et le ticket d'origine .

Navigation simplifiée entre les onglets dans les demandes de fusion

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Étape du cycle DevOps: "Créer"

L'interface de demande de fusion est l'endroit où le code est examiné, testé et discuté, mais cette interface peut facilement être surchargée. Les descriptions des demandes de fusion, les pipelines, les résultats des analyses de sécurité peuvent pousser les onglets loin en bas de la page, ce qui les rend difficiles à atteindre.

Dans la nouvelle version de GitLab, la navigation des demandes de fusion est désormais au-dessus de la description, et vous pouvez facilement accéder directement aux modifications. Nous avons également regroupé la description et les widgets dans l'onglet Présentation , ce qui facilitera la navigation dans la demande de fusion. Veuillez envoyer vos commentaires sur cette mise à jour ici .

Fusionnez la documentation de la demande et un ticket original .

Suppression des branches tout en limitant la visibilité du projet

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Étape du cycle DevOps: "Créer"

Les succursales simplifient le travail sur n'importe quel projet. Vous effectuez une copie du projet principal sur lequel vous pouvez travailler, puis créez une demande de fusion pour apporter vos modifications au projet.

Auparavant, lorsque la visibilité du projet racine dans le réseau de succursales était devenue limitée, la visibilité de toutes les succursales était également devenue limitée. Cela pourrait conduire au fait que toutes les fourches d'un projet public se sont soudainement fermées si vous avez limité la visibilité du projet racine.

Dans GitLab 12.6, au lieu de modifier la visibilité de tous les projets, le projet racine est simplement supprimé du réseau de succursales, laissant tous les autres projets inchangés, ce qui équivaut à supprimer le projet racine.

Documentation sur la restriction de visibilité et le ticket d'origine .

Configuration de CI en dehors du référentiel

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Étape du cycle DevOps: "Vérifier"

Nous avons ajouté la possibilité de définir le chemin d'accès à .gitlab-ci.yml tant .gitlab-ci.yml arbitraire, ce qui vous permet de stocker les paramètres CI en dehors du référentiel que vous construisez actuellement. Maintenant, pour configurer plusieurs référentiels de la même manière, vous pouvez simplement fournir un lien vers le même .gitlab-ci.yml externe .gitlab-ci.yml . L'efficacité est augmentée du fait qu'au lieu de prendre en charge de nombreux paramètres distincts, il suffit de mettre à jour un seul fichier de configuration. Les utilisateurs qui utilisent des services qui génèrent dynamiquement un fichier de configuration bénéficieront également de cette fonctionnalité.

Il vous permet également de protéger les paramètres des modifications non autorisées, car le fichier de configuration peut être stocké dans le projet avec une restriction d'accès plus restrictive. Nous avons mis à jour notre documentation en ajoutant des informations sur la façon de procéder.

Documentation sur la définition du chemin d'accès au fichier de paramètres CI et au ticket d'origine .

Le registre NPM prend désormais en charge l'installation des dépendances

(PREMIUM, ULTIMATE, SILVER, GOLD) Étape du cycle DevOps: "Package"

Nous sommes heureux de vous informer qu'à partir de GitLab 12.6, le registre NPM prend en charge l'installation des dépendances de package. Auparavant, la commande npm install ne fonctionnait pas si la version du package n'était pas incluse dans la commande. De plus, cette commande ne prend pas en charge l'installation des dépendances de package car nous ne prenons pas en charge les métadonnées NPM requises, telles que les dépendances et les balises.

Avec cette version, l' npm install GitLab npm install fonctionnera comme prévu. Ensuite, nous prévoyons de travailler sur l' ajout de dépendances et de balises à l'interface utilisateur du registre de packages .

Documentation des métadonnées du registre NPM et ticket d'origine .

Le conteneur officiel GitLab avec AWS préinstallé

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Étape du cycle DevOps: "Release"

L'interaction avec l'un des plus grands fournisseurs de services cloud, tels qu'AWS, Azure ou GCP, est un composant clé de nombreux pipelines. Cependant, avant de pouvoir automatiser les opérations cloud, vous devez configurer votre environnement avec tous les outils dont vous avez besoin. Vous deviez le faire vous-même auparavant, mais à partir de la version 12.6, GitLab fournira une image AWS Docker officielle qui vous permettra d'exécuter des commandes aws à partir de vos pipelines CI / CD. Vous pouvez accéder à de nombreux services AWS à l'aide de l'image Docker, qui est maintenue et mise à jour par l'équipe GitLab.

Une image officielle est également la première étape de la prise en charge des déploiements AWS dans EC2 . L'un de nos plans mondiaux consiste à ajouter une prise en charge native des déploiements cloud de différents fournisseurs . Nous espérons voir la communauté contribuer au développement de la prise en charge de fournisseurs de cloud supplémentaires. Pour ce faire, vous pouvez utiliser ce modèle d'images pré-assemblées avec des scripts inclus, qui est stocké dans le registre officiel de GitLab Cloud Deploy .

Documentation de déploiement cloud et ticket d'origine .

Avertissement hors file d'attente

(PREMIUM, ULTIMATE, SILVER, GOLD) Étape du cycle DevOps: "Release"

Lorsque les utilisateurs sélectionnent l'option «Fusionner immédiatement» pour leurs demandes de fusion, toutes les demandes de fusion dans la file d'attente sont retardées. Les utilisateurs peuvent ne pas savoir que cela se produit et ils peuvent interférer par inadvertance les uns avec les autres. Maintenant, bien que nous autorisions toujours les demandes de fusion urgentes à tourner à leur tour, en tant que ligne de défense supplémentaire, nous avons ajouté un avertissement qui explique que cette action affectera d'autres demandes de fusion.

Documentation de la chaîne de fusion et ticket d'origine .

Configurer l'espace de noms Kubernetes pour chaque environnement

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Étape de la boucle DevOps: "Configurer"

Lorsque vous utilisez l'intégration de GitLab avec Kubernetes, vous obtenez un espace de noms généré automatiquement qui sert de cible de déploiement pour GitLab CI / CD. Cela facilite la prise en main de Kubernetes. Cependant, si vous avez déjà un cluster avec un ensemble existant d'espaces de noms, vous souhaiterez probablement spécifier l'un de ces espaces de noms comme cible pour le déploiement de GitLab.

Avec GitLab 12.6, vous pouvez définir un espace de noms personnalisé pour chaque environnement CI dans un .gitlab-ci.yml , qui vous permet de déployer sur des espaces qui existaient avant même que vous ayez connecté votre cluster Kubernetes à GitLab. Par défaut, cette fonctionnalité est disponible uniquement pour les clusters sans autogestion, mais elle prend en charge les environnements dynamiques (par exemple, pour une utilisation dans les applications de révision).

Documentation de configuration du déploiement de Kubernetes et ticket d'origine .

Effacement du cache de cluster pour prendre en charge la synchronisation

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Étape de la boucle DevOps: "Configurer"

Nous devons souvent effectuer des actions sur les clusters Kubernetes directement, par exemple, pour le dépannage ou le réglage fin. La modification des ressources Kubernetes directement dans le cluster peut entraîner la fin de la synchronisation de GitLab avec le cluster, et elle arrêtera de recréer les ressources, car elle supposera qu'elles existent déjà.

À partir de GitLab 12.6, une option pour effacer le cache local de l'espace de noms et des comptes de service apparaîtra dans l'intégration de Kubernetes, ce qui permettra au prochain travail CI de les recréer si nécessaire.

Documentation de nettoyage du cache de cluster et ticket d'origine .

Installer les applications Kubernetes à l'aide du modèle CI

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Étape de la boucle DevOps: "Configurer"

L'installation d'applications Kubernetes à l' aide de GitLab CI fournit un excellent moyen de personnaliser vos graphiques Helm avant l'installation. Pour simplifier le démarrage, nous avons ajouté un modèle CI avec toutes les applications actuellement prises en charge. De plus, nous avons créé un exemple de projet de gestion de cluster qui contient tout ce dont vous avez besoin pour commencer. Il vous suffit d'importer et de copier ce projet pour obtenir toutes les dernières versions des applications prises en charge.

Documentation d'installation via GitLab CI et le ticket d'origine .

Meilleure intégration entre le suivi des bogues et la gestion des tickets

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Étape de boucle DevOps: "Monitor"

Les erreurs de tri peuvent prendre du temps, ce qui implique souvent plusieurs membres de votre équipe. Un participant peut identifier l'erreur comme critique et créer un ticket pour la corriger. À partir de GitLab 12.6 à partir de la page contenant des informations détaillées, vous pouvez par erreur accéder au ticket ouvert pour celui-ci. Ainsi, il sera immédiatement évident si vous devez créer un ticket pour cette erreur.

S'il n'y a pas encore de ticket, vous pouvez le créer rapidement à partir de l'erreur générée depuis la page d'erreur.

Documentation sur la page d'informations sur l'erreur et le ticket d'origine .
Boucle DevOps: "Moniteur"] ( https://about.gitlab.com/stages-devops-lifecycle/monitor/ )

Gérer Sentry via GitLab

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Étape de boucle DevOps: "Monitor"

Si vous utilisez le suivi des bogues GitLab, il est probablement important pour vous d’intégrer Sentry, l’outil de suivi des bogues le plus populaire. À partir de GitLab 12.6, si vous ne pouvez pas utiliser le projet Sentry sur Sentry.io, vous pouvez déployer Sentry directement dans le cluster Kubernetes attaché à votre projet ou groupe. Cela simplifie considérablement le démarrage du suivi des erreurs dans GitLab.

Documentation pour l'installation de Sentry via GitLab CI et le ticket d'origine .

Accès aux journaux de foyer sur l'onglet opérations

(ULTIMATE, GOLD) Étape du cycle DevOps: "Monitor"

Auparavant, il n'y avait pas de moyen facile d'accéder directement aux journaux de vos foyers. Pour ce faire, vous deviez aller dans l'onglet Environnements de l'élément Opérations , sélectionner l'environnement souhaité et cliquer sur celui sous. Maintenant, dans GitLab 12.6, parcourir les journaux de foyer est maintenant plus facile que jamais. Cliquez sur l'onglet Pod Pods sous Operations .

Documentation du journal du foyer Kubernetes , ticket original et épopée originale .

Amélioration de l'analyse des dépendances pour les projets Python

(ULTIMATE, GOLD) Étape du cycle DevOps: "Secure"

Si vos dépendances Python ne sont pas stockées dans requirements.txt , mais dans un autre fichier, à partir de GitLab 12.6, vous pouvez définir le fichier de dépendance via la variable PIP_REQUIREMENTS_FILE .

Documentation des variables disponibles et du ticket d'origine .

Prise en charge SAST du framework React (JavaScript)

(ULTIMATE, GOLD) Étape du cycle DevOps: "Secure"

Si vous avez des projets écrits à l'aide du framework JavaScript React, vous pouvez maintenant utiliser nos analyses SAST pour rechercher des problèmes de sécurité.

Documentation des langages et frameworks pris en charge et du ticket d'origine .

Analyse des dépendances pour les projets Scala à l'aide du gestionnaire de packages sbt

(ULTIMATE, GOLD) Étape du cycle DevOps: "Secure"

Dans GitLab 12.6, nous avons ajouté la prise en charge de Scala avec le gestionnaire de packages sbt dans l'analyse des dépendances. Vous pouvez maintenant analyser des projets sur Scala pour rechercher des vulnérabilités potentielles.

Documentation des langues prises en charge et des gestionnaires de packages et du ticket d'origine .

Possibilité de modifier les hooks Web de groupe

(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR) "Activation"

Les hooks Web de groupe peuvent maintenant être modifiés. Auparavant, vous ne pouviez que les créer et les supprimer. Pour les modifier, vous deviez donc supprimer un hook Web existant et en créer un nouveau. Dans cette version, nous avons ajouté la possibilité de modifier les crochets Web via l'interface utilisateur, ce qui vous fera gagner du temps et des efforts lorsque vous les utiliserez.

Documentation sur les paramètres de groupe avancés , le ticket d'origine et la demande de fusion .

Commentaires désactivés dans les billets Jira

(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR) "Activation"

Lorsqu'un utilisateur a l' intégration de GitLab avec Jira activée , les commentaires sont publiés sur Jira lorsqu'une activité se produit dans GitLab. Cette mise à jour permettra aux utilisateurs de désactiver ces commentaires pour une intégration spécifique sur la page des paramètres.

Cela sera pratique pour les utilisateurs qui ne veulent pas voir de commentaires, mais qui souhaitent ajouter automatiquement des tickets Jira aux projets GitLab. De plus, il peut y avoir des scénarios d'utilisation dans lesquels certains utilisateurs de Jira ne devraient pas avoir accès à l'activité dans le référentiel en raison de leur confidentialité. Dans les deux cas, vous devrez affiner le contenu de ces messages.

Documentation pour désactiver les commentaires sur les tickets Jira , le ticket d'origine et la demande de fusion .

Trier les membres du groupe par utilisateurs ajoutés directement

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Étape du cycle DevOps: "Gérer"

Il existe deux façons d'accéder à un projet ou un groupe privé:
a) vous pouvez être ajouté directement à un projet ou à un groupe spécifique
b) vous pouvez hériter de l'accès d'un groupe supérieur .

GitLab 12.6 a permis de comprendre plus facilement comment un utilisateur avait accès à un projet ou à un groupe, grâce à un filtre pour trier le tableau des participants par utilisateurs ajoutés directement ou par utilisateurs avec des droits hérités.

Ceci est particulièrement utile pour les groupes avec des utilisateurs externes ou des instances qui utilisent des groupes pour notifier les équipes .

Documentation sur les utilisateurs ayant des droits d'accès hérités et le ticket d'origine .

SSH

(ULTIMATE) DevOps: "Manage"

GitLab . , , . , , .

, MVC PAT SSH. , , . , , .

.

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) DevOps: "Plan"

. , , -.

@fh1ch Siemens!

, - .

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) DevOps: "Create"

: , - . . , .

GitLab 12.1 , , . GitLab 12.6 ( ) objects/info/alternates , .

Brian Kabiro !

.

-

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) DevOps: "Create"

, «Merge» , , ( ). . GitLab 12.6 - , .

- .

(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD) DevOps: "Verify"

GitLab 12.0 , - .

GitLab 12.6 , .

.

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) DevOps: "Verify"

, . ( ) , , .

.

API

(PREMIUM, ULTIMATE, SILVER, GOLD) DevOps: "Package"

GitLab API , , . API , , .

GitLab 12.6 API, .

API .

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) DevOps: "Release"

GitLab 12.6 API GitLab. .

.

(PREMIUM, ULTIMATE, SILVER, GOLD) DevOps: "Release"

userID . staging ( ), , , .

.

Kubernetes

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) DevOps: "Configure"

, , , ( , , . .) . , .

GitLab , .

.

Auto DevOps

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) DevOps: "Configure"

Auto DevOps Helm chart. .gitlab/auto-deploy-values.yaml , Auto DevOps . HELM_UPGRADE_EXTRA_ARGS .

Auto DevOps .

Cloud Run Anthos Kubernetes GKE

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) DevOps: "Configure"

Kubernetes GitLab GKE «Cloud Run on Anthos» . GKE Knative, Istio HTTP, Cloud Run . - , GitLab Serverless Knative .

. Cloud Run Anthos GitLab 12.4, - . , .

.

Knative 0.9

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) DevOps: "Configure"

GitLab 12.6 Knative GitLab ​​ 0.9. Knative. Knative Serving API v1 , beta alpha - . API, .

.

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) DevOps: "Monitor"

. , , . GitLab 12.6 .

.

/

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) DevOps: "Monitor"

, — , . GitLab 12.6, Sentry GitLab, , .

.

​​ PHP

(ULTIMATE, GOLD) DevOps: "Secure"

PHP , (License Compliance). , . PHP, composer ( composer.lock ).

.

Gradle- Java

(ULTIMATE, GOLD) DevOps: "Secure"

Gradle Java .

.

SAST Kubernetes

(ULTIMATE, GOLD) DevOps: "Secure"

Kubernetes , , kubesec .

SAST .

SAST

(ULTIMATE, GOLD) DevOps: "Secure"

, , SAST, .

SAST .

- CI

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) "Enablement"

CI, . Jenkins, Packagist, Team City, DroneCI, Buildkite Bamboo. , .

, , , , . , ( !).

CI , - .

GitLab Puma ( )

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) "Enablement"

GitLab , Unicorn Puma . Puma , GitLab 30%.

Puma , , Puma 13.0. .

Puma .

release notes / : GitLab 12.6 released with Security Scorecard and Release Evidence .

cattidourden , maryartkey , ainoneko rishavant .