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