Description
Actuellement, les plugins du Console couplent la capacité métier (fournir une identité / un secret / un dépôt) à l'implémentation du service externe (GitLab, Vault, Keycloak…). Chaque plugin réimplémente la logique d'appel au service, ce qui :
- duplique la gestion d'erreurs, de retry et de mapping des credentials entre plugins ;
- rend le changement de fournisseur (ex. Vault → autre secret-manager) impossible sans réécrire le plugin ;
- empêche de tester la logique Console indépendamment du service externe.
L'objectif est d'introduire une couche interface par capacité (IdpProvider, SecretManagerProvider, VcsProvider, …) découplée des implémentations service externe (GitlabProvider, VaultProvider, …). Le plugin consomme l'interface ; l'implémentation est injectée. Cela isole la logique Console de l'origine du service et prépare un changement de fournisseur sans rupture de plugin.
PRs liées
No response
Issues liées
Exemples simples
No response
Spécifications techniques
No response
Définition du fini
Description
Actuellement, les plugins du Console couplent la capacité métier (fournir une identité / un secret / un dépôt) à l'implémentation du service externe (GitLab, Vault, Keycloak…). Chaque plugin réimplémente la logique d'appel au service, ce qui :
L'objectif est d'introduire une couche interface par capacité (
IdpProvider,SecretManagerProvider,VcsProvider, …) découplée des implémentations service externe (GitlabProvider,VaultProvider, …). Le plugin consomme l'interface ; l'implémentation est injectée. Cela isole la logique Console de l'origine du service et prépare un changement de fournisseur sans rupture de plugin.PRs liées
No response
Issues liées
Exemples simples
No response
Spécifications techniques
No response
Définition du fini