added a comment - - edited
On top of this, if you go into 'Manage Jenkins', change anything (even something unrelated to the JDK), and save, it will change your existing JDK ids blank! For example, I had:
which was replaced by
(empty <id> tag). So the next time a build ran on my slaves, Jenkins removed the existing JDK install and all the builds started failing. When I fixed the tag, and reloaded Jenkins, the autoinstaller tried to run, but was failing because Windows thought the JDK was already installed. What I ended up having to do was.
1) Stop the slave
2) Log in to the slave machine
3) Copy the JDK files back to the /tools directory
4) Remove the JDK through Add/Remove programs (had to do step 3 or this wouldn't work)
5) Start the slave
After that the autoinstaller was able to run successfully and re-install the JDK. A huge pain, but luckily we don't have too many slaves. Maybe there was an easier way to fix it, but this worked for me.
In any case, if you change anything in 'Manage Jenkins' before this is fixed, verify your JDK installs have valid <id> tags. (I'm not sure how the save process works, but maybe in the future don't allow a blank value in this tag?) Another suggestion would be to break up the 'Manage Jenkins' page so one 'Save' doesn't have the potential of affecting so much. Finally, verify that if a JDK is removed by jenkins it runs the uninstaller if on windows.
I've been using Jenkins for quite a while and this is the first time it really gave me a scare! Hopefully others can avoid this one.