v9.27.0

dso-console 9.27.0

Objectif(s) de cette version

• Fiabiliser les opérations d’administration, de synchronisation et de gestion des projets.
• Renforcer la cohérence des rôles et des synchronisations avec les outils connectés.

Changements livrés

Pour les équipes projet

• Retrouver la branche choisie pour synchroniser un dépôt. Lorsque vous demandez la copie d’une branche d’un dépôt externe vers le GitLab du socle, son nom est conservé pour ce dépôt. Le formulaire le propose à nouveau après rechargement, sans saisie supplémentaire. Il s’agit de la dernière branche demandée, pas nécessairement de la dernière synchronisation réussie.
  Synchroniser un dépôt · #1672. Documentation à compléter — documentation#117

• Consulter les déploiements que l’on peut gérer. Le droit « Gérer les déploiements » permet désormais aussi de les lister, sans devoir ajouter séparément « Voir les déploiements ». Cette correction n’accorde pas ces droits à tous les membres du projet.
  Droits de déploiement · #2764. Documentation à compléter — documentation#118

• Éviter une seconde suppression des ressources d’un projet archivé. Une nouvelle demande d’archivage est refusée si le projet est déjà archivé. Elle ne renomme plus à nouveau le projet et ne relance plus les opérations de suppression des ressources associées.
  Gestion des projets · #2757. Documentation à compléter — documentation#119

Pour l’administration du socle

Les rôles du socle définissent les droits sur l’ensemble de la console, contrairement aux rôles propres à un projet.

• Consulter les déploiements depuis l’administration d’un projet. Dans « Administration → Projets → sélectionner un projet → Ressources », la rubrique « Déploiements » est accessible aux administrateurs autorisés à consulter le projet, même s’ils n’en sont pas membres. Elle pouvait auparavant rester masquée malgré leurs droits.
  Gestion des déploiements · #2764. Documentation à compléter — documentation#118

• Retrouver les écrans autorisés par son groupe de connexion. Si un rôle d’administration provient d’un groupe de connexion géré par Keycloak, la console en tient compte pour afficher les menus et les actions autorisés. Ils pouvaient rester masqués alors que le serveur reconnaissait déjà les droits de la personne.
  Authentification et droits · #2835.

• Continuer à utiliser la page des rôles après une création. Créer un rôle dans « Administration → Rôles » actualise la liste sans bloquer la page ni nécessiter de rechargement. La présence de rôles liés à des groupes de connexion ne fait plus échouer non plus l’affichage des décomptes de membres. Ce correctif ne signifie pas que les membres de ces groupes sont désormais comptés.
  Gestion des rôles · #2833 · #2781. Documentation à compléter — documentation#120

• Répercuter les attributions et retraits de rôles dans les services connectés. Les changements d’appartenance aux rôles d’administration sont transmis aux mécanismes de synchronisation de Keycloak et GitLab. Les groupes et droits correspondants sont mis à jour selon la configuration des intégrations.
  Groupes et rôles Keycloak · Synchronisation avec GitLab · #2204 · PR #2749.

• Reconnaître les groupes donnant des droits d’audit dans GitLab. La configuration GitLab peut associer plusieurs groupes de connexion aux droits d’administrateur ou d’auditeur. Avec la configuration par défaut, les groupes des rôles « Lecture Seule Plateforme » et « Sécurité Plateforme » sont correctement reconnus pour les droits d’auditeur GitLab. Le rôle « Sécurité Plateforme » donne des droits de consultation dans la console ; sa définition est préconfigurée et non modifiable, mais ses membres restent administrables.
  Rôles d’administration · Correspondance avec GitLab · #2792. Documentation à compléter — documentation#121 · Fiche GitLab inaccessible — documentation#126

• Modifier un cluster dédié sans perdre les projets autorisés. Changer sa description ou ses autres informations conserve les projets autorisés à y déployer leurs applications. Il n’est plus nécessaire de les rattacher à nouveau après chaque modification.
  Détail d’un cluster · #2838.

Pour l’exploitation du socle

Le reprovisionnement remet les ressources d’un projet en conformité avec sa configuration déclarative, c’est-à-dire la description de leur état attendu dans la console. Il ne s’agit pas de la copie d’une branche de code, décrite plus haut.

• Éviter les identifiants techniques et les commits de configuration inutiles. L’identifiant technique utilisé pour l’accès à Vault dans la configuration produite par Argo CD est conservé, puis réutilisé lors des synchronisations suivantes. Il n’est plus systématiquement régénéré à chaque passage. Cela évite les commits dus uniquement à ce renouvellement et l’accumulation de ces identifiants dans Vault. Cet identifiant, appelé secret-id AppRole, est distinct des secrets applicatifs stockés par les équipes.
  #2622. Documentation à compléter — documentation#122

• Ne plus confondre un coffre Vault existant avec un échec. Lors du reprovisionnement, la console reconnaît le coffre du projet avant de tenter de le créer. Sa présence normale ne produit plus l’avertissement trompeur path is already in use alors que l’opération réussit.
  Accéder au coffre Vault d’un projet · #2762.

• Poursuivre le reprovisionnement avec les éléments SonarQube déjà présents. Si le projet, le groupe ou le modèle de permissions attendu existe déjà avec le même identifiant, la console le retrouve au lieu d’échouer en tentant de le recréer.
  #2778. Documentation à compléter — documentation#123

• Préserver le nettoyage des secrets lors de l’archivage avec Vault 2.0. Les requêtes utilisées pour parcourir les secrets techniques à supprimer ne contiennent plus le double séparateur de chemin rejeté par cette version du serveur Vault. Ce correctif prépare la compatibilité du nettoyage avec Vault 2.0 ; il ne faut pas confondre cette version du serveur avec celle du moteur de secrets KV.
  PR #2678. Documentation à compléter — documentation#124

• Identifier le bon service dans le contrôle de santé. Le contrôle de disponibilité de GitLab utilise le nom gitlab dans sa réponse, et non plus vault. L’exploitation peut ainsi identifier le service concerné lorsqu’un contrôle échoue.
  PR #2780. Documentation à compléter — documentation#125