The simplest solution in this case would be to install the CI Game plugin on the target server. But what
if we don’t want to install this plugin? We could leave the configuration files alone, but this might mask
more significant errors later on—it would be better to tidy them up.
In that case, we need to inspect and update the project configuration files by hand. On this Unix box, I
just used grep to find all the configuration files containing a reference to “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/>In these config.xml files, I found the reference to the CI Game plugin in the
(which is where the configuration for the reporting plugins generally goes):
<maven2-moduleset><publishers>
<hudson.plugins.cigame.GamePublisher/>
<hudson.plugins.claim.ClaimPublisher/>
</publishers></maven2-moduleset>To fix the issue, all I have to do is to remove the offending line:
<maven2-moduleset><publishers>
<hudson.plugins.claim.ClaimPublisher/>
</publishers></maven2-moduleset>The exact location of the plugin configuration data will vary depending on the plugin, but in general the
config.xml files are quite readable, and updating them by hand isn’t too hard.
So, all in all, migrating build jobs between Jenkins instances isn’t all that hard—you just need to know
a couple of tricks for the corner cases, and if you know where to look Jenkins provides some nice tools
to make the process smoother.
13.7. Conclusion
In this chapter, we looked at a number of considerations that you should be aware of if your job is to
maintain your Jenkins server, including how to monitor disk and server usage, how to back up your build
jobs and Jenkins configuration files, and also how to migrate build jobs and upgrade build data safely.