Faire en sorte que Jenkins construise plusieurs configurations avec des URL SVN variables

Question

Je souhaite automatiser nos processus de construction.

Nous avons plus de 30 configurations, chacune avec une branche SVN différente. Idéalement, je voudrais éviter d'avoir à créer 30 jobs Jenkins distincts, en raison de l'effort de maintenance et du risque d'erreur humaine.

C'est pour cela que le "projet multi-configuration" dans Jenkins a été conçu, mais malheureusement Jenkins ne supporte pas l'utilisation de l'axe de la matrice de configuration dans l'URL SVN.

Je ne peux pas non plus construire en utilisant la construction paramétrée, parce que Jenkins n'autorise pas l'utilisation des variables dans les chemins d'accès locaux (les variables dans les URL fonctionnent bien, mais elles finissent toujours par aller dans un répertoire appelé ${BRANCH} (littéral).

En fin de compte, j'aimerais pouvoir consulter https://domain.ext/something/${BRANCH}/ et l'enregistrer dans /some/path/${BRANCH} . C'est encore mieux si cela se fait d'une manière qui me permette de profiter des fonctions SCM intégrées de Jenkin (par exemple, le polling).

Comment puis-je faire comprendre à Jenkins ce que j'essaie de faire ?

Answer 1

Il y a deux façons de faire ce que vous souhaitez, selon moi. Vous pouvez soit ajouter toutes les branches dans un seul projet (via "add location" dans la configuration), les vérifier dans différents répertoires et déterminer "manuellement" ce qui a changé (ou tout compiler). Cela pourrait être intégré à la multi-configuration, l'axe de configuration étant les différents emplacements d'extraction, c'est-à-dire que chaque configuration obtient un répertoire de travail différent par le biais du paramètre.

L'autre solution serait de ne pas informer Jenkins de l'existence du dépôt, mais de déclencher les constructions manuellement (par exemple par le biais d'un crochet de commit SVN) et d'extraire les sources lors de la première étape de construction. Là encore, il s'agirait d'un projet multi-configuration, selon des principes similaires à ceux décrits ci-dessus.

Answer 2

J'ai fini par résoudre ce problème en demandant à Jenkins de vérifier le dépôt SVN à un niveau si élevé qu'il contenait toutes les branches dont j'avais besoin. Ce n'est cependant pas une solution idéale, car vous perdez du temps pendant les constructions en exécutant 'svn update' sur tout .

Answer 3

J'ai eu un problème similaire avec une échelle plus petite : J'ai dû construire un tronc et une branche avec la même configuration, mais des chemins SVN différents.

La première tentative a été d'utiliser $SVN_BRANCH dans l'URL de la caisse et de le définir avec un paramètre de type chaîne. Cela a bien fonctionné avec l'utilisation manuelle, mais pas avec le travail matriciel (comme Aleksi l'a déjà souligné). Tout ce que j'ai pu faire avec un matrix build, c'est de déclencher le job paramétré comme un job de suivi, ce qui n'est pas très joli.

J'ai fini par utiliser le "Jobcopy Builder plugin" : J'ai désactivé mon travail initial et je l'ai utilisé comme modèle. Dans le job de copie, j'ai une étape de construction "copy job" qui copie le job désactivé, remplace $SVN_BRANCH par le nom réel de la branche (trunk ou branches/some_branch) et active ces deux jobs. Comme j'ai également coché l'option "overwrite", toutes les configurations des jobs sont mises à jour après l'exécution du "copy job" et l'historique de construction est préservé.