Are you interested in free and powerful Continuous Integration for your applications based on Play2 Framework ? Yes, so just try Travis CI<http://travis-ci.org/> !
Some more notes (a bit out of post's scope, sorry I can't resist to drop some more ideas in the air ;-)
- I'm pretty sure it will be easy to setup testing of Play2 Modules on Travis as well, but I did not work on that point so far. - For people interested about how to build Play20 framework itself on Travis, you can have a look on https://github.com/gildegoma/Play20/tree/pr-integrate-travis-ci. So far I have not opened any pull request on master project (I think that according to current guidelines of Play20 project such kind of change would not be evaluated for now). Even if main project is tested on cloudbees, I think it could be a nice improvement for the general fork/pull-request community process, if PRs are publicly tested by Travis, before their integration.
On Saturday, 14 April 2012 18:42:08 UTC+2, gildegoma wrote:
> Hi Play2 Developers !
> Are you interested in free and powerful Continuous Integration for your > applications based on Play2 Framework ? Yes, so just try Travis CI<http://travis-ci.org/> > !
> Some more notes (a bit out of post's scope, sorry I can't resist to drop > some more ideas in the air ;-)
> - I'm pretty sure it will be easy to setup testing of Play2 Modules on > Travis as well, but I did not work on that point so far. > - For people interested about how to build Play20 framework itself on > Travis, you can have a look on > https://github.com/gildegoma/Play20/tree/pr-integrate-travis-ci. So > far I have not opened any pull request on master project (I think that > according to current guidelines of Play20 project such kind of change would > not be evaluated for now). Even if main project is tested on cloudbees, I > think it could be a nice improvement for the general fork/pull-request > community process, if PRs are publicly tested by Travis, before their > integration.
CloudBees have a service in early beta called BuildHive. It provides a one-click integration with github to set up jobs from repos. You do not need a CloudBees account to use it, just oauth with github.
For play2 it needs no extra files at all to build.
>> Some more notes (a bit out of post's scope, sorry I can't resist to drop >> some more ideas in the air ;-)
>> I'm pretty sure it will be easy to setup testing of Play2 Modules on >> Travis as well, but I did not work on that point so far. >> For people interested about how to build Play20 framework itself on >> Travis, you can have a look >> on https://github.com/gildegoma/Play20/tree/pr-integrate-travis-ci. So far I >> have not opened any pull request on master project (I think that according >> to current guidelines of Play20 project such kind of change would not be >> evaluated for now). Even if main project is tested on cloudbees, I think it >> could be a nice improvement for the general fork/pull-request community >> process, if PRs are publicly tested by Travis, before their integration.
> To post to this group, send email to play-framework@googlegroups.com. > To unsubscribe from this group, send email to > play-framework+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/play-framework?hl=en.
I noticed a few more things after sending my first response, hence these updates:
I found where you can configure:
- branches to build :-) - the shell script to run for 'unkown template' project :-) but if a template has been found (e.g. 'sbt'), shell script cannot be redefined... :-/
*SORRY: I mixed myself and my 'second' answer has been posted while I actually failed to send first reponse... which I include now. Sorry, I think I better have to read Google Groups Help, but it's time to sleep now :-/*
Thank you for the announcement. BuildHive/GitHub integration is smooth, quite similar as Travis/GitHub. Nice concurrence in perspective!
I actually tested 3 Projects (1 Play2 and 2 pure Scala) with following results:
- *Build failed for my Play2 Sample App:* - https://buildhive.cloudbees.com/job/gildegoma/job/travis-ci-ScalaOnPl... - there was a dependency download problem that interrupted the build, I think this should not happen (again/always) - 'sbt' template *is auto-detected *=> test run with 'sbt test' command, which is not enough to run 'play test' action (what is actually the goal of my original post) - is there (alreay) a way to override/force the builder template/script in BuildHive ? - Wrong builder for pure Scala/SBT projects (like Salat or Akka): - https://buildhive.cloudbees.com/job/gildegoma/job/salat/1/console - https://buildhive.cloudbees.com/job/gildegoma/job/akka/1/console - 'sbt' template* should be auto-detected*, but it's not the case (/bin/sh -xe /tmp/hudson6904688027096127531.sh, instead sbt test)
Configuration auto-detection are nice features, but anyway it is a must to let user override/reconfigure default settings... Travis-CI is already quite mature, BuildHive can for sure take some good influences from it :-).
on https://buildhive.cloudbees.com/template/, I see that the list of build templates is already quite nice (sbt, maven, gradle, bundler/rake, ...). I would recommend you to setup a Play2 template, and then BuildHive wins one point in the race with Travis ;-)
I am looking forward a new discussion thread about BuildHive upcoming features !
Thank you very much for the feedback! Yeah, missing 'x' permission is common pitfall when doing copy-paste of shell script content. Actually, I created this extra script 'travis/setup' in a Don't Repeat Yourself and clean code spirit, but it's not straightforward and maybe error-prone...
Let me know which variant you find better... My current feeling: +1 for this new variant (everything in .travis.yml).
*Precision:* Comments from Ivan Meredith show how Play projects can auto-download the Play dependency via Maven/Ivy/sbt. This is also quite nice way to do it, and it works fine either on BuildHive/Jenkins or Travis. My idea here was merely to save download time/traffic, with only a single file to download (play-2.0.zip release), which is also matches with Installation Guide of Play Framework (see http://www.playframework.org/documentation/2.0/Installing)
Regards, Gilles
Le lundi 23 avril 2012 22:36:41 UTC+2, Matthieu a écrit :
> I just had to do a 'chmod +x travis/setup' in order to avoid an error on > Travis and then it worked like a charm.
> Matthieu
> On Saturday, 14 April 2012 18:42:08 UTC+2, gildegoma wrote:
>> Hi Play2 Developers !
>> Are you interested in free and powerful Continuous Integration for your >> applications based on Play2 Framework ? Yes, so just try Travis CI<http://travis-ci.org/>
>> !
>> Some more notes (a bit out of post's scope, sorry I can't resist to drop >> some more ideas in the air ;-)
>> - I'm pretty sure it will be easy to setup testing of Play2 Modules >> on Travis as well, but I did not work on that point so far. >> - For people interested about how to build Play20 framework itself on >> Travis, you can have a look on >> https://github.com/gildegoma/Play20/tree/pr-integrate-travis-ci. So >> far I have not opened any pull request on master project (I think that >> according to current guidelines of Play20 project such kind of change would >> not be evaluated for now). Even if main project is tested on cloudbees, I >> think it could be a nice improvement for the general fork/pull-request >> community process, if PRs are publicly tested by Travis, before their >> integration.
> SORRY: I mixed myself and my 'second' answer has been posted while I > actually failed to send first reponse... which I include now. Sorry, I think > I better have to read Google Groups Help, but it's time to sleep now :-/
> Thank you for the announcement. BuildHive/GitHub integration is smooth, > quite similar as Travis/GitHub. Nice concurrence in perspective!
> I actually tested 3 Projects (1 Play2 and 2 pure Scala) with following > results:
> Build failed for my Play2 Sample App:
> https://buildhive.cloudbees.com/job/gildegoma/job/travis-ci-ScalaOnPl... > there was a dependency download problem that interrupted the build, I think > this should not happen (again/always) > 'sbt' template is auto-detected => test run with 'sbt test' command, which > is not enough to run 'play test' action (what is actually the goal of my > original post) > is there (alreay) a way to override/force the builder template/script in > BuildHive ?
> Wrong builder for pure Scala/SBT projects (like Salat or Akka):
> Configuration auto-detection are nice features, but anyway it is a must to > let user override/reconfigure default settings... Travis-CI is already quite > mature, BuildHive can for sure take some good influences from it :-).
> on https://buildhive.cloudbees.com/template/, I see that the list of build > templates is already quite nice (sbt, maven, gradle, bundler/rake, ...). I > would recommend you to setup a Play2 template, and then BuildHive wins one > point in the race with Travis ;-)
> I am looking forward a new discussion thread about BuildHive upcoming > features !
> To post to this group, send email to play-framework@googlegroups.com. > To unsubscribe from this group, send email to > play-framework+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/play-framework?hl=en.
> SORRY: I mixed myself and my 'second' answer has been posted while I > actually failed to send first reponse... which I include now. Sorry, I think > I better have to read Google Groups Help, but it's time to sleep now :-/
> Thank you for the announcement. BuildHive/GitHub integration is smooth, > quite similar as Travis/GitHub. Nice concurrence in perspective!
> I actually tested 3 Projects (1 Play2 and 2 pure Scala) with following > results:
> Build failed for my Play2 Sample App:
> https://buildhive.cloudbees.com/job/gildegoma/job/travis-ci-ScalaOnPl... > there was a dependency download problem that interrupted the build, I think > this should not happen (again/always) > 'sbt' template is auto-detected => test run with 'sbt test' command, which > is not enough to run 'play test' action (what is actually the goal of my > original post) > is there (alreay) a way to override/force the builder template/script in > BuildHive ?
> Wrong builder for pure Scala/SBT projects (like Salat or Akka):
> Configuration auto-detection are nice features, but anyway it is a must to > let user override/reconfigure default settings... Travis-CI is already quite > mature, BuildHive can for sure take some good influences from it :-).
> on https://buildhive.cloudbees.com/template/, I see that the list of build > templates is already quite nice (sbt, maven, gradle, bundler/rake, ...). I > would recommend you to setup a Play2 template, and then BuildHive wins one > point in the race with Travis ;-)
> I am looking forward a new discussion thread about BuildHive upcoming > features !
> To post to this group, send email to play-framework@googlegroups.com. > To unsubscribe from this group, send email to > play-framework+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/play-framework?hl=en.
On Wednesday, 25 April 2012 01:42:52 UTC+2, gildegoma wrote:
> Hi Matthieu,
> Thank you very much for the feedback! Yeah, missing 'x' permission is > common pitfall when doing copy-paste of shell script content. Actually, I > created this extra script 'travis/setup' in a Don't Repeat Yourself and > clean code spirit, but it's not straightforward and maybe error-prone...
> Let me know which variant you find better... My current feeling: +1 for > this new variant (everything in .travis.yml).
> *Precision:* Comments from Ivan Meredith show how Play projects can > auto-download the Play dependency via Maven/Ivy/sbt. This is also quite > nice way to do it, and it works fine either on BuildHive/Jenkins or Travis. > My idea here was merely to save download time/traffic, with only a single > file to download (play-2.0.zip release), which is also matches with > Installation Guide of Play Framework (see > http://www.playframework.org/documentation/2.0/Installing)
> Regards, Gilles
> Le lundi 23 avril 2012 22:36:41 UTC+2, Matthieu a écrit :
>> Thanks your example.
>> I just had to do a 'chmod +x travis/setup' in order to avoid an error on >> Travis and then it worked like a charm.
>> Matthieu
>> On Saturday, 14 April 2012 18:42:08 UTC+2, gildegoma wrote:
>>> Hi Play2 Developers !
>>> Are you interested in free and powerful Continuous Integration for your >>> applications based on Play2 Framework ? Yes, so just try Travis CI<http://travis-ci.org/>
>>> !
>>> Some more notes (a bit out of post's scope, sorry I can't resist to drop >>> some more ideas in the air ;-)
>>> - I'm pretty sure it will be easy to setup testing of Play2 Modules >>> on Travis as well, but I did not work on that point so far. >>> - For people interested about how to build Play20 framework itself >>> on Travis, you can have a look on >>> https://github.com/gildegoma/Play20/tree/pr-integrate-travis-ci. So >>> far I have not opened any pull request on master project (I think that >>> according to current guidelines of Play20 project such kind of change would >>> not be evaluated for now). Even if main project is tested on cloudbees, I >>> think it could be a nice improvement for the general fork/pull-request >>> community process, if PRs are publicly tested by Travis, before their >>> integration.
I started a second job for Akka, and now 'sbt' detection indeed works fine, but the related command ('sbt test') is not valid in BuildHive environment. You should either:
- directly execute java -jar /opt/sbt/sbt-launch-0.11.0.jar clean test (as you do for your Play project)
or
- configure some symlink/script alias to "java -jar /opt/sbt/sbt-launch-0.11.0.jar" (example: https://github.com/mxcl/homebrew/blob/master/Library/Formula/sbt.rb#L10)
My questions and remarks are now:
- It seems that the project workspace is permanently stored on BuildHive server-side between test runs. That's quite fine…
- Now I'm not able anymore to find the Menu 'configure' in the project context (where it was possible to select which branches must be built, which test script must be executed,…)
- I would recommend to start a new discussion thread dedicated to BuildHive itself (maybe on another group?). It's going to get messy here…
