Betterrev building on Cloudbees

Edward Yue Shung Wong edward.ys.wong at gmail.com
Mon May 12 06:45:37 UTC 2014



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 
>    - 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. 
>    - 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
>     
> 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 <javascript:>  |  +44 (0) 7799406399  |  Twitter: 
> @taidevcouk <https://twitter.com/taidevcouk> 
>  


More information about the adoption-discuss mailing list