Hudson jobs and slave node are missing after an upgrade

Question

Where and how are Hudson jobs and slave information stored?

I accidentally canceled a Hudson upgrade today. It wouldn't permit me to continue the upgrade; only to downgrade to the previous version and then upgrade again. After I downgraded, the two jobs I had created in the recent past were gone from the dashboard along with the slave node I created for one of those jobs, and the job I had recently deleted showed up in the dashboard. After the upgrade, the jobs and nodes are in that same state.

What happened? Can I restore my recent jobs and nodes, and how would I do that? Please keep in mind that while I know C/C++ well, web services are out of my area and I don't really know what a jar or a war is... I just followed online directions to install and set up Hudson and it worked. I wish to avoid simply re-creating those jobs; setting up one of them was less than trivial.

More info: Looking in the configuration, the home directory is incorrect; it thinks HOME is /root/ instead of /home/hudson. How did it change, and how do I change it back?

The previous version of Hudson is 1.379. It's currently running 1.381. I'm running it on RHEL 5.

When I look in the .hudson/jobs directory, both of the recent jobs are there, and the previously deleted job is not there. These job directories are missing their "workspace" directories.

Answer 1

As you've noticed, job configuration is stored in HUDSON_HOME/jobs/[name]/config.xml.

Slave configuration is stored in the main Hudson config file, HUDSON_HOME/config.xml.

I'm not sure why Hudson didn't pick up the jobs when you restarted after the upgrade. Checking the Hudson log might provide a clue, usually /var/log/hudson/hudson.log.

If your jobs' config.xml files are present, Hudson might be able to reread them if you reload your configuration (Manage Hudson -> Reload Configuration From Disk). If Hudson still doesn't recognize them (and the config file is present), your best bet is probably to recreate the jobs manually grabbing whatever you can from the config file (keeping in mind that XML escapes are applied to text fields like the build commands).

Answer 2

I got a helpful clue when I revisited the "manage hudson" page and saw a message that I had data in an old and unreadable format. That suggested Hudson was running a .war that was different from the one used more recently. So I searched the disk for any "hudson.war" files and found two; one from a couple of weeks ago and one from some months ago. The newer one is in the place I expected to find one, and the older one was elsewhere. I renamed the older one. Also, I have a start-hudson.sh script, added 'export HUDSON_HOME=/home/hudson' to that script, and used it to restart hudson. Lo and behold, my new jobs were back and working.

I would have thought that simply naming the HUDSON_HOME variable would have done it, but I did that first and restarted Hudson, and no joy. It was only after I renamed the older .war AND had set the environment variable that I found the fix. My guess would be that the older .war file had root set as HUDSON_HOME and that somehow that .war was being run, but the version showed on the page was the current version. I don't understand it, but I'm happy to be back in business.