+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 > > >
