Playframework 2.1-RC4: running tests on dev@cloud using sbt

Question

I'm trying to set up a Jenkins task that regularly checks out a play 2.1-rc4 project and executes all the tasks that would be run normally when you do "play test."

Our Jenkins install is hosted on cloudbees (dev@cloud).

I installed the Jenkins sbt plugin and configured it to point to a valid copy of sbt(.11.? I think). In my build, I run a sbt test with the current directory set to the root of the play project.

My understanding was that sbt would update itself to .12 because of build.properties files under projects, download and installing the play sbt plugin, resolve all dependencies and then execute the tests.

However, sbt fails to resolve the play sbt plugin:

Note: Some unresolved dependencies have extra attributes. Check that these dependencies exist with the requested attributes.

warn play:sbt-plugin:2.1-RC4 (sbtVersion=0.11.3, scalaVersion=2.9.1)

The scala and sbt version attributes seem wrong (play 2.1 uses sbt .12)...I've been trying to piece together how play, sbt and Jenkins play together and have several questions:

1. Will sbt .11 update itself on the fly just for the current build if build.properties calls for a newer version?
2. What functionality does the play sbt plugin (loaded in plugins.sbt) add to sbt? Could I replace it with "pure" sbt?
3. What are sbt.boot.properties and play's framework/sbt/boot directory for? When play runs sbt, it sets -Dsbt.boot.properties to a boot properties file in the framework/sbt directory. This file defines some repositories and the scala version among other thing. In this sbt directory, there's a sub-directory called "boot". In it,there's a directory tree including a ton of jars. What is all this boot stuff? It doesn't seem to be covered in the main sbt documentation.. My guess is that it has to do with loading sbt itself (resolving any necessary deps for sbt. Etc.)
4. Does anyone have dev@cloud executing play 2.1-rc4 tests correctly? If so, how did you set it up?

Answer 1

We don't have 0.12 on the slaves yet, however what I (and others) do is use https://github.com/paulp/sbt-extras to bootstrap sbt. All you need to do is copy the sbt launch script to the root of your project, and then call ./sbt in jenkins.

The play sbt plugin is purely for deploying to run@cloud, it is not needed if all you are doing is testing.

Answer 2

I ended up taking a slightly different approach.

I was able to execute most play commands just fine with the older version of SBT on the cloudbees jenkins slaves. Uploading a newer version to scratch space and using that would probably speed things up, but sbt .11 bootstraps .12.2 fine.

Ridiculously Simple Two-Step Walkthrough:

1. Configure SBT in jenkins config
2. Add "Build using sbt" step to the build
   • JVM Flags: -Xms512M -Xmx1536M -Xss1M -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=384M
   • sbt flags: -Dsbt.log.noformat=true -Dconfig.file=ifnecessary
   • actions: "project PROJECT_NAME" clean compile test (or whatever)

Potential Pitfalls/Notes:

• In some cases, all the bootstrapping seems to create a ".sbt" directory in the root of my workspace. Sbt then assumes this is the project directory and chooses it over play's project directory. (It throws a warning about using old directory layout, but doesn't ignore it.) "project blah" (in quotes) ensures that sbt uses the right project config
• JVM flags: I grabbed these from one of the play build scripts... I have no idea which ones can be ignored
• sbt flags: You do seem to be able to pass play environment vars like config.file here or in jvm flags section.
• Using the default version of sbt installed on the cloudbees slaves, there seems to be a bunch of bootstrapping going on at build time. I imagine installing the most current version of sbt to your scratch space and using that would trim build times down.