bigtop-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roman Shaposhnik <ro...@shaposhnik.org>
Subject Re: CI improvements [Was: The state of new CI]
Date Fri, 25 Dec 2015 01:06:54 GMT
On Wed, Dec 23, 2015 at 10:38 PM, Konstantin Boudnik <cos@apache.org> wrote:
> Actually, there's more into this. Mounting volumes from a host will always be
> a subject to disrepancies between host's user uid/gio and ones inside of the
> container. We still should go ahead at least with 2) and 3) in the short run.

Let me look into this today. I think we may as well solve it once and for all.
In fact, looking at how our Jenkins job is setup I'm thinking that
perhaps having
a direct Docker-enabled entry point into our build process will be better than
keep remembering an exact incantation of Docker.

So how about we implement a sysprop bigtop.build.env so that the following
will happen:
    1. with bigtop.build.env not set we get the current build process remains
        the same
    2. with bigtop.build.env set to one of the build environment values that we
        recognize the Docker magic is transparently invoked
    3. with bigtop.build.env set to anything else Gradle prints the
list of build
        environments and exists

Thoughts?

Thanks,
Roman.

P.S. If it were Maven, I'd hook it up as a profile, but I guess with
Gradle sysprops
is all we get to switch things around, right?

Mime
View raw message