So, I thought I was doing pretty well, getting svn working on the mac, installing cruisecontrol for my continuous integration, even getting SCPlugin working with unsigned certificates. Then I tried to run my ant build, and ended up having all sorts of problems getting my mac debug player to run. Some investigating and help from the ANT folks later, and I have a solution
So, when I ran my ant build, all went well until the runTest target executed (or at least tried to execute). I got the following build error:
Execute failed: java.io.IOException: debugPlayerMac.app cannot execute
You see the problem is that on a mac, the standalone player (like other applications on the Mac) is actually a folder containing all sorts of cleverness inside. Ant doesn’t know how to execute a folder, so I was a bit stuck. Until, after lots of digging, I found the answer in an old osflash mailing list archive. Basically I have to use the ‘open’ command to launch the app – something like this:
<exec executable="open">
<arg line="${pathToFlashPlayer}"/>
<arg line="${pathToSWFToPlay}"/>
</exec>
I tried this, and it worked nicely. The problem is that my ant build needs to wait until the test harness runs and closes the player before reading the log and parsing the results for cruisecontrol to consume. In the ant script above, the open command only stalls the ant script until it has finished doing its opening magic, so ant gets upset as the test results haven’t been written yet. I slept on this, then couldn’t think of an answer so I sent an email to the ant users mailing list. Mere minutes later I got a reply that helped me work out how to crack this.
Basically, ant has the ability to run two threads, and move on when they are both complete. So in one thread we launch the player, and in another thread we first wait for the file to be available, then we do a check to see if it contains what we want (I am testing against the flag -----------------TESTRUNNEROUTPUTENDS---------------- which I used in my result printer). It worked like a charm:
<target name="runTest" description="runs the test harness" depends="compileTest">
<parallel>
<exec executable="open" spawn="no">
<arg line="${debugPlayer}" />
<arg line="'${testHarness.swf}'"/>
</exec>
<sequential>
<waitfor>
<available file="${flashlog.location}"/>
</waitfor>
<waitfor>
<isfileselected file="${flashlog.location}">
<contains text="-----------------TESTRUNNEROUTPUTENDS----------------"/>
</isfileselected>
</waitfor>
</sequential>
</parallel>
</target>
The last step to making this properly cross platform for cruisecontrol was to have the right <exec> command called depending on the OS. Fortunately there is an os attribute you can specify on <exec> and the task will only run if the os matches the platform you are running the task on. A few minutes later, I had my amended runTest target:
<target name="runTest" description="runs the test harness" depends="compileTest">
<parallel>
<exec executable="${debugPlayerWin}" spawn="no" os="Windows XP">
<arg line="'${testHarness.swf}'"/>
</exec>
<exec executable="open" spawn="no" os="Mac OS X">
<arg line="${debugPlayerMac}" />
<arg line="'${testHarness.swf}'"/>
</exec>
<sequential>
<waitfor>
<available file="${flashlog.location}"/>
</waitfor>
<waitfor>
<isfileselected file="${flashlog.location}">
<contains text="-----------------TESTRUNNEROUTPUTENDS----------------"/>
</isfileselected>
</waitfor>
</sequential>
</parallel>
</target>
I’m planning to post my completed project build script and step through it in more detail than I did previously. I’ve updated it quite a lot in the last year, and so far, I think its a lot neater. Before I do that, I’m going to post about my removing the python dependency from my continuous integration process.