hudson revisited

But since I've already done up nullDC, let's see how getting it set up goes. I'll compare in a follow-on post.

1. The hudson website says the best configuration on windows is to install tomcat and configure it to load the hudson .war. I have no idea what that means. I think tomcat serves up java modules as objects that return web or data requests, possibly in combination with apache httpd. Turns out, you don't need apache httpd. On win32 (xp) last time I set this up, I had no trouble configuring xampp and installing tomcat from an extra xampp package. But on Windows 7 x64, xampp was busted from the installer. There's an x86/x64 windows service installer for tomcat 7.0. Let's do that, since it's the newest. Tomcat requires a 64 bit jre, which I have. It also wants to use port 8080, which is fine.
2. Download the latest hudson .war and try to follow the instructions. There's no %TOMCAT_HOME% environment variable configured with the windows service installer for tomcat 7. Browsing to http://myhost/hudson doesn't show anything. Go to restart the windows service. Also try http://myhost:8080/hudson and http://myhost:8080/. Nothing. Try to use the tomcat manager, and get 403 access denied. Change my manager user and pass to something retarded simple and impossible to typo. Nothing. Time to uninstall and deselect the manager, methinks. Apache Tomcat doesn't say it's an apache publisher product in the remove programs control panel, and it leaves a zombie instance of its uninstall registry when it's done. I notice that a bunch of hudson files were created in the directory as it uninstalls.
3. Reinstall of tomcat shows the web manager is unusable in its default install state. Blah. Try escalating the user it runs as to an admin, no luck. Everything useful about the page results in a 403 error. Uninstall and try tomcat 6.0 just in case? Confirm that hudson is extracted all over the webapp/hudson directory tho. Find this web post, 7.0 is bugged, but they claim as designed. Apply the single-character config fix, and hudson says it's loading.
4. Read the docs, and start by setting environmnet variable to move hudson's root directory HUDSON_HOME to different disc. Restart tomcat service.
5. Find the mercurial plugin but not sure how to install it. Ah, the docs say the manage page has a plugins view. That didn't load before, but does now. Also warns about no utf-8 encoding. Reconfigure and restart tomcat, and go back to http://myhost:8080/hudson/pluginManager/
6. Hey! There's updates to plugins I already have installed. That's cool. Holy crap, there's so many plugins in the list that it's hard to see what other cool stuff I can do. But I see copying artifacts from other Hudson instances (ala cruise fetchartifact xml config lines), and guess there's plenty of configuring ahead. It would be nice to repackage hudson on windows to install into tomcat, or offer a 'make hudson installer package from this configuration' link.
7. Poke around, and find the email configuration options. Can't authorize against my yahoo smtp service because hudson gui doesn't allow me to set username and password to auth with, nor the smtp port. There's a way to configure it in the config file apparently. Leave this alone for another time. ZOMG, the mercurial plugin didn't install. The install button is tiny, and way at the bottom of the page, so I hadn't found and hit it. Needs some stylesheet love to fold up all the damn sections; under google chrome, it seems like some things fold, and some don't unfold. [2010/07/10] Found the advanced button in the hudson configuration that lets user set advanced details like auth and port.
   
8. Blargh. Skipped email config and went to bed. Woke up, and configured build steps for SDL, copying the work from cruise. Build steps fail because sh is not on path. Really? Can it not tell that I am running windows and it needs to run command? Fah. It could come bundled with msys/mingw, with a nice nullsoft installer. Or because it's windows, it could just switch from sh to cmd.
   
9. It turns out, there's a built-in windows batch command builder step I should have used instead. Hudson doesn't currently figure out to hide sh commands on windows. It would be cool if it came with sh.exe or removed it from the dropdown. Creating all-new steps to use batch commands fails on unquoted strings with spaces, and succeeds finally. Artifacts are downloadable individually or all in a zip. The zip includes the full path to the artifact, instead of tidying the paths flat similar to cruise. Different, not bad.
10. Notice the success icon is a blue ball. Should be green, methinks. Someone already made a plugin to fix that. Install that and something else that catches my eye, and get tired of restarting tomcat instead of restarting hudson within tomcat. Finally go reconfigure tomcat users, which the windows installer for 7.0 doesn't correctly configure - it added the manager role, but really, you need manager-gui and a couple other roles. Restart tomcat, and finally get into the web manager. Feature request - Hudson to restart itself if it knew it was within tomcat and had its own user.
11. Green balls plugin sort of works, sort of not. Chrome has cached the image, so in pages viewed before, it shows up as blue. But if you open the image elsewhere, it shows up green.
12. Include folder as artifact doesn't work the first way I configured it. web shows the right way to get the entire contents is to use directory/file wildcards like path/to/folder/**/*. Except, then the UI forces you to browse the entire artifact dir. What I want to see is some libs, and an include directory. I guess I could bundle files myself, or put them into a published structure and artifact that.
13. While waiting, discover that cctray input from hudson looks like this. Wonder why work goes through the trouble of making their own cctray, when they could just format the build output correctly. That would be minus one app to make, less code in the tree.
14. Try the msbuild builder, which is currently invoked from the command line. Maybe it's awesome. No, not really. it allows for the user to configure specific msbuild to run, but nothing that the command line can't handle. Doesn't have the awesome edit text box bottom sizer that the cmd text has, so I can't read all the args. Scratch that change to config.
15. Clone the SDL project to make one for Winpcap. But hudson's getting a second copy of the same code to build everything. annoying! Now I have extra copies of the source repo, again. These can run from the same code base, and can run at the same time (in parallel), because the tasks do not intersect.
16. Not being able to change the cwd for a task to run is starting to drag. Reconfigure so include file batch runs correctly in winpcap.
17. Trying to figure out how parallel builds can go off before the dependent build. This post recommends Join or Locks and Latches plugins. Docs for join are there, I go read Locks. Bah. Locks looks abandoned and incomplete, whereas join was modified recently and has pretty pictures of configuring. Looks like it will require some noop stages. or some dependency configuring.
18. Make nullDC trigger on SDL or winpcap rebuild complete, instead of on SCM changes. These two build on source control rev changes, so if either changes, we rebuild. SDL currently runs from DEEPWATER, but that's sub-par. It should run from my local SDL clone. winpcap is part of SHARKBAIT, which DEEPWATER was cloned from. If source in SHARKBAIT changes, we definitely want to rebuild winpcap and nullDC. So I think this is suitable. But how do I get the artifacts which I did easily with cruise? Oh hey look. There's a fetch artifact plugin. Awesome.
19. Yay. The steps are drag-and-drop in the web ui. That's nice, because I defined them out of order and now they are in order. SDL headers and libs go where we want. Now to figure out the best way to get winpcap output where it should end up.
20. A bit more artifact and fetch artifact configuring, and headers, libs show up, and nullDC builds. Add remaining files from WorkDir to the artifacts it publishes, and it's like I have a nearly-ready-to-redistribute zip file!

So there we go. Most of the work from setting up cruise, I was able to replicate simply in Hudson.

The benefits now that I'd like to set up are a linux port using other instances of slaved hudson on virtual machines, and going back to build from clean source mercurial repo (SHARKBAIT) instead of the one I had to pollute to get it to work under the cruise crippleware free license (DEEPWATER).

It looks like Hudson has all the parts I need to make a distributed build that can fork and join status across multiple instances, but it needs some installer repackaging before I could deploy it at work. Some kind of uber installer that drops in tomcat, hudson, reconfigures each, and installs the base plugins I want to use.

If hudson could already be packaged for easy windows installs, and prompt the user on install for the default plugins to activate on windows, I'd say it'd be pretty lively and easy to deploy.

I prefer this to the cripple ware cruise, but more about that later.