<plugin>
    <executions>
        <execution>
            <goals><goal>javascript-test</goal></goals>
        </execution>
    </executions>
    <groupId>com.carbonfive.javascript-test</groupId>
    <artifactId>javascript-test-maven-plugin</artifactId>
    <version>1.0-beta1</version>
    <configuration>
        <includes>
            <include>src/test/javascript/suite*.html</include>
        </includes>
    </configuration>
</plugin>

You will probably also need to add Carbon Five’s public repository so that maven will know where to grab the plugin:

<pluginRepositories>
    <pluginRepository>
        <id>c5-public-repository</id>
        <name>Carbon Five Public Repository</name>
        <url>http://mvn.carbonfive.com/public</url>
    </pluginRepository>
</pluginRepositories>

The <configuration> section contains standard maven <include> and <exclude> tags to allow you to specify any Screw.Unit test suite html files you would like to include in your build.

Now when maven executes its test phase, it will include your javascript tests as well. Any test that fails will halt the build. When the test phase is complete the target directory will contain a ‘screw-unit’ directory that contains the test reports. There will be two files for every file included in the test execution The first is an XML file named TEST-dir1.dir2.dir3.filename.html.xml that contains the test results for that file in a reasonable approximation of JUnit’s xml format. The other file will be named dir1.dir2.dir3.filename.html and will contain a sort of snapshot of the test suite’s html at the time the tests completed (the javascript will be removed and the css will be baked in).

Like Blue Ridge, the javascript-test-maven-plugin relies on the excellent env.js project and the less-excellent Rhino project to emulate a browser in Java. Unfortunately this combination creates the possibility of discrepancies between the browser and build results, and the probability of relatively slow test execution. To keep the simulation as realistic as possible, javascript-test-maven-plugin recreates the test environment for each Screw.Unit html file, so the more tests you can cram into a single file the faster your builds will run.

There are a few directions for future work. I’d like for the plugin to handle other browser-based javascript testing frameworks. Screw.Unit is popular, but seems suboptimal in many respects. The only limiting factor here is the plugin’s ability to interpret the results. If env.js could run in javascript interpreters other than Rhino, I’d like to give the the plugin the capability to fork out to spidermonkey for better compatibility and performance. Modifying the plugin would be relatively easy, but env.js appears to have some significant dependencies on Java.

Check it out if you have a need for this kind of thing and let us know if you have any problems or suggestions.

Engine Yard will eventually allow us to push a branch to our cloud environment from git (ie “git push engineyard master”) but until that is available the best option seems to be to trigger a github post receive hook directly.

To that end I rewrote an existing script to trigger post receive hooks as a rake task; http://gist.github.com/271433

require 'rubygems'
require 'json'
begin
  require 'restclient'
rescue Exception
end

namespace :ey do

  # Based on http://gist.github.com/114954
  # Discussed at https://cloud-support.engineyard.com/discussions/questions/83-deploying-to-solo-instance-from-automated-build
  desc 'Trigger a GitHub Post Receive Hook to deploy the app'
  task :deploy do
    post_receive_hook 'preview'
  end

  desc 'Trigger a GitHub Post Receive Hook to deploy and migrate the app'
  task :deploy_and_migrate do
    post_receive_hook 'preview', true
  end

  def post_receive_hook(envname, migrate=false)
    token = `git config --get cloud.token`.chomp

    if token.empty?
      token = ENV['cloud.token']
      end

    if token.empty?
      puts <<-EOT
The cloud token is not set.
To store the token, use:
$ git config --add cloud.token SOMETOKEN
or set the cloud.token environment variable.
EOT
      exit 2
    end

    commit = `git rev-parse HEAD`.chomp
    payload = {
        "commits" => [{"id" => commit, "message"=>"[deploy #{envname}#{migrate ? ' migrate' : ''}]"}],
        "ref" => "refs/heads/master",
        }

    puts "Triggering a deploy for #{commit} on #{envname}"
    begin
      response = RestClient.post("https://cloud.engineyard.com/github/#{token}",
                                 :payload => payload.to_json)
      puts "Successfully triggered the deploy"
    rescue RestClient::RequestFailed => e
      puts "Could not deploy your changes"
      puts e.response.code
      puts e.response.body
      exit 1
    end
  end
end

In setting this up I discovered a couple of potential stumbling points:

• The environment must have been deployed via the EY dashboard before you will be able to trigger a deploy using the post receive hook API.
• The branch specified in the API call (and therefore the git branch you should be working in if running that rake task) must match the branch deployed using the EY dashboard.
• If you make an API call to deploy the ‘master’ branch EY will attempt to deploy branch ‘HEAD’.
• If the branch specified in the API call does not match the branch specified on the dashboard the API will report success but not redeploy the environment.

The folks at Engine Yard are working to correct some of those issues and now I’ve got a project which automatically pushes changes to the cloud every time our tests cycle.