Il arrive que vous ayez à déplacer ou copier des tâches de build Jenkins d'une instance Jenkins à une autre sans copier toute la configuration de Jenkins. Par exemple, vous pourriez migrer vos tâches de build vers une instance Jenkins sur une machine flambant neuve, avec une configuration système différente de celle de la machine initiale. Ou vous pourriez être en train de restaurer une vieille archive de tâche de build.

Comme nous l'avons vu, Jenkins stocke toutes les données nécessaires pour un projet au sein d'un sous-répertoire du répertoire jobs dans votre répertoire racine de Jenkins. Ce sous-répertoire est aisé à identifier — il a le même nom que votre projet. D'ailleurs, cela explique pourquoi vos noms de projets ne doivent pas contenir d'espaces, spécialement si Jenkins tourne sous Unix ou Linux — cela rend la maintenance et les tâches d'administrtions bien plus aisées si les noms de projet sont également des fichiers Unix correctement nommés.

Vous pouvez copier ou déplacer des tâches de build entre instances de projets assez simplement en copiant ou déplaçant les répertoires des tâches de build dans la nouvelle instance Jenkins. Le répertoire de la tâche du projet est autonome — il contient tant la configuration complète du projet que son historique des builds. Il est également possible de copier des répertoires de tâches de build dans une instance Jenkins en cours de fonctionnement. Toutefois, si vous effacez également ces répertoires du serveur originel, vous devriez en premier stopper ce dernier. Vous n'avez même pas besoin de redémarrer la nouvelle instance Jenkins pour voir le résultat de votre import, allez simplement à l'écran "Administrer Jenkins" et cliquez sur "Recharger la configuration à partir du disque". Cela chargera les nouvelles tâches de build et les rendra immédiatement visible sur le tableau de bord Jenkins.

Il y a quelques précautions à prendre toutefois. Si vous migrez vos tâches vers une installation toute fraîche de Jenkins, souvenez vous d'installer ou de migrer les plugins de votre précédent serveur. Les plugins se trouvent dans le répertoire plugins , il suffit donc de simplement copier tout le contenu de ce répertoire dans le répertoire correspondant à votre nouvelle instance.

Bien sûr, vous pourriez être en train de migrer les tâches de build vers une nouvelle instance présicément parce que la configuration des plugins est problématique. Certains plugins peuvent parfois être un peu bogués, et vous pourriez vouloir une installation propre avec des plugins bien précis. Dans ce cas, vous pourriez avoir à retravailler certaines configurations de projets une fois ceux-ci importés.

L'explication de cela est simple. Quand vous utilisez un plugin dans un projet, le fichier config.xml du projet est mis à jour avec des champs de configuration spécifiques au plugin. Si, pour quelques raisons que ce soit, vous devez migrer des projets vers une installation Jenkins sans ces plugins, Jenkins ne comprendra pas les parties correspondantes de la configuration de ces projets. La même chose peut également arriver si les versions des plugins sont très différentes et que le format des données de configuration a changé.

Si vous migrez des tâches vers une instance Jenkins avec une configuration différente, il est également intéressant de garder un oeil sur les logs systèmes. Les configurations de plugin invalides sont généralement visibles via des alertes ou des exceptions. Bien que non fatal, ces messages d'erreurs indiquent souvent que le plugin ne fonctionnera pas comme attendu, voir pas du tout.

Jenkins offre des fonctionnalités utiles pour vous aider à migrer les configurations de vos projets. Si Jenkins trouve des données qu'il considère invalides, il vous le fera savoir. Sur l'écran "Administrer Jenkins", vous aurez des messages comme celui dans Figure 13.15, “Jenkins vous informe si vos données ne sont pas compatibles avec la version actuelle” .

Plusieurs options s'offrent alors à vous. Vous pouvez laisser la configuration en l'état, par exemple si vous souhaitez revenir à une version précédente de votre instance Jenkins. Vous pouvez aussi laisser Jenkins ignorer les champs qu'il ne peut lire. Si vous retenez cette option, Jenkins affichera un écran avec plus de détails sur l'erreur et il pourra même, si vous le souhaitez, vous aider à nettoyer votre fichier de configuration (voir Figure 13.16, “Gestion de configuration périmée” ).

Cet écran donne plus de détails sur le projet contenant les données périmées ainsi que le message d'erreur obtenu. Cela offre plusieurs possibilités. Si vous êtes sûr de ne plus avoir besoin du plugin ayant originellement créé ces données, vous pouvez supprimer les champs fautifs en toute sécurité en cliquant sur le bouton "Discard Unreadable Data". Il est aussi possible que ces données appartiennent à un plugin qui n'a pas encore été installé sur cette instance Jenkins. Dans ce cas, installez le plugin et tout devrait aller bien. Enfin, vous pouvez toujours choisir de laisser les données redondantes et de vivre avec le message d'erreur, au moins jusqu'à ce que vous soyez sûr de ne plus avoir à migrer ces données vers l'ancien serveur.

Cependant, Jenkins ne détecte pas toujours toutes les erreurs et inconsistences. Il est toujours utile de garder un oeil sur les fichiers de log lorsque que vous migrez vos tâches de build. Par exemple, ce qui suit est un exemple réel d'un fichier de log Jenkins montrant ce qu'il peut arriver pendant une migration :

Mar 16, 2010 2:05:06 PM
			hudson.util.CopyOnWriteList$ConverterImpl unmarshal
			WARNING: Failed to resolve class com.thoughtworks.xstream.mapper.CannotResolveClassException:
			hudson.plugins.cigame.GamePublisher :
			hudson.plugins.cigame.GamePublisher
			at
			com.thoughtworks.xstream.mapper.DefaultMapper.realClass(DefaultMapper.java:68)
			at
			com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
			at
			com.thoughtworks.xstream.mapper.DynamicProxyMapper.realClass(DynamicProxyMapper.java:71)
			at
			com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)

Cette erreur nous informe que Jenkins ne peut trouver une classe appelée hudson.plugins.cigame.GamePublisher . En fait, l'installation cible n'a pas le plugin "CI Game". Et dans ce cas (comme cela arrive parfois), aucun message d'alerte n'est apparu sur la page "Administrer Jenkins". Par conséquent, Jenkins n'a pas été capable de corriger le fichier de configuration par lui même.

La solution la plus simple, dans ce cas, serait d'installer le plugin "CI Game". Mais que faire si on ne veut pas installer ce plugin? Nous pourrions laisser les fichiers de configuration en l'état, mais cela pourrait cacher des erreurs plus importantes ultérieurement. Il serait mieux de les nettoyer.

Dans ce cas, il faut inspecter et modifier les fichiers de configuration du projet à la main. Sur cette machine Unix, j'ai juste utilisé grep pour trouver tous les fichiers de configuration contenant "cigame" :

			$
			cd $JENKINS_HOME/jobs
			$
			grep cigame */config.xml
			project-a/config.xml: <hudson.plugins.cigame.GamePublisher/>
			project-b/config.xml: <hudson.plugins.cigame.GamePublisher/>
			project-c/config.xml: <hudson.plugins.cigame.GamePublisher/>
		

Dans ces fichiers config.xml , j'ai trouvé une référence au plugin CI Game dans la section <publishers> , là où se trouve généralement les configurations des plugins réalisant des rapports :

<maven2-moduleset>
			...
			<publishers>
			<hudson.plugins.cigame.GamePublisher/>
			<hudson.plugins.claim.ClaimPublisher/>
			</publishers>
			...
			</maven2-moduleset>

Pour résoudre le problème, il suffit de supprimer la ligne incriminée:

<maven2-moduleset>
			...
			<publishers>
			<hudson.plugins.claim.ClaimPublisher/>
			</publishers>

			...
			</maven2-moduleset>

L'emplacement précis des données de configuration du plugin varie en fonction du plugin, mais en général les fichiers config.xml sont relativement lisibles. Les mettre à jour manuellement n'est pas trop compliqué.

Au final, migrer des tâches de build entre des instances Jenkins n'est pas si dur. Vous avez juste besoin de connaitre quelques astuces pour les cas particuliers, et, si vous savez où regarder, Jenkins fournit de beaux outils pour rendre le processus aisé.