Betterrev building on Cloudbees

[Martijn Verburg]

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 gmail.com>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.

Cheers,
Martijn


>>    -
>>
>> 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] http://www.meetup.com/Londonjavacommunity/events/181023842/
>> [1] https://adopt-openjdk.ci.cloudbees.com/job/betterrev/70/console
>>
>>
>> --
>> * Daniel Bryant  |  Software Development Consultant  |  www.tai-dev.co.uk
>> <http://www.tai-dev.co.uk/>*
>> daniel... at tai-dev.co.uk  |  +44 (0) 7799406399  |  Twitter: @taidevcouk<https://twitter.com/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 googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>