Tableau de bord de sécurité de groupe
Les développeurs utilisent depuis longtemps GitLab comme un outil pour assurer la sécurité de leur code. GitLab offre désormais aux professionnels de la sécurité plus de puissance et d'opportunités, afin qu'ils puissent l'utiliser pour améliorer la sécurité et la compatibilité des applications. Avec la sortie de la version 11.5, le nouveau panneau de sécurité du groupe rassemble toutes les informations dont les professionnels de la sécurité peuvent avoir besoin d'une manière pratique conçue spécialement pour eux. Ce panneau contient de nouvelles options d'affichage: un aperçu général des informations de sécurité pour différents projets, ainsi que des informations détaillées sur chacun d'entre eux. Dans la version 11.5, nous commençons avec les rapports SAST, dans les versions futures, nous ajouterons de nouveaux rapports à ce panneau. Notre objectif est de créer un outil pratique, un panneau de sécurité unique que les spécialistes de la sécurité peuvent utiliser au lieu de basculer entre de nombreux outils.
Nouveau panneau de contrôle pour les opérateurs
Tout comme le panneau de sécurité du groupe offre aux professionnels de la sécurité un large éventail d'options, le panneau de commande de l' opérateur offre des opportunités similaires aux spécialistes DevOps. Ce panneau recueille en un seul endroit des informations sur toutes les opérations sur les projets de votre instance, y compris l'état du pipeline et des alertes.
Gérer l'accès aux pages GitLab
GitLab Pages est un moyen pratique de créer du contenu statique sur le Web, par exemple, de la documentation pour votre projet. Mais qu'en est-il des projets privés, où la documentation et d'autres fichiers ne devraient être disponibles que pour les participants au projet? Auparavant, pour utiliser cette fonctionnalité, il était nécessaire d'ouvrir l'accès public à tous les fichiers supplémentaires, ou de ne pas l'utiliser du tout.
Depuis la sortie de GitLab 11.5, vous pouvez appliquer les mêmes restrictions d'accès aux pages GitLab que vous le feriez pour les tâches et le code. Les utilisateurs non autorisés recevront une page avec un code d'erreur 404 lorsqu'ils tenteront d'ouvrir un tel lien. Le contrôle d'accès pour les pages GitLab fonctionne actuellement sur des copies serveur de GitLab, et une prise en charge est également prévue pour GitLab.com.
Nous sommes très fiers de cette fonctionnalité, telle qu'elle a été introduite par notre communauté. Le contrôle d'accès aux pages a été demandé particulièrement souvent et, par conséquent, cette fonctionnalité a été ajoutée par les membres de la communauté eux-mêmes .
Knative pour Kubernetes
L'architecture d'application sans serveur est maintenant largement discutée, mais souvent mal comprise. Certaines personnes pensent que l'informatique sans serveur implique une «fonction en tant que service» (FaaS), mais ce n'est pas tout à fait vrai . En bref, l'architecture sans serveur vous permet de vous concentrer sur l'écriture de la logique métier sans avoir besoin de comprendre l'infrastructure sous-jacente sur laquelle votre logiciel s'exécutera. Ainsi, les applications et les fonctions peuvent être sans serveur.
Knative est une plate- forme Kubernetes conçue pour créer, déployer et gérer des projets modernes sans serveur, et dans GitLab 11.5, nous avons ajouté la possibilité de déployer et d'intégrer facilement Knative avec GitLab . Vous pouvez installer Knative sur un cluster Kubernetes connecté en une seule fois . Dans GitLab 11.5, vous pouvez utiliser Knative pour vos applications sans serveur, la prise en charge des fonctions sans serveur sera ajoutée dans 11.6.
Knative est toujours dans la version alpha en ce moment, mais il existe de nombreuses bonnes raisons de déployer des applications avec, car il est livré avec des fonctionnalités puissantes dès la sortie de la boîte. Par exemple, Knative surveille le chargement des foyers et peut automatiquement augmenter ou diminuer leur nombre sans configuration supplémentaire. Knative dispose également d'un traitement des événements, ce qui facilite le déploiement des communications entre les processus des services Producteur et Consommateur lors du déploiement des microservices.
Et encore plus!
Il y a tellement d'innovations intéressantes dans cette version que nous ne pourrions pas toutes les intégrer dans l'introduction. Ensuite, vous trouverez des fonctionnalités telles que parallel pour le pipeline , la refonte des cartes sur le tableau des tâches et l' intégration initiale avec Jaeger . Dans cette version, nous avons apporté des améliorations significatives au processus de révision du code, le rendant plus facile et plus pratique: par exemple, nous avons ajouté la possibilité de commenter les lignes de code inchangées dans la demande de fusion , de prévisualiser la révision de la demande de fusion avant de l'envoyer , d' affecter automatiquement les propriétaires de code pour confirmer la demande de fusion, et des liens directs pour consulter les applications . Lisez la suite et vous découvrirez toutes les nouvelles fonctionnalités incluses dans cette version.
Nous vous invitons à nos réunions .
Tuomo a fait un excellent travail en mettant en œuvre le contrôle d'accès aux pages GitLab , une fonctionnalité populaire que beaucoup ont demandé à ajouter. Les projets privés peuvent désormais restreindre l'accès à leur contenu, ce qui vous permettra de créer et de stocker des pages internes avec des informations privées.
Merci Tuomo Cette contribution a nécessité un travail considérable sur les gitlab-ce , gitlab-pages et omnibus-gitlab .
Principales caractéristiques de la sortie de GitLab 11.5
Tableau de bord de sécurité de groupe
(ULTIME, OR)
Les professionnels de la sécurité doivent obtenir facilement des informations sur l'état de sécurité actuel de tous leurs projets afin de savoir quelle tâche sera désormais la plus importante. Ceci est encore plus important pour les directeurs de la sécurité qui ont besoin d'une vue d'ensemble des vulnérabilités critiques potentielles qui affectent l'ensemble du développement.
Dans GitLab 11.5, nous présentons la première version du nouveau tableau de bord de sécurité, disponible au niveau du groupe. Il recueille en un seul endroit les vulnérabilités identifiées par SAST pour tous les projets de ce groupe et une liste des actions disponibles pour les corriger. Par exemple, vous pouvez créer une tâche avec la solution proposée, ou simplement masquer la notification si vous pensez qu'il s'agit d'un faux positif. Les versions futures ajouteront la prise en charge d'autres tests - Analyse des dépendances, Analyse des conteneurs, DAST.
Notez que le panneau de sécurité de groupe nécessite l'utilisation d'une nouvelle syntaxe pour les rapports de reports et GitLab Runner version 11.5 ou supérieure pour afficher les résultats. La prise en charge d' Auto DevOps sera ajoutée dans une prochaine version.
Documentation sur le nouveau panneau de sécurité et le ticket d'origine .
Panneau de contrôle pour les opérateurs
(ULTIME, OR)
Pour les entreprises et les équipes utilisant DevOps, il est important de pouvoir accéder rapidement aux informations sur l'état des projets.
La version 11.5 introduit un nouveau panneau pour les opérateurs, contenant une vue d'ensemble de toutes les métriques importantes pour les projets auxquels l'utilisateur s'est abonné, par exemple, le temps écoulé depuis le dernier déploiement, la dernière validation et les alertes actives.
Ce panneau peut être configuré comme page d'accueil pour l'utilisateur, ou vous pouvez y accéder en cliquant sur l'icône dans le panneau supérieur.
Documentation sur le nouveau panneau pour les opérateurs et le ticket d'origine .
Gérer l'accès aux pages GitLab
(NOYAU, DEMARREUR, PREMIUM, ULTIME)
Dans la version de GitLab 11.5, nous présentons une fonctionnalité étonnante introduite par la communauté - le contrôle d'accès aux pages GitLab. Auparavant, nous ne prenions en charge que les cas dans lesquels tout le contenu du projet était public, mais maintenant, à l'aide de Pages, vous pouvez créer et publier du contenu protégé, dont l'accès ne sera accessible qu'aux participants au projet. Les documents sur les opérations, les données secrètes, les plans et autres informations peuvent désormais être publiés de manière confidentielle, donnant accès à un cercle restreint de personnes.
Jusqu'à présent, cette fonctionnalité n'est pas connectée sur GitLab.com, plus d'informations dans le ticket 5576 .
Pages de documentation de contrôle d'accès et ticket d'origine .
Déployer et intégrer Knative avec GitLab
(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)
La création d'applications sans serveur permet aux équipes de se concentrer sur la création d'un produit de qualité, éliminant ainsi la nécessité de configurer et d'entretenir les serveurs.
Depuis la sortie de GitLab 11.5, il est devenu possible de déployer Knative sur votre cluster Kubernetes en une seule étape, en utilisant l'intégration de GitLab avec Kubernetes. Knative est une plateforme Kubernetes conçue pour créer, déployer et gérer des projets modernes sans serveur. Les tâches auparavant complexes, telles que l'assemblage d'une source à un conteneur, la gestion du trafic et la mise à l'échelle à 0 (mise à l'échelle à zéro) en l'absence de chargement, fonctionnent désormais immédiatement.
Documentation sur le travail avec une architecture sans serveur dans GitLab et ticket original .
Nomination des propriétaires de code confirmant la demande de fusion
(DEMARREUR, PREMIUM, ULTIME, BRONZE, ARGENT, OR)
Il n'est pas toujours évident de savoir qui doit effectuer un examen de la demande de fusion. Les propriétaires de code, qui sont responsables de fichiers spécifiques, sont désormais automatiquement affectés comme confirmant les demandes de fusion.
Avec le rendez-vous automatique de confirmation des demandes de fusion, les propriétaires de codes recevront des notifications de modifications, afin qu'ils puissent les examiner et approuver ou non les modifications.
La prise en charge des propriétaires de code est apparue dans la version GitLab 11.3 ( article original , traduction ). Dans les versions futures, le degré de participation des propriétaires de code dans les processus de travail des demandes de fusion avec la confirmation requise du propriétaire augmentera.
Documentation confirmant la demande de fusion et le ticket d'origine .
Attribut parallel pour accélérer le pipelining
(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)
La vitesse du pipeline est un facteur important pour toute équipe et l'exécution de tests ou d'autres tâches pouvant être parallélisées prend généralement beaucoup de temps pour tout assemblage. L'ajout d'un nouveau mot-clé - l'attribut parallel - permet aux équipes de paralléliser facilement les tests, accélérant ainsi le processus de livraison de logiciels. Pour utiliser cette fonctionnalité, définissez l'attribut sur le nombre de threads dans lesquels vous souhaitez exécuter cette tâche, et GitLab créera indépendamment le nombre nécessaire de travaux avec votre tâche.
Documentation d'attribut parallèle et ticket d'origine .
Autres améliorations dans GitLab 11.5
Commenter des lignes de code inchangées dans une demande de fusion
(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)
L'une des principales tâches d'une révision du code est d'attirer l'attention sur les aspects des modifications proposées qui n'ont peut-être pas été pris en considération. Ce sont souvent des indications de conséquences imprévues qui peuvent survenir dans un code non modifié.
GitLab prend désormais en charge les commentaires sur les lignes de code modifiées et inchangées dans la demande de fusion, afin que vous puissiez attirer l'attention de l'auteur sur les modifications qui doivent encore être apportées. Pour afficher des lignes de code inchangées lors de la révision des modifications de la demande de fusion, cliquez sur le bouton points de suspension ( ... ).
Dans les versions futures, nous étendrons la prise en charge des commentaires sur les fichiers inchangés .
Documentation sur les discussions dans les demandes de fusion et un ticket original .
Modèles de fichiers de groupe
(PREMIUM, ULTIME, ARGENT, OR)
LICENSE .gitlab-ci.yml .gitignore , .gitignore , Dockerfile et .gitlab-ci.yml facilitent l'ajout de ces fichiers couramment utilisés aux projets. Les modèles de fichiers personnalisés peuvent désormais être partagés entre tous les projets d'un groupe et de sous-groupes si vous configurez le référentiel de modèles de groupe.
Les modèles personnalisés sont utiles dans les cas où les modèles GitLab ne conviennent pas: par exemple, lorsque vous avez besoin de votre propre licence, qui est utilisée dans tous les projets de l'entreprise, ou d'un Dockerfile complexe, qui doit être utilisé dans chaque microservice.
La prise en charge des modèles de fichiers pour les instances utilisateur a été introduite dans la version GitLab 11.3 ( article d'origine , traduction ).
Documentation sur les modèles de fichiers pour le groupe et le ticket d'origine .
Lien direct pour consulter les applications
(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)
Lorsque vous travaillez dans une branche distincte et modifiez seulement quelques fichiers, vous n'avez pas besoin du lien vers les applications de révision pour vous amener à la racine du projet. Pour plus de commodité, nous avons ajouté un menu déroulant au lien vers les demandes de révision, qui vous permet désormais d'accéder directement aux pages de fichiers avec lesquelles vous avez travaillé.
Documentation sur la transition directe des fichiers sources vers leurs pages dans l'environnement et le ticket d'origine .
Analyse des tâches
(PREMIUM, ULTIME, ARGENT, OR)
Dans cette version, nous avons présenté un graphique dynamique indiquant le nombre de tâches créées dans votre groupe par mois ou au cours de la dernière année. Nous avons également ajouté un filtre qui vous permet de restreindre votre recherche à un ensemble spécifique de tâches.
Cette fonctionnalité aidera les équipes à effectuer une analyse plus approfondie des tâches. Par exemple, vous pouvez rapidement voir combien de tâches de bogue ont été créées si vous sélectionnez la marque de «bogue» appropriée.
Ici, vous pouvez voir comment nous prévoyons d'étendre les capacités des diagrammes . Nous vous demandons de participer à la discussion!
Documentation sur l'analyse des tâches et un ticket original .
Aperçu de l'examen de la demande de fusion avant le départ
(PREMIUM, ULTIME, ARGENT, OR)
Une révision de code est une pratique obligatoire dans tout projet réussi, mais il est parfois difficile de fournir une rétroaction compréhensible et exécutable. L'un des problèmes est que les commentaires sur le code deviennent inutiles ou incomplets lorsque le lecteur comprend les modifications apportées en visualisant le diff.
Dans GitLab 11.4, nous avons introduit une fonctionnalité pour l'examen des demandes de fusion, qui vous permet d'écrire et d'envoyer plusieurs points de rétroaction en une seule action. À partir de cette version, vous pouvez consulter les révisions de vos demandes de fusion avant de les soumettre.
Dans les versions futures, nous améliorerons cette fonctionnalité en ajoutant des notifications par e-mail - une pour chaque examen de demande de fusion.
Documentation sur l'aperçu de l'examen des demandes de fusion et du ticket d'origine .
Gardez votre e-mail privé
(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)
Lorsque vous travaillez ensemble sur un projet, il est important de savoir qui apporte exactement les modifications dans le code et de pouvoir afficher le profil de l'auteur via l'interface GitLab lorsque vous l'utilisez localement ou sur un hôte situé à distance, mais cela expose votre courrier électronique au public.
GitLab fournit maintenant une adresse non- noreply qui peut être utilisée localement ou pour des noreply Web pour vous permettre de garder plus facilement votre e-mail secret.
Documentation par email privé et ticket original .
Nouvelle syntaxe CI / CD pour les rapports de sécurité, de qualité et de performances
(ULTIME, OR)
Avant GitLab 11.5, les rapports tels que SAST ou DAST reposaient sur une combinaison de noms de tâche et d'artefacts pour permettre au système de reconnaître leur type. En raison des exigences de performances accrues pour accéder aux artefacts, ces fonctionnalités étaient difficiles à mettre à l'échelle et prennent en charge des fonctionnalités plus avancées telles que Group Security Dashboard. Avec la syntaxe précédente, vous deviez toujours donner des noms spécifiques aux travaux (par exemple, sast ), mais maintenant vous pouvez spécifier n'importe quel nom que vous aimez pour chaque travail.
GitLab 11.5 a introduit une nouvelle fonctionnalité pour utiliser la nouvelle syntaxe des rapports pour les rapports. La documentation sur la création de travaux avec la nouvelle syntaxe est disponible aux liens suivants: SAST , DAST , définition des dépendances , analyse d'un conteneur , gestion des licences , évaluation de la qualité du code et test des performances dans un navigateur . L'ancienne syntaxe a disparu en arrière-plan, et dans une future version, nous pourrions nous en débarrasser. Nous serons heureux si vous mettez à jour votre travail pour profiter de la productivité accrue et du tableau de bord de sécurité de groupe, même si l'ancienne syntaxe fonctionne toujours. Pour utiliser la nouvelle syntaxe, GitLab Runner 11.5 ou supérieur est requis.
Rapportez la documentation et le ticket d'origine .
Ouverture d'une demande de fusion avec un correctif par e-mail
(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)
GitLab soutient depuis longtemps l'ouverture des demandes de fusion par e-mail, mais avant l'envoi de l'e-mail, la branche aurait déjà dû être créée sur le serveur. Vous pouvez maintenant ouvrir des demandes de fusion avec un seul e-mail, en joignant un ou plusieurs fichiers de correctifs ( .patch ) au .patch .
Les fichiers de correctifs sont une norme pour le partage et le transfert des modifications entre les systèmes. Dans les futures versions de GitLab, nous créerons des demandes de fusion distribuées basées sur celles-ci, ce qui nous permettra de partager les demandes de fusion entre les instances de GitLab et d'autres outils d'hébergement Git.
Documentation sur l'ouverture des demandes de fusion par e - mail et ticket d'origine .
Page d'accueil vide du wiki
(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)
Nous avons amélioré le processus de création de projets wiki en supprimant la page d'affichage de projet par défaut. Maintenant, la page principale est vide par défaut, ce qui incite les utilisateurs à ajouter leurs propres pages au wiki correspondant et à développer davantage les projets.
Documentation du projet Wiki et ticket original .
Ouverture de Jaeger via GItLab
(ULTIME, OR)
Le traçage fournit une analyse approfondie des performances et de l'intégrité de l'application déployée, car il peut être utilisé pour suivre chaque fonction et microservice qui traite cette demande. Cela rend le processus de traitement de la demande du début à la fin plus clair, que vous utilisiez un système monolithique ou distribué.
Dans GitLab 11.5, nous avons inclus l'intégration initiale avec Jaeger , le projet de traçage CNCF , qui permet aux utilisateurs d'ouvrir facilement l'interface utilisateur Jaeger à partir de GitLab.
Documentation de trace et ticket d'origine .
Noms convenus pour les vérifications de l'état des tâches lors de l'intégration à GitHub
(PREMIUM, ULTIME, ARGENT, OR)
Il est désormais possible de définir des vérifications de l'état des tâches du côté GitHub en cochant simplement la case «requis» - sans avoir à configurer les vérifications pour chaque tâche individuellement en fonction de leur nom. Auparavant, le nom des chèques incluait le nom de la branche, donc le chèque ne pouvait pas être fait simplement. Vous pouvez connecter cette fonctionnalité dans la section des paramètres d'intégration avec GitHub.
Documentation sur les noms des vérifications de statut et le ticket d'origine .
Les applications Omnibus Go utilisent désormais le répertoire des certificats GitLab
(NOYAU, DEMARREUR, PREMIUM, ULTIME)
GitLab comprend un certain nombre d'applications basées sur Go. Avant la version 11.5, ces applications utilisaient le répertoire système standard pour les certificats approuvés au lieu du répertoire Omnibus GitLab.
À partir de cette version, les applications Go utilisent le même répertoire pour les certificats approuvés que le reste de GitLab. La valeur par défaut est /opt/gitlab/embedded/ssl/certs/ . L'utilisation d'un répertoire partagé facilite la gestion des certificats et vous permet de travailler directement avec eux.
Si vous avez des installations GitLab qui ont des dépendances liées aux applications Go utilisant le répertoire système, déplacez ces certificats vers le répertoire Omnibus GitLab standard.
Documentation pour l'installation des certificats et du ticket d'origine .
Notifications de fermeture Ă©piques
(ULTIME, OR)
Récemment, nous avons ajouté la possibilité de fermer des épopées, à savoir, d'établir différents états d'épopées: ouverts et fermés. Dans cette version, nous avons également ajouté des notifications sur la fermeture des épopées ou leur réouverture, afin qu'il soit plus facile pour les utilisateurs de suivre les modifications des projets qui les intéressent.
Documentation des notifications et du ticket d'origine .
Journalisation des événements d'audit JSON
(NOYAU, DEMARREUR, PREMIUM, ULTIME)
Pour simplifier l'analyse des événements d'audit et leur utilisation en dehors de GitLab, nous avons ajouté le fichier audit_json.log pour enregistrer les événements d'audit dans un fichier journal structuré. Grâce à cette innovation, l'envoi et l'analyse des journaux deviendront beaucoup plus faciles, en particulier pour la visualisation et l'analyse lors de l'utilisation d'autres outils.
Documentation sur les événements d'audit et le ticket d'origine .
Fonction de saisie semi-automatique pour les épopées dans la description des tâches et des demandes de fusion
(ULTIME, OR)
Maintenant, il est devenu encore plus facile de rechercher des épopées et de créer des liens vers celles-ci lorsque vous travaillez sur une tâche ou une demande de fusion. Entrez simplement & et quelques chiffres ou caractères dans la description de la tâche ou de la demande de fusion ou dans le commentaire. En utilisant la fonction de saisie semi-automatique de GitLab, les épopées seront recherchées directement dans le groupe parent, ce qui vous permettra de sélectionner l'un d'entre eux sans quitter la page actuelle.
Documentation du lien spécial GitLab et ticket original .
Liste des fichiers pour afficher les modifications dans la demande de fusion
(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)
Lors de l'affichage des modifications dans la demande de fusion, vous devez presque toujours vous déplacer d'avant en arrière entre les fichiers. Maintenant, en plus de l'arborescence de fichiers ajoutée dans GitLab 11.4 ( article d'origine , traduction ), GitLab comprend une liste de fichiers avec des modifications qui peuvent être recherchées, ce qui facilite la visualisation des fichiers qui ont été modifiés et le basculement entre eux via une liste ou une arborescence - de quoi avez-vous besoin? plus comme ça.
Documentation pour naviguer dans les fichiers modifiés et le ticket d'origine .
(NOYAU, DEMARREUR, PREMIUM, ULTIME, GRATUIT, BRONZE, ARGENT, OR)
Actuellement, les informations environnementales sont masquées lors du démarrage d'un nouveau pipeline. Dans cette version, nous ajoutons la sortie d'informations sur les déploiements en cours au widget pour vous informer que la mise à jour est en cours.
L'un des résultats les plus intéressants qui peuvent être obtenus en utilisant cette fonctionnalité est que le lien vers le déploiement actuel restera disponible dans les cas où un nouveau déploiement est déjà en cours d'exécution, ce qui vous permettra de trouver un lien vers la page de l'application pour examen. , , .
- .
Jira Cloud email API
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Jira Cloud . , email- API Jira Cloud.
Jira GitLab .
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
, . GitLab . , , GitLab , .
, - , URL, .
.
.
API
(ULTIMATE, GOLD)
, , : . 11.5 API, , , .
API .
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab , , . , . , , .
-, , .
.
(ULTIMATE, GOLD)
( , -) , , , .
r , , . e , l .
.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab (Issue Boards), . , . , , , , , .
.
'index' , 'README'
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
README.* , «» GitLab . GitLab 11.5 index.* ( README.* ).
, , . , README.md , README.html , index.html « » URL, - http://example.com/page/index.html http://example.com/page/ .
Markdown, GitLab .
README. index. .
RBAC ,
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Kubernetes . RBAC (Role-based access control, ) .
GitLab 11.5, Kubernetes , ( , ) CI GitLab. , cluster-admin GitLab CI Runners .
RBAC .
-
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
, -. - , .
, -. - GitLab. , - , .
​​ .
.
Git API
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Git Git Git. GitLab API. , API .
.
, Git push
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
, Git GitLab, GitLab , LFS (Large File Storage). , .
GitLab , - . .
git push/pull .
, -
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
, - . , .
.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab 11.5 , . , , , . : !
.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
« » ('New group') « » ('New project'), , .
.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
, «». , !
.
Gemnasium
(ULTIMATE, GOLD)
Gemnasium . GitLab , , .
GitLab 11.5 Gemnasium , . . , , , .
.
-
(PREMIUM, ULTIMATE)
, GitLab, 11.5:
- .
GitLab Helm chart
(CORE, STARTER, PREMIUM, ULTIMATE)
Helm chart'
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
, , GitLab. , , .
.
GitLab Runner 11.5
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab Runner 11.5! GitLab Runner — , CI/CD GitLab.
:
CHANGELOG GitLab Runner'.
GitLab Runner .
release notes / : GitLab 11.5 released with Group Security and Operations Dashboards, and Access Control for Pages .
cattidourden , maryartkey , ainoneko rishavant .