Jenkins - Surveiller les branches SVN

Question

Existe-t-il un moyen d'amener Jenkins à rechercher des changements dans toutes les branches d'un projet SVN, comme il le fait avec Git? Le Piggybank d'Apache Piggybank est un ensemble de classes auxquelles la communauté contribue et qui ajoute de l'extention à des versions spécifiques d'Apache Pig. Pig lui-même est publié via Maven, donc en obtenir une version spécifique n'est jamais un problème. Par contre, Piggybank n'est pas versionnée, cependant il y a des branches pour chaque version de Pig dont elle dépend. J'aimerais que Jenkins surveille, puis crée, pour toutes les branches du référentiel SVN de Pig. Je préfère ne pas avoir à surveiller les nouvelles versions de Piggybank et ajouter un job Jenkins pour chaque branche.

Answer 1

Vous pouvez ajouter plusieurs emplacements de référentiel à un seul projet et les faire extraire dans des répertoires différents. Vous devrez toujours ajouter toutes les branches manuellement.

Answer 2

Voici quelques précisions sur les lignes de @Lars répondre:

Créer l'emploi de déclenchement (appelons-le Trigger) qui checkout chaque branche dans un répertoire différent dans son espace de travail (en passant, vous pouvez créez ces répertoires manuellement dans l'espace de travail avec l'option --depth=empty, alors Subversion Plugin détectera toujours les changements, mais ne récupérera pas le code en vous économisant de l'espace au cas où vous auriez beaucoup de branches).

Vous pouvez ensuite utiliser SNV_REVISION_n (où n est 1, 2, etc .; voir Subversion Plugin Documentation) dans un script qui Trigger invoque comme une étape de construction pour vérifier quelle branche (ou branches) ont vraiment changé (vous devez stocker les résultats, bien sûr, à utiliser dans le prochain Trigger build).

Ensuite, vous créez un seul travail (appelons-le Worker) qui prend le nom de la branche en tant que paramètre. Le déclencheur appellera Travailleur via http avec wget ou curl avec les paramètres appropriés (par exemple, nom de la branche).

Vous pouvez avoir un emploi Trigger par branche et invoquer travailleur en utilisant Parameterized Trigger Plugin. L'inconvénient est que vous aurez besoin de créer un Trigger par branche et vous aurez plus d'interrogations SVN (sauf si vous utilisez SVN push). D'autre part, vous aurez pas besoin d'écrire un script qui vérifie
quelle branche a changé et vous pouvez utiliser Blame Subversion Plugin pour propager le changeset de Trigger-travailleur (et seulement des changements pertinents à la branche à cela).

Travailleur va mettre à jour/checkout la branche passée à lui comme un paramètre manuellement (svn co etc) et construire.

De cette façon, vous avez seulement un emploi qui ne soulever des objets lourds réel (ce qui signifie un entretien plus facile, moins de bugs, etc.)

J'emploie cette méthode dans notre système de construction. Comme nous n'avons pas plus de 2 branches actives à la fois, j'utilise l'approche trigger par branche.