cookies and code

Here’s the thing about proof-of-concept projects, they always get the high risk technology questions out of the way, but they never manage to expose the stupid gotchas that are coming down the line when you go to make them into a reality. Case in point, unit testing in Flex and continuous integration. In my last post, I spoke about how I got flex-mojos, ant, fluint, and Hudson all playing nice together. Please preface the following with the fact that I’m a terrible server admin, so there may be work arounds for the roadblocks I ran into, I’m just not aware of them.

So when our team went to deploy the PoC, we decided to use Windows. Our hope was that with the lack of headless support in AIR, Windows would provide us access to a windowing system even when a user isn’t authenticated thanks to the dreaded LocalSystem account. As expected, I was able to get Hudson up and running and the AIR test runner was working without issue while running as LocalSystem. I then needed to integrate a series of CI builds which we put together to automatically release our components. All of sudden, I had the need for user specific settings to interact with putty, plink, and SVN, then LocalSystem failed me. I setup a special user to run the service hosting Hudson and placed that user into the Administrator group to start; I figured once I had it working again, I’d restrict its rights … <crickets chirping>. So when I had finally gotten the automatic release builds working with the new user, I re-ran one of my previous CI builds only to find that the build would hang when the AIR runner for Fluint was executed. After hours of pouring over a solution (I even tried this registry hack for the service with no success), I decided that Windows just wasn’t going to work.

I decided to give Linux a shot and I have to say I had much better results; I chose Ubuntu for my PoC due to its simplicity for guys like me. As a nice plus, all of the SSH/SVN woes I experienced disappeared because I had a native SSH client and integration was just easy. I still had the issue however of needing to run AIR in a truly headless mode. I started with some tips I found on the Fluint mailing list and was able to get Xvfb up and running as a service. Integration with the Fluint Ant Task didn’t pan out easily though, so I again looked for another solution. I did some digging and as it turns out a lot of the Java/Swing folks had to solve the same problems we’re having to solve now before Java gained the ability to run Swing apps headlessly. I found this post on xvfb-run and it did the trick. In fact it worked out so well, that I went ahead and integrated it into the Fluint Ant task as an option. Effectively I just had it execute the AIR application with the “-a” flag so sysadmins who are picky about how xvfb-run is used may not like the lack of granularity I’ve built in, but it’s working for us. I know that FlexUnit has a similar issue since the Flash Player can’t be run in a headless-mode either, so this may be a good feature to add to the FlexUnit Ant task eventually too. On a side note, my changes to Fluint are being reviewed right now and it looks like I may get my branch merged into the next release fairly soon for anyone who is interested in finding binaries.

We’re still working to deploy on a different Linux distro at the moment, but I think we’ve finally managed to mitigate the risk of running a Flex build on a CI server for the different variations we’ve thrown together. If you see another post from me really soon, you’ll know the edge of the PoC sword got me again … stupid sneaky sword.

• Using Xvnc to create headless CI builds for Flex and AIR applications
• Thanks for the invitation KSC
• New FlexUnit … what?
• Fluint 1.1.1 ready to be released
• Fluint 1.1.0 Released!