Refactor : Surcharge des registries ghcr et docker et gestion conditionnelle de Nexus

[benji78]

Quel est le comportement actuel ?

Les URLs des registries (ex: ghcr.io, docker.io) sont hard codés dans chaque fichier CI (kaniko-ci.yml, mirror.yml, sonar-ci.yml, vault-ci.yml).
La récupération des identifiants Nexus dans vault-ci.yml est non conditionnelle : si le chemin /NEXUS n'existe pas dans Vault, le pipeline échoue.

Quel est le nouveau comportement ?

• Surcharge des registries :
  Les variables globales (GHCR_REGISTRY, DOCKER_REGISTRY) sont définies en haut de chaque fichier CI et utilisées pour surcharger les URLs des registries.
  Cela permet de centraliser la configuration et d'utiliser un autre registry sans introduire de breaking changes (les valeurs par défaut restent identiques).

• Gestion conditionnelle de Nexus :
  Dans vault-ci.yml, la récupération des identifiants Nexus est désormais conditionnelle :

  • Vérification de l'existence du chemin /NEXUS dans Vault avant toute tentative de récupération.
  • Si le chemin n'existe pas, les variables Nexus sont laissées vides (avec des valeurs par défaut via ${VAR:-}).
  • Cela permet de désactiver le plugin Nexus dans la console sans impacter le pipeline.

• Nettoyage mineur :
  Suppression des espaces superflus (formatage automatique).

Cette PR introduit-elle un breaking change ?

Non :

• Les valeurs par défaut des registries (ghcr.io, docker.io) restent inchangées.
• La gestion conditionnelle de Nexus est rétrocompatible : si le chemin /NEXUS existe, le comportement est identique à avant.

Autres informations

Aujourd'hui la console offre la possibilité de désactiver le "plugin" Nexus, mais le job vault-ci ne passe pas en l'absence du chemin /NEXUS dans l'espace Vault du projet qui est créé uniquement avec ce plugin.