GitLab 11.10 avec des pipelines dans le tableau de bord, des pipelines pour résultats combinés et des suggestions pour plusieurs lignes dans les merge requests.
Informations pratiques sur la fonctionnalité des pipelines dans différents projets
GitLab continue d'accroître la transparence du cycle de vie DevOps. Cette version comprend un aperçu du statut des pipelines.
C'est pratique, même si vous examinez le pipeline d'un seul projet, mais cela est particulièrement utile si , ce qui est souvent le cas lorsque vous utilisez des microservices et que vous souhaitez lancer un pipeline pour tester et livrer du code depuis différents dépôts de projets. Vous voyez maintenant instantanément la fonctionnalité , peu importe où ils sont exécutés.
Lancer des pipelines pour des résultats combinés
Avec le temps, les branches source et cible divergent, et il peut se produire une situation où elles fonctionnent bien individuellement mais pas ensemble. Vous pouvez maintenant . Ainsi, vous remarquerez rapidement les erreurs qui ne se seraient manifestées que lors des déplacements fréquents de modifications entre les branches, ce qui vous permettra de corriger plus rapidement les erreurs du pipeline et d'utiliser .
Une optimisation supplémentaire de la collaboration
Dans GitLab 11.10, encore plus de fonctionnalités pour une collaboration aisée et des workflows simplifiés ont été ajoutées. Dans nous avons introduit des suggestions pour les merge requests, permettant à un examinateur de proposer une modification d'une ligne dans un commentaire de merge request, qui peut être immédiatement validée depuis le fil de commentaires. Nos utilisateurs ont apprécié cette fonctionnalité et ont demandé à l'étendre. Vous pouvez maintenant proposer , en spécifiant quelles lignes supprimer et lesquelles ajouter.
Merci pour vos retours et suggestions !
Et ce n'est pas tout…
Cette version regorge de fonctionnalités incroyables, telles que , un nettoyage plus approfondi , et possibilité . Voici les détails de chacune d'elles.
Employé le plus précieux de ce mois-ci () — Takuya Noguchi
Ce mois-ci, l'employé le plus précieux est Takuya Noguchi (). Takuya : corrigeant des bugs, finalisant des améliorations backend et frontend, et améliorant l'interface utilisateur. Merci !
Fonctionnalités principales de GitLab 11.10
Pipelines sur le tableau de bord
PREMIUM, ULTIMATE, SILVER, GOLD
Le tableau de bord dans GitLab affiche des informations sur les projets dans l'ensemble de l'instance GitLab. Vous ajoutez des projets individuels un par un et pouvez sélectionner le projet qui vous intéresse.
Dans cette version, nous avons ajouté des informations sur les statuts des pipelines au tableau de bord. Les développeurs peuvent désormais voir le bon fonctionnement des pipelines dans tous les projets nécessaires - dans une seule interface.
Pipelines pour des résultats fusionnés
PREMIUM, ULTIMATE, SILVER, GOLD
En général, au fil du temps, la branche source diverge de la branche cible si vous ne déplacez pas continuellement les modifications entre elles. Par conséquent, les pipelines des branches source et cible sont « verts » et il n'y a pas de conflits de fusion, mais une erreur se produit lors de la fusion en raison des modifications incompatibles.
Lorsque le pipeline des demandes de fusion crée automatiquement un nouveau lien contenant le résultat fusionné des branches source et cible, nous pouvons déclencher le pipeline sur ce lien et garantir que le résultat global sera fonctionnel.
Si vous utilisez des pipelines de demandes de fusion (de n'importe quelle manière) et que vous employez des runners GitLab privés de version 11.8 ou antérieure, vous devez les mettre à jour pour éviter un problème. . Cela n'affecte pas les utilisateurs des runners GitLab publics.
Proposition de modifications sur plusieurs lignes
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Lors de la collaboration sur des demandes de fusion, vous remarquez souvent des problèmes et proposez des solutions. À partir de la version GitLab 11.6, nous supportons pour une seule ligne.
Dans la version 11.10, il est possible de proposer des modifications pour plusieurs lignes dans les commentaires du diff d'une demande de fusion, et ensuite tout utilisateur ayant des droits d'écriture dans la branche source peut les accepter d'un simple clic. Grâce à cette nouvelle fonctionnalité, vous pouvez éviter le copier-coller comme dans les versions précédentes.
Étiquettes dans un domaine
PREMIUM, ULTIMATE, SILVER, GOLD
Avec des étiquettes dans un domaine, les équipes peuvent appliquer des étiquettes mutuellement exclusives (dans le même domaine) pour une tâche, une demande de fusion ou un épic dans des scénarios avec des champs personnalisés ou des états de workflow personnalisés. Elles sont configurées à l'aide d'une syntaxe spéciale avec deux-points dans le titre de l'étiquette.
Supposons que vous ayez besoin d'un champ personnalisé dans les tâches pour suivre le système d'exploitation de la plateforme ciblée par vos fonctionnalités. Chaque tâche ne doit se rapporter qu'à une seule plateforme. Des étiquettes peuvent être créées platform::iOS, platform::Android, platform::Linux et d'autres si nécessaire. Si une telle étiquette est appliquée à une tâche, une autre étiquette existante qui commence par platform::.
Supposons que vous ayez des étiquettes workflow::development, workflow::review et workflow::deployed, représentant l'état du flux de travail dans votre équipe. Si une tâche a déjà une étiquette workflow::development, et qu'un développeur souhaite faire passer la tâche à l'étape workflow::review, il lui suffit d'appliquer une nouvelle étiquette, et l'ancienne (workflow::development) est automatiquement supprimée. Ce comportement existe déjà lorsque vous déplacez des tâches entre les listes d'étiquettes sur le tableau des tâches, qui représente le flux de travail de votre équipe. Maintenant, les membres de l'équipe qui ne travaillent pas directement avec le tableau des tâches peuvent modifier l'état du flux de travail directement dans les tâches.
Un nettoyage plus approfondi du registre des conteneurs
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Lors de l'utilisation habituelle du registre des conteneurs avec des pipelines CI, vous envoyez plusieurs modifications distinctes sous un seul tag. En raison de la mise en œuvre de la distribution Docker, le comportement par défaut est de conserver toutes les modifications dans le système, mais cela finit par occuper beaucoup de mémoire. Si vous utilisez le paramètre -m avec registry-garbage-collect, vous pouvez rapidement supprimer toutes les modifications précédentes et libérer de l'espace précieux.
Achat de minutes supplémentaires pour CI Runner
BRONZE, SILVER, GOLD
Les utilisateurs avec des plans payants GitLab.com (Gold, Silver, Bronze) peuvent désormais acheter des minutes supplémentaires pour CI Runner. Auparavant, il fallait respecter la quota prévu par le plan. Grâce à cette amélioration, il est possible d'acheter des minutes au-delà de la quota à l'avance pour éviter les interruptions dues à l'arrêt des pipelines.
Actuellement, 1000 minutes coûtent 8 dollars, et vous pouvez en acheter autant que vous le souhaitez. Les minutes supplémentaires commenceront à être consommées lorsque vous aurez épuisé votre quota mensuel, et le solde des minutes supplémentaires sera reporté au mois suivant. Dans , nous souhaitons ajouter cette fonctionnalité aux plans gratuits.
Auto DevOps modulable
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Avec Auto DevOps, les équipes adoptent des pratiques DevOps modernes presque sans effort. À partir de GitLab 11.10, chaque job dans Auto DevOps est fourni sous la forme d'un . Les utilisateurs peuvent utiliser dans GitLab CI pour inclure des étapes individuelles d'Auto DevOps tout en utilisant leur fichier personnalisé gitlab-ci.yml. Cela permet de n'inclure que les jobs nécessaires et de profiter des mises à jour en upstream.
Gestion automatique des membres de groupe sur GitLab.com avec SCIM
SILVER, GOLD
Auparavant, la gestion des adhésions aux groupes sur GitLab.com devait se faire manuellement. Désormais, vous pouvez utiliser SAML SSO et gérer les adhésions via SCIM pour créer, supprimer et mettre à jour des utilisateurs sur GitLab.com.
C'est particulièrement utile pour les entreprises ayant un grand nombre d'utilisateurs et des fournisseurs d'identité centralisés. Vous pouvez maintenant avoir une source unique de vérité, comme Azure Active Directory, et les utilisateurs seront créés et supprimés automatiquement par le biais du fournisseur d'identité, et non manuellement.
Connexion à GitLab.com via un fournisseur SAML
SILVER, GOLD
Auparavant, lors de l'utilisation de SAML SSO pour un groupe, l'utilisateur devait se connecter avec ses identifiants GitLab et le fournisseur d'identité. Désormais, il peut se connecter directement via SSO en tant qu'utilisateur GitLab lié au groupe configuré.
Les utilisateurs n'auront pas à se connecter deux fois, ce qui rend SAML SSO plus pratique pour les entreprises utilisant GitLab.com.
Autres améliorations dans GitLab 11.10
Schéma des épiques enfants
ULTIMATE, GOLD
Dans la version précédente, nous avions ajouté des épiques enfants (épiques d'épiques) pour faciliter la gestion de la structure de répartition des tâches. Les épiques enfants sont affichés sur la page de l'épique parent.
Dans cette version, la page de l'épique parent affiche le schéma des épiques enfants, permettant aux équipes de voir la chronologie des épiques enfants et de gérer les dépendances temporelles.
Écrans contextuels des demandes de fusion
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Dans cette version, nous introduisons des écrans informatifs qui apparaissent lors du survol du lien de la demande de fusion. Auparavant, nous ne montrions que le titre de la demande de fusion, mais maintenant nous affichons également le statut de la demande de fusion, le statut du pipeline CI et une URL courte.
Dans les versions futures, nous prévoyons d'ajouter plus d'informations importantes, comme , et nous introduirons également des écrans contextuels pour .
Filtrage des demandes de fusion par branches cibles
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Les workflows Git pour la publication ou la livraison de logiciels sont souvent associés à plusieurs branches à long terme — pour des corrections dans des versions antérieures (par exemple, stable-11-9) ou la transition de l'assurance qualité à la production (par exemple, intégration), mais il n'est pas si simple de trouver des demandes de fusion pour ces branches parmi de nombreuses demandes de fusion ouvertes.
La liste des demandes de fusion pour les projets et les groupes peut maintenant être filtrée par la branche cible de la demande de fusion, pour faciliter la recherche de ce dont vous avez besoin.
Merci, Hiroyuki Sato ()!
Envoi et fusion lors d'un pipeline réussi
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Si nous utilisons la méthode de développement basée sur le Trunk, nous devons éviter les branches à long terme au profit de petites branches temporaires avec un seul propriétaire. Des changements mineurs sont souvent envoyés directement dans la branche cible, mais cela comporte le risque de casser la build.
Dans cette version, GitLab prend en charge de nouveaux paramètres d'envoi dans Git pour ouvrir automatiquement des demandes de fusion, définir la branche cible et assurer la fusion lors d'un pipeline réussi depuis la ligne de commande lors de l'envoi vers une branche.
Intégration améliorée avec des tableaux de bord externes
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
GitLab peut interroger plusieurs serveurs Prometheus (au niveau de l'environnement, du projet et ), mais avoir plusieurs points de terminaison peut compliquer le système ou ne pas être pris en charge par les tableaux de bord standard. Dans cette version, les équipes peuvent utiliser une seule API Prometheus, ce qui simplifie considérablement l'intégration avec des services comme Grafana.
Tri des pages Wiki par date de création
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Dans la Wiki du projet, les équipes peuvent partager de la documentation et d'autres informations importantes aux côtés du code source et des tâches. Dans cette version, la liste des pages dans la Wiki peut être triée par date de création et par titre, pour trouver rapidement le contenu récemment créé.
Surveillance des ressources demandées par le cluster
ULTIMATE, GOLD
GitLab aide à surveiller le cluster Kubernetes pour les applications en développement et en production. À partir de cette version, surveillez les ressources processeur et mémoire demandées par le cluster pour repérer d'éventuelles difficultés avant qu'elles ne deviennent problématiques.
Affichage des métriques du répartiteur de charge sur le tableau de bord Grafana
CORE, STARTER, PREMIUM, ULTIMATE
Il est très important de suivre le bon fonctionnement de l'instance GitLab. Auparavant, nous fournissions des tableaux de bord par défaut via une instance intégrée de Grafana. À partir de cette version, nous avons inclus des tableaux de bord supplémentaires pour surveiller les équilibres de charge NGINX.
SAST pour Elixir
ULTIMATE, GOLD
Nous continuons à étendre le support des langages et à approfondir les vérifications de sécurité. Dans cette version, nous avons inclus des vérifications de sécurité pour les projets en et les projets créés sur .
Plusieurs requêtes dans un seul graphique
PREMIUM, ULTIMATE, SILVER, GOLD
Dans GitLab, vous pouvez créer des graphiques pour visualiser les métriques collectées. Souvent — par exemple, si vous souhaitez voir la valeur maximale ou moyenne d'une métrique — vous voudrez afficher plusieurs valeurs sur un seul graphique. À partir de cette version, vous avez cette possibilité.
Résultats DAST sur le tableau de sécurité du groupe
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Nous avons ajouté les résultats de tests de sécurité dynamiques (Dynamic Application Security Testing, DAST) au tableau de sécurité du groupe en plus de SAST, du scan de conteneurs et du scan de dépendances.
Ajout de métadonnées au rapport de scan de conteneurs
ULTIMATE, GOLD
Dans cette version, le rapport de scan de conteneurs contient plus de métadonnées — nous avons ajouté le composant concerné (fonction Clair) aux métadonnées existantes : priorité, identifiant (avec référence à mitre.org) et niveau concerné (par exemple, debian:8).
Ajout d'un type de rapport métrique dans les merge requests
PREMIUM, ULTIMATE, SILVER, GOLD
GitLab propose déjà plusieurs types de rapports qui peuvent être inclus directement dans les merge requests : des rapports sur et au stade de la révision jusqu'à et au stade de la protection.
Et bien que ces rapports soient importants, des informations de base adaptées à différents scénarios sont également nécessaires. Dans GitLab 11.10, nous proposons des rapports métriques directement dans la merge request, qui attend une simple paire clé-valeur. Ainsi, les utilisateurs peuvent suivre les changements dans le temps, y compris les métriques personnalisées, et les changements de métriques pour une merge request spécifique. L'utilisation de la mémoire, les tests de charges spécialisées et les états de disponibilité peuvent être transformés en simples métriques pouvant être visualisées directement dans les merge requests aux côtés d'autres rapports intégrés.
Prise en charge des projets multimodules Maven pour l'analyse des dépendances
ULTIMATE, GOLD
Dans cette version, les projets multimodules Maven prennent en charge l'analyse des dépendances de GitLab. Auparavant, si un sous-module avait une dépendance à un autre sous-module du même niveau, il ne pouvait pas résoudre le téléchargement à partir du référentiel central Maven. Maintenant, un projet multimodule Maven est créé avec deux modules et une dépendance entre les deux modules. La dépendance entre les modules du même niveau est désormais disponible dans le référentiel local Maven, permettant ainsi de continuer la construction.
Les utilisateurs peuvent modifier le chemin de clonage dans CI
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Par défaut, GitLab Runner clone le projet dans un chemin imbriqué unique dans $CI_BUILDS_DIR. Mais pour certains projets, comme Golang, le code doit être cloné dans un répertoire spécifique pour pouvoir être construit.
Dans GitLab 11.10, nous avons introduit la variable GIT_CLONE_PATH, qui permet de spécifier un chemin particulier où GitLab Runner clone le projet avant l'exécution de la tâche.
Masquage simple des variables protégées dans les journaux
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
GitLab propose plusieurs moyens et des variables dans GitLab CI/CD. Cependant, les variables peuvent toujours accidentellement ou intentionnellement apparaître dans les journaux de construction.
GitLab prend très au sérieux la gestion des risques et l'audit et continue d'ajouter des fonctionnalités pour respecter les exigences. Dans GitLab 11.10, nous avons introduit la possibilité de masquer certains types de variables dans les journaux de trace des jobs, ajoutant un niveau de protection contre l'apparition accidentelle du contenu de ces variables dans les journaux. De plus, GitLab masque désormais de nombreuses variables intégrées des jetons.
Activation et désactivation d'Auto DevOps au niveau du groupe
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Avec Auto DevOps dans un projet GitLab.com, vous pouvez facilement vous engager dans les workflows DevOps modernes – de la construction à la livraison.
Depuis GitLab 11.10, vous pouvez activer et désactiver Auto DevOps pour tous les projets d'un même groupe.
Page des licences simplifiée et améliorée
STARTER, PREMIUM, ULTIMATE
Pour faciliter la gestion des clés de licence, nous avons modifié le design de la page des licences dans le panneau d'administration et mis en avant les éléments les plus importants.
Mise à jour du sélecteur d'étiquettes pour les déploiements Kubernetes
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Les panneaux de déploiement affichent des informations sur tous les déploiements Kubernetes.
Dans cette version, nous avons modifié la façon dont les étiquettes sont mappées aux déploiements. Les correspondances par app.example.com/app et app.example.com/env ou app. Cela permettra d'éviter les conflits lors du filtrage et le risque de déploiements incorrects liés au projet.
De plus, dans la version GitLab 12.0, nous , et la correspondance ne sera possible que par app.example.com/app et app.example.com/env.
Création dynamique de ressources Kubernetes
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
L'intégration de Kubernetes dans GitLab permet d'utiliser la fonction RBAC avec un compte de service et un espace de noms dédié pour chaque projet GitLab. À partir de cette version, pour une efficacité maximale, ces ressources seront créées uniquement lorsqu'elles sont nécessaires pour le déploiement.
Lors du déploiement Kubernetes, GitLab CI créera ces ressources avant le déploiement.
Runners de groupe pour des clusters au niveau de groupe
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Les clusters au niveau de groupe prennent désormais en charge l'installation de GitLab Runner. Les runners Kubernetes au niveau de groupe s'affichent pour les projets enfants comme des runners de groupe, étiquetés. cluster et kubernetes.
Compteur d'appels pour les fonctions Knative
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Les fonctions déployées avec , affichent désormais le nombre d'appels reçus pour chaque fonction. Pour cela, il est nécessaire d'installer Prometheus sur le cluster où Knative est installé.
Contrôle des paramètres git clean pour les jobs GitLab CI/CD
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Par défaut, GitLab Runner exécute git clean au cours du processus de nettoyage du code lors de l'exécution d'un job dans GitLab CI/CD. À partir de GitLab 11.10, les utilisateurs peuvent contrôler les paramètres passés à la commande git clean. Cela est utile pour les équipes avec des runners dédiés, ainsi que pour les équipes qui construisent des projets à partir de grands monorepôts. Ils peuvent maintenant gérer le processus de nettoyage avant l'exécution des scripts. La nouvelle variable GIT_CLEAN_FLAGS a pour valeur par défaut -ffdx et accepte tous les paramètres possibles de la commande [git clean](https://git-scm.com/docs/git-clean).
Autorisation externe dans Core
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Les environnements protégés peuvent nécessiter une ressource d'autorisation externe supplémentaire pour accéder au projet. Nous avons ajouté le support d'un niveau de contrôle d'accès supplémentaire dans et avons reçu de nombreuses demandes pour ouvrir cette fonctionnalité dans Core. Nous sommes heureux de présenter l'autorisation externe et un niveau de sécurité supplémentaire pour les instances Core, car cette fonctionnalité est nécessaire pour certains participants.
Possibilité de créer des projets dans des groupes dans Core
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Le rôle de Developer peut créer des projets dans des groupes , et maintenant c'est possible aussi dans Core. La création de projets est une fonctionnalité clé pour un travail productif dans GitLab, et grâce à l'intégration de cette fonctionnalité dans Core, il est désormais plus facile pour les participants de se lancer dans de nouveaux projets.
GitLab Runner 11.10
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Aujourd'hui, nous avons publié GitLab Runner 11.10 ! GitLab Runner est un projet open source utilisé pour exécuter des tâches CI/CD et renvoyer les résultats vers GitLab.
Les changements les plus intéressants :
- .
- .
- .
- .
- .
La liste complète des changements peut être trouvée dans le journal des modifications de GitLab Runner : .
Correction de la valeur retournée project_id dans l'API de recherche de blob dans Elasticsearch
STARTER, PREMIUM, ULTIMATE
Nous avons corrigé un bug dans l'API de recherche de blob dans Elasticsearch, qui retournait incorrectement 0 pour project_id. Il faudra , pour obtenir les valeurs correctes project_id après l'installation de cette version de GitLab.
Améliorations d'Omnibus
CORE, STARTER, PREMIUM, ULTIMATE
Nous avons apporté les améliorations suivantes à Omnibus dans GitLab 11.10 :
- GitLab 11.10 inclut , , dont la dernière version comprend un nouveau catalogue d'intégration pour un transfert de données facile depuis Hipchat et bien plus encore. Cette version inclut , et nous vous recommandons de mettre à jour.
- Nous , et maintenant il est très facile de commencer à surveiller votre instance GitLab.
- Nous avons ajouté la prise en charge de la suppression des anciennes images de conteneurs du registre Docker.
- Nous avons mis à jour le ca-certs au 2019-01-23.
Améliorations des performances
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Nous continuons d'améliorer les performances de GitLab avec chaque version pour des instances de GitLab de toutes tailles. Quelques améliorations dans GitLab 11.10 :
- .
- .
- .
- .
- .
- .
- .
- .
Amélioration des graphiques GitLab
CORE, STARTER, PREMIUM, ULTIMATE
Nous avons apporté les améliorations suivantes aux graphiques GitLab :
- .
Fonctionnalités obsolètes
GitLab Geo permettra le stockage haché dans GitLab 12.0
GitLab Geo nécessite pour atténuer la concurrence sur les nœuds secondaires. Cela a été noté dans .
Dans GitLab , nous avons ajouté cette exigence à la documentation Geo : .
Dans GitLab sudo gitlab-rake gitlab:geo:check vérifie si le stockage haché est activé et si tous les projets sont transférés. Voir. . Si vous utilisez Geo, veuillez effectuer cette vérification et migrer dès que possible.
Dans GitLab un avertissement désactivable en permanence sera affiché sur la page Zone Admin › Geo › Nœuds, si les vérifications mentionnées ci-dessus ne sont pas autorisées.
Dans GitLab Geo utilisera les exigences du stockage haché. Voir. .
Date de retrait : 22 juin 2019.
Support pour Ubuntu 14.04
GitLab 11.10 sera la dernière version avec .
Canonical a annoncé la fin du support standard d'Ubuntu 14.04 depuis . Nous conseillons aux utilisateurs de passer à une version LTS supportée : Ubuntu 16.04 ou Ubuntu 18.04.
Date de retrait : 22 mai 2019.
Limitation du nombre maximum de pipelines créés par un seul envoi
Auparavant, GitLab créait des pipelines pour HEAD chaque branche dans l'envoi. Cela est pratique pour les développeurs qui soumettent plusieurs modifications (par exemple, dans une branche de fonctionnalités et dans la branche develop).
Mais lors de l'envoi d'un grand dépôt avec de nombreuses branches actives (par exemple pour le déplacement, le mirroring ou le branching), il n'est pas nécessaire de créer un pipeline pour chaque branche. À partir de GitLab 11.10, nous créons lors de l'envoi.
Date de retrait : 22 mai 2019.
Les chemins de code legacy obsolètes de GitLab Runner
À partir de Gitlab 11.9, GitLab Runner utilise clonage/appel du dépôt. Actuellement, GitLab Runner utilisera l'ancienne méthode si la nouvelle n'est pas prise en charge. Pour plus de détails, voir .
Dans GitLab 11.0, nous avons modifié la configuration du serveur de métriques pour GitLab Runner. metrics_server sera supprimé au profit de listen_address dans GitLab 12.0. Pour plus de détails, consultez .
À partir de la version 11.3, GitLab Runner a commencé à prendre en charge ; ce qui a conduit à de nouveaux paramètres pour . Il y a , un tableau des changements et des instructions pour la transition vers la nouvelle configuration est disponible. Pour en savoir plus, consultez .
Ces chemins ne seront pas disponibles dans GitLab 12.0. En tant qu'utilisateur, vous n'avez rien à changer, il suffit de s'assurer que l'instance GitLab fonctionne avec la version 11.9+ lors de la mise à niveau vers GitLab Runner 12.0.
Date de retrait : 22 juin 2019.
Paramètre obsolète pour la fonctionnalité de point d'entrée pour GitLab Runner
Dans la version 11.4, GitLab Runner a introduit le paramètre de fonctionnalité pour corriger des problèmes comme et .
Dans GitLab 12.0, nous passerons à un comportement correct, comme si le paramètre de fonctionnalité était désactivé. Pour plus de détails, consultez .
Date de retrait : 22 juin 2019.
Support obsolète pour les distributions Linux arrivées à EOL pour GitLab Runner
Certaines distributions Linux sur lesquelles GitLab Runner peut être installé ont atteint leur fin de vie.
Dans GitLab 12.0, GitLab Runner ne distribuera plus de paquets pour ces distributions Linux. Vous pouvez trouver une liste complète des distributions qui ne sont plus prises en charge dans notre . Merci à Javier Ardo () pour !
Date de retrait : 22 juin 2019.
Suppression des anciennes commandes GitLab Runner Helper
Dans le cadre des efforts pour soutenir , il a fallu abandonner certaines anciennes commandes utilisées pour .
Dans GitLab 12.0, GitLab Runner est lancé à l'aide de nouvelles commandes. Cela ne concerne que les utilisateurs qui . Pour plus de détails, consultez .
Date de retrait : 22 juin 2019.
Suppression du mécanisme legacy git clean de GitLab Runner
Dans GitLab Runner 11.10 de configurer comment Runner exécute la commande git clean. De plus, la nouvelle stratégie de nettoyage supprime l'utilisation de permet de rétablir les modifications dans les déploiements ; les états précédents sont toujours accessibles. et place la commande git clean après l'étape de décharge.
Étant donné que ce changement de comportement peut affecter certains utilisateurs, nous avons préparé le paramètre FF_USE_LEGACY_GIT_CLEAN_STRATEGY. Si vous définissez la valeur true, cela restaurera la stratégie de nettoyage héritée. Plus d'informations sur l'utilisation des paramètres de fonction dans GitLab Runner sont disponibles .
Dans GitLab Runner 12.0, nous supprimerons le support de la stratégie de nettoyage legacy et la possibilité de la restaurer à l'aide du paramètre de fonction. Pour en savoir plus, consultez .
Date de retrait : 22 juin 2019.
La section Infos système dans le panneau d'administration
GitLab fournit des informations sur votre instance GitLab dans admin/system_info, mais ces informations peuvent être inexactes.
Nous du panneau d'administration dans GitLab 12.0 et recommandons d'utiliser .
Date de retrait : 22 juin 2019.
Journal des modifications
Consultez toutes ces modifications dans le journal des modifications :
Installation
Si vous configurez une nouvelle installation de GitLab, visitez .
Mise à jour
Consultez .
Plans d'abonnement GitLab
GitLab est disponible en deux options : et .
: localement ou sur la plateforme cloud de votre préférence.
- Noyau: pour les petites équipes, les projets personnels ou une version d'essai de GitLab sans limite de durée.
- Starter: pour les équipes travaillant dans un même bureau sur plusieurs projets, ayant besoin d'un support professionnel.
- Premium: pour les équipes distribuées nécessitant des fonctionnalités avancées, une haute disponibilité et un support 24/7.
- Ultimate: pour les entreprises nécessitant une stratégie fiable et une mise en œuvre avec une sécurité améliorée et la conformité réglementaire.
— de GitLab.com: hébergé, géré et administré par GitLab sous pour les développeurs individuels et les équipes.
- Gratuit: dépôts privés illimités et nombre illimité de participants au projet. Les projets privés ont accès aux fonctionnalités de niveau Gratuit, tandis que les ont accès aux fonctionnalités de niveau Gold.
- Bronze: pour les équipes ayant besoin d'accéder à des fonctionnalités avancées de flux de travail.
- Silver: pour les équipes nécessitant des capacités DevOps plus robustes, une conformité réglementaire et un support rapide.
- Gold: convient à de nombreux jobs CI/CD. Tous les projets publics peuvent utiliser gratuitement les fonctionnalités Gold, quelle que soit l'option choisie.
Source : habr.com
