Hudson Upgrade Forgets Projects
For no other good reason than it was released, I upgraded Hudson, the CI tool I use to test my projects. The upgrade was successful, but at the same time fails miserably by losing the previously configured jobs and their runs.
OK, so nothing was actually lost, but nothing is there, either.
Looking under the hood, the jobs still exist in their folders on the server. Creating a job of the same name uses the existing directory, but not only doesn't see the previous data, but also overwrites the config.xml file for the job.
I thought for a bit that perhaps there was an additional configuration file or database entry somewhere that was introduced since my last update. I decided to press on to recreate this job and see if Hudson behaved. If it did, I figured I could make a back-up of the other jobs' configuration properties files, and at least use them as templates to more quickly rebuild them, too.
After a little (too much) dorking around, I managed to get my project building again, and none of the previous files (except the build number) were lost or overwritten. The build finally succeeded, the Twitter and Google Calendar plug-ins updated correctly, and the graphs populated with what looked to be the right data for the builds done trying to get the job reconfigured.
Satisfied that I had the build right, I decided to change the build number so the history could continue in the right order, even though all of the previous files weren't being recognized by the tool at least I'd be able to see the notices roughly matching the SVN number (as previous). As I had done before, I edited the build number to be the correct next number, and bonked the link to re-read the configuration from disk.
Hudson again forgot my job. It not only continued to not see the other jobs, but also didn't see the newly created job.
I backed-up the config.xml file for the job, recreated it without any settings. Holding my breath I again bonked the button and watched as that job also disappeared. I restored the config.xml file and next build number and decided to await the next Hudson release rather than try to find the correct previous version I was using or the point in the many versions between where this doesn't occur.
After chasing the trouble around a little bit, I found that the problem lie with the new installation’s inability to affect the contents of the $HUDSON_HOME/plugins folder. This I found by following clues in the Tomcat log file. Within was a maven-plugin folder and maven-plugin.hpi file that I was able to move, allowing Hudson to start without a problem. Similarly, removing other plugins allowed their update to succeed where previously this also had bombed.