On aurait besoin d’avoir un fichier qui se mette à jour avec des informations tel que, le numéro de version, la date du module, et l’environnement, tous portées par des params systèmes. Afin de ne pas avoir les informations dédoublés. De ce fait, on pensait ce servir du code pour mettre a jour cette valeur, on pourrait au mieux avoir un code déclenché à l’export du module (si c’est possible, but principal du post), au pire un bouton d’action qui le mettent à jour.
On a besoin de générer un document qui contienne des informations statics propre au projet et des informations dynamiques tel que la version, la date version, et l’environnement (conso/integ/pprod/prod). et ce dernier doit être au format .yml
Le où n’as pas d’importance, l’utilisation, c’est un livrable qui nous a été demandé pour l’ensemble de nos projets, sont but exact je ne sais pas hormis qu’il doit respecter la norme de nommage info.yml et contenir des informations spécifique.
L’intérêt de la demande et de rendre sa mise à jour automatique et de ne pas dupliquer des informations déjà portée par le SI en les réécrivant à la main ( ce qui réduit aussi le taux d’erreur)
Je pose la question car vous voulez mélanger des information sur le module et des informations sur l’environnement, ce qui implique un livrable par environnement. Cela est contre-intuitif sans contexte supplémentaire, car en théorie on n’exporte le module que depuis l’environnement de développement, pas depuis les autres que vous évoquez (intégration, préproduction, etc) sur lesquels le module est uniquement importé. Cet élément ne fait pas sens pour moi et j’ai donc besoin de précisions pour éviter les hors sujets.
Bonjour,
Merci de votre attente,
Après discussion, il a été décidé de ne pas gérer l’écriture automatique du fichier dans le code mais, avec un “job” git qui l’écrirais lors des merges request, le temps que ce soit mis en place on va rester sur des données dupliqué entre ce que possède le fichier et les information de l’appli.
