Betterrev building on Cloudbees
martijnverburg at gmail.com
Mon May 12 08:06:55 UTC 2014
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!
> *Sorry for the duplicate Daniel, I realised I only replied to your email
> On Sunday, 11 May 2014 19:11:16 UTC+1, Daniel Bryant wrote:
>> Hi all,
>> Yesterday at an OpenJDK hackday at 'Hack the Tower'  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 , 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.
>> - 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
>> 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,
>>  http://www.meetup.com/Londonjavacommunity/events/181023842/
>>  https://adopt-openjdk.ci.cloudbees.com/job/betterrev/70/console
>> * Daniel Bryant | Software Development Consultant | 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.
More information about the adoption-discuss