Le point n°1 c'est la sécurité. On ne va pas laisser "n'importe qui" écrire son bout de code et l’exécuter "les yeux fermés".
On pourrait considérer que seuls quelques utilisateurs sélectionnés ont le droit de le faire mais se posent alors deux autres problèmes
- la dépendance aux admins centraux. Ce sont à eux d'écrire ou de revoir le code en question => ca ne sera pas fait et le point n°1 reste valable.
- la dépendance aux APIs internes de Tuleap. Tuleap bouge beaucoup et bouge vite, il n'y a aucune garantie de compatibilité sur les APIs internes. Le coût de mise à jour serait énorme pour garantir une upgrade "smooth".
La meilleure solution aujourd'hui est de se baser sur les mécanismes d'extension déjà présent (post-action "jenkins" du workflow ou webhooks) et d'avoir une implémentation indépendante qui utilise les APIs publiques (testées et stables) pour faire la logique particulière.
Peut être qu'a terme nous mettrons à disposition des éléments pour faciliter ces déploiements (genre github actions & co) mais c'est assez "lourd" à concevoir quand on doit prendre en compte le passage à l'échelle (autant j'imagine assez bien comment faire ça pour une petite instance à quelques dizaines d'utilisateurs, autant les instances avec 10k trackers et 45k personnes, la dépendance c'est une truc comme k8s ou OpenFaaS).
[^] # Re: Tuleap
Posté par vaceletm . En réponse au journal Gestion des tickets/workflows. Évalué à 2.
Le point n°1 c'est la sécurité. On ne va pas laisser "n'importe qui" écrire son bout de code et l’exécuter "les yeux fermés".
On pourrait considérer que seuls quelques utilisateurs sélectionnés ont le droit de le faire mais se posent alors deux autres problèmes
- la dépendance aux admins centraux. Ce sont à eux d'écrire ou de revoir le code en question => ca ne sera pas fait et le point n°1 reste valable.
- la dépendance aux APIs internes de Tuleap. Tuleap bouge beaucoup et bouge vite, il n'y a aucune garantie de compatibilité sur les APIs internes. Le coût de mise à jour serait énorme pour garantir une upgrade "smooth".
La meilleure solution aujourd'hui est de se baser sur les mécanismes d'extension déjà présent (post-action "jenkins" du workflow ou webhooks) et d'avoir une implémentation indépendante qui utilise les APIs publiques (testées et stables) pour faire la logique particulière.
Peut être qu'a terme nous mettrons à disposition des éléments pour faciliter ces déploiements (genre github actions & co) mais c'est assez "lourd" à concevoir quand on doit prendre en compte le passage à l'échelle (autant j'imagine assez bien comment faire ça pour une petite instance à quelques dizaines d'utilisateurs, autant les instances avec 10k trackers et 45k personnes, la dépendance c'est une truc comme k8s ou OpenFaaS).