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