brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Downer <>
Subject Re: [PROPOSAL] Using docker for jenkins builds
Date Tue, 14 Nov 2017 15:48:25 GMT

Having seen some of the conversations on the 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.


On 14 November 2017 at 15:43, Thomas Bouron <
> 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]
> [2]
> brooklyn-dist-master-docker/
> [3]
> brooklyn-dist-master/
> [4]
> --
> Thomas Bouron • Senior Software Engineer @ Cloudsoft Corporation •
> Github:
> Twitter:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message