Using AppEngine (and GWT) in a CI environment

These days, I don’t much like being ahead of, behind, askance of, or otherwise deviated from the curve. It used to fit well with my “blogging as a nervous tic” phase of early 2008 when I would apparently post about every single compiler error I encountered and how it fit in with the grand scheme of things. But now, I prefer my technology much more Google-able. Does wonders for my productivity. In light of that, this post will fall into the category of “interesting to people searching for a solution to a specific problem.”

And so it was that I went and tried to set up a CI process for our brand spankin’ new AppEngine app. (Note to you fetishists: I didn’t mean that “spankin’” part literally. I don’t pretend to understand the euphemisms I use; I just use ‘em.)

It’s essentially the same process we’re using for our main BookedIN application, which also runs on AppEngine:

Compile and test configuration
In this configuration, we just compile the app and run the unit tests.

Run stable UI tests
This configuration performs the following steps:

GWT compile the application. I.e. do all the magic that converts Java into JavaScript
Launch GWT hosted mode
Launch the UI tests

The first two steps are performed with Ant. The last is in Rake because the UI tests are done in Capybara. We launch hosted mode first because it’s orders of magnitude faster to run UI tests against a local hosted mode version than it is against a deployed version, especially because we clear out the datastore before each scenario.

Let me add some foreshadowing here. In order to launch hosted mode, we use the following Ant target:

<target name="devmode" depends="" description="Run development mode"> 



















Note that this is running dev mode using the AppEngine agent. So it’s mimicking AppEngine behind the scenes…somehow. <java fork="true" classname="com.google.gwt.dev.DevMode" dir="${basedir}/war" spawn="true"> <classpath> <pathelement location="src" /> <path refid="project.class.path" /> <path refid="tools.class.path" /> </classpath> <jvmarg value="-Xmx512M" /> <jvmarg value="-javaagent:${appengine.folder}/lib/agent/appengine-agent.jar" /> <jvmarg value="-Duser.dir=${basedir}/WAR" /> <arg line="-war" /> <arg value="${basedir}/war" /> <arg line="-logLevel" /> <arg value="INFO" /> <arg value="-server" /> <arg value="com.google.appengine.tools.development.gwt.AppEngineLauncher" /> <arg value="net.bookedin.bam.BAM" /> </java> 20: </target>

The key to this target is where it says: spawn=”true”. This allows TeamCity to launch DevMode, then continue about its business. I.e. it doesn’t wait until DevMode is finished.

Run flaky UI tests
We have this one in here just because I got tired of seeing three or four failing tests every single time and 95% of the time, it was because of a PayPal sandbox issue. Having these “sometimes they work, sometimes they don’t” tests in a separate project means I can take the ones that fail in the previous configuration that much more seriously. All this configuration does is run UI tests that are tagged as @flaky.

Kill DevMode
We have this as a separate configuration because we want it to run always. If it’s set up as a separate step in one of the previous configurations, TeamCity won’t run it if any of the UI tests fail. As a separate configuration, it can be set to run after any build of “Run flaky UI tests” regardless of whether that build succeeded or failed.

The new app…

…is in AppEngine also but not in GWT (for reasons outlined elsewhere). Which I thought meant this would be easier. Alack, this is not true.

There is a corresponding “dev mode” in AppEngine. But it can’t be launched and then forgotten like it can in GWT. Here’s the target we originally had for it:

<target name="runserver" description="Starts the development server.">
    <java classname="com.google.appengine.tools.development.DevAppServerMain"
          classpath="${appengine.tools.classpath}"
          fork="true" failonerror="true">
      <jvmarg value="-javaagent:${appengine.folder}/lib/agent/appengine-agent.jar"/>
      <arg value="--address=localhost"/>
      <arg value="--port=8080"/>
      <arg value="war"/>
    </java>
</target>

Same idea as the previous one but with a different class name. And unfortunately, you can’t add spawn=”true” to this one. Something in DevAppServerMain doesn’t like spawn=”true” and complains. So if you run this target, it sits there and waits until you forcibly stop the server, either with Ctrl-C or something like the following (in another command window):

<target name="stopserver">
    <property environment="env"/>
    <exec executable="${env.JAVA_HOME}/bin/jps" output="pid.out.file"/>
    <loadfile srcfile="pid.out.file" property="pid.out">
      <filterchain>
        <linecontains>
          <contains value="DevMode"/>
        </linecontains>
        <tokenfilter>
            <deletecharacters chars="DevMode"/>
            <trim/>
            <ignoreblank/>
        </tokenfilter>
          <tailfilter lines="1" />
      </filterchain>
    </loadfile>
  
    <echo>Killing appengine java process with PID - "${pid.out}"</echo>
  
      <exec executable="taskkill">
          <arg value="/f" />
          <arg value="/fi"/>
          <arg value='"PID eq ${pid.out}"'/>
      </exec>
  
    <delete file="pid.out.file"/>
</target>

Side note: Both of these were modified from a comment thread on an open issue with AppEngine, whereby the default “runserver” command leaves a stray java.exe process running after you kill it.

This method works pretty well for local development. But won’t for a CI configuration that’s relying on the “runserver” target to give up control so it can “run UI tests”.

“No matter,” says I, “surely someone else has discovered just how much money and time is saved through the practices of UI testing and CI and is doing the same on an AppEngine application.”

If you just chuckled to yourself at my apparent naïveté, then same on you! I remain convinced that such a person does exist. He or she just doesn’t like to brag is all…

A post to the AppEngine Google Group led to my eventual solution which came in the usual manner: it occurred to me during the process of typing out my question and/or one of my responses.

The basis for the solution is: the process works for GWT DevMode with an AppEngine agent; so run the app in GWT DevMode with an AppEngine agent.

Setting up a minimal GWT environment for the app was simple:

Add gwt-dev.jar to my classpath (just for the purpose of testing; it’s not included when we deploy the app)
Create a stub .gwt.xml file
Use the same Ant target above to launch the app in DevMode

The stub .gwt.xml file is an almost empty XML file:

<?xml version="1.0" encoding="UTF-8"?>
<module rename-to="gunton">
</module>

DevMode complains if this file is missing. The location is defined in the final argument of the <java> task in the Ant target.

That’s it. We can now launch our AppEngine app in a CI environment and it won’t wait for the user to forcibly close dev mode. We can use a similar “kill dev mode” target to stop it when the UI tests are done. Our one remaining issue is that “kill dev mode” target. At any given time, we may have up to two DevModes running on the CI server: one for the GWT app and one for the AppEngine app. When we go to kill them, we can’t distinguish one from the other…

…which leads to one final footnote. We’re using Windows. If you are using Linux on your CI server, much of this would be moot, as was suggested in the thread. From my understanding, you can more easily run a process in the background, in which case, you can go with the original “runserver” target. Which also makes it easier to figure out which process to kill when the UI tests have finished.

Kyle the PID off.