I've completed the Jenkins build script, after some more tweaking and testing, and it's working fine. I've updated the wiki page about it, and GN has put in a request for a new VM we can build up to replace the old one. Learned quite a lot in the process of doing this. The horrible curl request in the previous post actually works, if you do it at the right time (after downloading all the jobs, setting them up, and restarting Jenkins so it knows the jobs are there).
I think we may be able to do the form submit to generate configs like this:
Updated the wiki page after testing the build a couple more times, so now the wiki points to the current version of the script in SVN and gives appropriate instructions. However, I still haven't solved the log-parse-rules file issue. I will have to figure out some way to watch what happens when that Save button in the config screen is clicked, and mimick it using curl or wget. It's very messy.
I'm trying to figure out an easy way of putting a Jenkins config (config.xml) file into the directory where it's expecting it to be, in the hope that this will cause Jinks to use the correct log parse rules when running jobs. I can create a generic config file, but I want to make sure that it doesn't have the wrong Jenkins build number in it. Once I have the right build number from the current Jenkins instance, I'll be able to pass it as a parameter to an XSLT transformation. Here's one approach which works:
wget -O /tmp/jinks.html http://localhost:8080 JINKSBUILD=`grep -oP '(?<=Jenkins ver\. )(1.[0-9\.]+)(?=</a>)' /tmp/jinks.html`
I'm also going to investigate the option of using the Jenkins CLI interface.
I've now got all important data off my old Lucid box (the Drive2 data), onto my new machine. We can now take out Drive2 from that machine and use it in a cradle, and repurpose the machine.
Problems solved this afternoon:
- rnv was failing to download and build; ampersands in the url query string needed to be backslash-escaped, and the file name needed to be specified with the -O flag.
- The log parse rules were not actually being used, even though they were downloaded, and were referred to in the job configs. I think this is because a file called hudson.plugins.logparser.LogParserPublisher.xml also needed to be there, to specify that the other file exists somehow. That's the theory anyway; not tested yet.
- Emailing could never have worked without going to a lot of trouble to mess with Jenkins's setup, so I'm simply sidestepping it and leaving it up to the user to set it up if they want to. I'm removing mine and SR's email addresses from the job configs.
- The Priority Sorter is working, but didn't actually solve the sequencing problem for the first build. Jinks managed to complete OxGarage, Roma and Stylesheets1 before Stylesheets completed, so it just had time to start and fail on P5-Test before the required artifacts were there. I'm consideriong making P5-Test a downstream job from Stylesheets, which should solve it once and for all.
- Core files are now in the TEI repo, as they should be, and the hudson log parse rules have been moved from P5/Source to Documents/Editing/Jenkins, where all the rest of the stuff is.
It turns out that the response at the command line when you try to run rnv is completely misleading. It leads you to believe that the executable is missing, whereas it's clearly there. Actually the problem is caused by the fact that the rnv installed from the TEI repo is 32-bit, and won't run on a 64-bit kernel.
So instead of installing it from the repos, I'm downloading and building it instead:
apt-get install libexpat-dev wget http://downloads.sourceforge.net/project/rnv/Sources/1.7.10/rnv-1.7.10.zip unzip rnv-1.7.10.zip cd rnv-1.7.10 ./configure make make install
In view of this, I don't think rnv should be in the TEI repos at all, unless it can be done in such a way as to provide the right build for the host architecture.
I now have a more convenient setup for creating and testing Jinks builds. This is how it works:
- There's a sort of "seed" vm called PreJenkins in /home/mholmes/VirtualBox VMs/
- That's a fully-updated vanilla install of Precise server.
- In my tei/jenkins directory, there's a script called vboxmanage_Jenkins2012A.sh. When you run that script, it clones the vanilla server to create a new VM called Jenkins2012A. It also configures that VM so that you can see its port 8080 (Jenkins) on the host's 7070, and so that you can ssh into it on port 2012.
- After running the above script, you start the newly-created VM. You log in as hcmc, and sudo su, then you run a script you'll find there called make_jenkins.sh (also in my local tei/jenkins directory on my host).
- The make_jenkins.sh script first scps a copy of the jenkins_builder_script_2012.sh from the host into the hcmc home directory (pulling this in, rather than having it there in the seed, enables me to tweak the script easily while working on it). It runs the script.
- At this point, you're seeing what the ordinary user of the jenkins build script would see.
- Once the build is complete, and you exit from the build script, make_jenkins.sh scps a copy of our Oxygen license from the host into the right location, so that Oxygen is registered.
- Now Jenkins should be running on the new machine. You can now run a script on the host called connect_to_Jenkins2012A.sh, which will send Firefox to the right port, and ssh into the machine. The connection to the machine is done like this:
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -l hcmc -p 2012 localhostwhich precludes checking of the machine's key, or storage of its key; this avoids the problem where every time you clone the pre-seed to create a new VM, it has a different key, and the host complains that the key in known_hosts has changed.
- Then you wait and watch to see if Jenkins builds the jobs OK.
This is what remains to be done:
- Fix the rnv problem. It's installed now from the TEI packages, and is clearly there, but make and bash are unable to find it:
rnv -bash: /usr/bin/rnv: No such file or directoryVery weird indeed. There are executable copies in /usr/bin and in /usr/bin/X11, just like on my local machine, where they work fine.
- Figure out what to do about job configs which include mine and SR's email addresses. We should probably XSTL the config.xml files during the setup process to replace SR's email with the user's own, which we can ask for.
- Solve the problem whereby P5-Test builds and fails before Stylesheets has built for the first time. Stylesheets needs to build once successfully before the P5 jobs can build; thereafter, they're independent. There must be a way to force Jenkins to build Stylesheets before P5-Test the first time out.
- List the error messages and warnings that show up ONLY on the first checkout/build of the jobs. There are lots of these in OxGarage, and possibly elsewhere. These need to be put into the hudson-log-parse-rules file so that a first-time user of the script is not worried by a lot of errors that will never show up again, and aren't relevant.
- Document and publish the script, by updating the page on the TEI wiki.
- Get a real VM to replace our current teijenkins, and when it's working, repoint the domain and bring the old one down.
This took all day. I first attempted to set the home dir for mholmes on the second disk drive, but when I did that, I ended up with no bash profile. I ended up leaving it at /home/mholmes, but symlinking to specific folders on the second drive instead.
To move VirtualBox vms, I first deleted all snapshots, then moved the disks over (only the disks). Then I created new VMs for the HDs. All working normally, after lots of Windows updates and a bit of tweaking on the Win7 machine (which by default tried to attach the old IDE disk image to a SATA disk controller).
Produce a sorted list of recently changed files by running this:
find . -type f -printf '%TY-%Tm-%Td %TT %p\n' | sort