Betterrev building on Cloudbees

Martijn Verburg martijnverburg at
Mon May 12 08:06:55 UTC 2014

Hi Dan/All,

Sounds like great progress was made, my comments inline.

On 12 May 2014 07:45, Edward Yue Shung Wong <edward.ys.wong at>wrote:

> That is fantastic news, good job guys.
> Re: Actors - we should try to isolate as much functionality from the Play
> side as possible. I say this because:
> - it allows us to TDD within our IDEs, no more relying on Play test.
> - should we ever decide to move off Play, server code which is isolated
> from the client is a "Good Thing"™
> Other than that, everything you guys came up with makes perfect sense!
> Edward
> *Sorry for the duplicate Daniel, I realised I only replied to your email
> before
> On Sunday, 11 May 2014 19:11:16 UTC+1, Daniel Bryant wrote:
>>  Hi all,
>> Yesterday at an OpenJDK hackday at 'Hack the Tower' [0] Richard and I
>> managed to get Betterrev building via Cloudbees (this built upon the
>> initial work done here by Mani and Martijn).
>> Needless to say, no yaks were harmed completing this work, but quite a
>> few were shaved... :-)
>> I'm quite pleased to get this working, as now we can get rid of the
>> dreaded 'works for me' type problems we have been seeing (particularly
>> around tests). You will however notice that the build is currently still
>> failing [1], and this raises some important questions/comments about our
>> current approach to testing.
>> To get the discussion going, here are a few thoughts that Richard, Mani
>> and Michael discussed at the event:
>>    - We should use Akka primarily as a communication/coordination
>>    wrapper around functional units of code. This builds upon Edward's initial
>>    suggestion that we should TDD a functional unit of code with unit tests
>>    (for example, the email functionality), and then add a thin Akka-based
>>    wrapper around this when complete. The Akka extension to the functional
>>    unit should only be tested via a system/integration test
Sounds good, there's an outstanding issue about splitting out the IT tests
which is now possible with the Play upgrade we had recently.

>>    - We should aim to minimise the number of tests that rely on external
>>    resources, and strive to reduce the non-determinism type issues we have
>>    seen with polling the hg repos. However, we may need a few system tests to
>>    ensure that external resources that are scraped or polled do not change
>>    e.g. to ensure the Bitbucket API does not change, or that the Oracle OCA
>>    page structure does not change.
Sounds good

>>    - Should we have an hg code repo as a sub-directory of the project
>>    for testing? For example, we currently include the jdk8 hg repo in the
>>    project, but I'm not sure how this will be handled when building with
>>    Cloudbees? Will they allow execution of arbitrary scripts? And how should
>>    we script the setup of this repo to ensure we have a fully automated build
I think Cloudbees will be quite flexible, we can talk directly to Nicholas
about this.


>>    -
>> It would be great to hear people's feedback - I've posted this to both
>> the betterrev Google group and adoption-discuss mailing lists, as I know
>> some people have issues accessing Google groups at work etc.
>> Best wishes,
>> Daniel
>> [0]
>> [1]
>> --
>> * Daniel Bryant  |  Software Development Consultant  |
>> <>*
>> daniel... at  |  +44 (0) 7799406399  |  Twitter: @taidevcouk<>
>  --
> You received this message because you are subscribed to the Google Groups
> "Betterrev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to betterrev+unsubscribe at
> For more options, visit

More information about the adoption-discuss mailing list