Lorsque vous exécutez un hook post-commit, le committer doit attendre que la validation soit terminée, ce qui signifie attendre que l'action post-commit elle-même soit terminée. Si cela prend trop long, et trop long peut être quelques secondes, les utilisateurs vont se révolter. Imaginez que chaque fois que vous faites un commit, le commit prend 15 secondes supplémentaires. Quinze secondes de vous assis là ne sachant pas ce qui se passe. Combien de temps l'utilisateur attend jusqu'à ce qu'il commence à essayer de terminer la validation?
Vous pouvez dupliquer les travaux Jenkins et mettre à jour le config.xml d'un travail via l'API REST de Jenkins. Ce n'est pas trivial, mais c'est possible. Cependant, ce n'est pas le mécanisme que vous voulez utiliser. Au lieu d'avoir des dizaines de jobs Jenkins qui construisent le sous-arbre du projet dans votre dépôt, vous avez un seul travail Jenkins qui construit le sous-arbre du projet qui a été modifié.
Imaginez que votre URL Subversion pour le projet foo est http://svn.vegicorp.com/projects/foo et votre URL de Subversion pour le projet bar est http://svn.vegicorp.com/projects/foo. Vous pouvez configurer un travail Jenkins pour surveiller http://svn.vegicorp.com/projects, puis voir si foo et/ou bar ont été modifiés, puis déclenchez la génération de ce sous-arbre particulier. Quand quelqu'un crée le projet http://svn.vegicorp.com/projects/fubar, Jenkins surveillera aussi ce projet puisqu'il regarde déjà http://svn.vegicorp.com/projects.
Vous pouvez utiliser le Build Name Setter Plugin pour définir le nom de la construction à la sous-arborescence qui a été créée. Cela vous permettra de voir quelles constructions étaient pour quels projets.
Cela devrait être beaucoup plus facile à installer dans Jenkins que d'essayer de créer des emplois Jenkins à la volée.
Merci beaucoup, très utile. Cela semble vraiment beaucoup plus facile par rapport à ce que j'avais en tête. Donc, si j'ai bien compris, ce que je dois faire est de créer un travail et de définir l'URL SVN à celle contenant tous les projets que je veux construire et tester. Ensuite, définissez "Profondeur du référentiel" sur "Infini" (pour que tous les projets contenus dans le sous-arbre soient récupérés), et configurez simplement ce travail comme je le ferais pour chaque travail. Droite? Ce serait génial. – RVKS
Je suppose que votre structure d'URL dans votre repo serait quelque chose comme 'http: // server/project/branches' ou' http: // server/branches/project'. Disons que c'est http: // server/branches/project'. Vous vérifiez pour 'http: // server' pour les changements. Ensuite, vous pouvez voir quelle branche et quel projet a été modifié et le construire. Utilisez le plugin set set setter pour spécifier la branche et le projet construits. Je suppose que tous vos projets se construisent de la même manière. –
Ok, merci beaucoup, juste une dernière question: je dois aussi envoyer un mail au committer qui finira par provoquer un échec dans les tests, mais, s'il a causé par exemple 5 erreurs dans un projet et un autre committer causé 3 erreurs Dans un autre projet, j'ai besoin que les deux soient envoyés avec le nombre correct d'erreurs qu'ils ont causé. Je suis sûr que cela fonctionnerait de la façon dont je voulais initialement créer des jobs Jenkins, mais votre méthode le fera-t-elle aussi ou les deux committers seront-ils prévenus de 8 erreurs (la somme de toutes les erreurs dans le job)? – RVKS