Un plugin core est un service de base associé à la chaîne DSO.
Un plugin external est un service supplémentaire facultatif.
Un hook est un point de déclenchement dont le cycle de vie comprend plusieurs étapes (step) : pre, main, post, etc.
Tout plugin peut s'enregistrer sur un hook, à une étape donnée.
Exemple :
- Le plugin
gitlabs'enregistre sur le hookcreateProject, à l'étapemain. - Le controller
createProjectControllerdéclenche le hookcreateProjecten lui associant unpayload. - Le plugin
gitlabréagit au déclenchement du hookcreateProjectet reçoit le payload associé du controller. - Le plugin
gitlabeffectue ses opérations (ex: création d'un groupe GitLab pour le projet). - Le plugin
gitlabrenvoie un objetresultau controllercreateProjectController, contenant unstatusindiquant si tout s'est déroulé sans erreur ou non. - Le controller
createProjectControllerenregistre ceresulten base de donnée et s'arrête si lestatusest en erreur.
{
// args come from controllers
args: {
projectName: 'toto',
},
failed: true || undefined
/*
[pluginName]: <PluginResult>
[pluginName]: <PluginResult>
...
*/
}Note: Si un module réutilise son propre payload, il doit penser à renvoyer le précédent s'il ne veut pas l'écraser. Charge aussi au plugin de gérer les erreurs des étapes précédentes.
{
status: {
result: string('KO' || 'OK'),
message: string(),
},
vault: [
{
name: string(),
data: {
// secret data
}
}
] || undefined
// otherKey: {},
// anotherKey: {},
}La communication des services associés à la chaîne DSO se fait au maximum en direct par les services Kubernetes via les url internes. On note toutefois les exceptions suivantes :
- Argocd communique avec l'url publique de Gitlab peu importe s'ils sont sur le même cluster.
- L'url publique de Harbor est utilisée dans les jobs de CI : il faudrait sinon une
imagePullSecretavec url interne pour les jobs de CI et une avec url publique pour les pods des clusters applicatifs.