Huge +1 on consistency/portability. On Tue, 14 Nov 2017 at 16:40 Mark McKenna <[email protected]> wrote:
> +1 I echo what Richard says about consistency ... also makes debugging > build failures easier > > > > On 14 November 2017 at 15:48, Richard Downer <[email protected]> wrote: > > > +1 > > > > Having seen some of the conversations on the [email protected] list, it > > does seem like this is the way to go as far as getting the right build > > environment on the Apache Jenkins cluster. This is the best solution for > > getting the `rpm` and `deb` built regularly. > > > > Build consistency is also a great driver. I can see this being useful for > > the release process too, as a release build would have an identical > > environment to that used to build the snapshots. > > > > Richard. > > > > > > On 14 November 2017 at 15:43, Thomas Bouron > <[email protected] > > om > > > wrote: > > > > > Hi Brooklyners! > > > > > > Few months ago, I pushed a PR[1] to simplify `brooklyn-vagrant` by > using > > > the RPM package. This is still on hold because we don't build RPM > package > > > of SNAPSHOT versions and therefore, our vagrant install script won't > work > > > for bleeding edge versions. > > > For the record, RPM are not built on SNAPSHOT because INFRA does not > > offer > > > centos/RHEL machines as Jenkins slaves. > > > > > > But that is coming to an end. INFRA did install (recently-ish) docker > on > > > all Jenkins slaves which means that a new world is opened to us! In the > > > past weeks, I have created a clone[2] of the `brooklyn-dist-master`[3] > > job > > > and configured it to use a custom docker image I created[4]. It is > based > > on > > > `maven:alpine` and adds `rpm` and `dpkg` binaries (for the `dist` tag). > > > As my test was successful, I decided to go a little further by > creating 2 > > > other tags for this image: > > > - `client, based on `maven:alpine` with the `go` binary > > > - `latest` which is the combination of the last 2. > > > > > > My plan is to migrate all jenkins jobs to use docker. I'll donate the > > > `Dockerfile` to each git repo so that jenkins will be able to build and > > > publish them on docker hub instead of using my account/image. Once we > > have > > > everything dockerised, we can look at improving current builds, like > > using > > > jenkins pipelines rather than relying on upstream<->downstream > projects' > > > relationships. > > > > > > It also makes the integration/live tests rise from the ashes. This is > the > > > perfect opportunity to fix and make then part of our CI. > > > > > > WDYT? Even if it's obvious, the main advantage here is the portability > of > > > the build environment. It also means that we can use any jenkins > slaves, > > > potentially saving us a lot of time when waiting for a build executor. > > > > > > Best. > > > > > > [1] https://github.com/apache/brooklyn-dist/pull/105 > > > [2] > > > https://builds.apache.org/view/B/view/Brooklyn/job/ > > > brooklyn-dist-master-docker/ > > > [3] https://builds.apache.org/view/B/view/Brooklyn/job/ > > > brooklyn-dist-master/ > > > [4] https://hub.docker.com/r/tbouron/brooklyn-build/ > > > -- > > > > > > Thomas Bouron • Senior Software Engineer @ Cloudsoft Corporation • > > > https://cloudsoft.io/ > > > Github: https://github.com/tbouron > > > Twitter: https://twitter.com/eltibouron > > > > > >
