I think for now it would be reasonable to just turn off the dependency graph
building. To do that we need to add
-Dbuildnodeps=true
to the gradle command line.
Cos
On Tue, Sep 22, 2015 at 01:40AM, Evans Ye wrote:
> Yup, and I think we've discussed that before in BIGTOP-1906.
>
> Right now I don't have any clue how to build that server up, but that's a
> good way to go since our users would somehow need to set there internal
> jars repository for hadoop apps developer to download dependencies.
>
> At this point, I'm thinking that maybe Cos can give me a hint of code
> snippet how to turn the dependency build off. If there's no such feature I
> can try to add it so that we can resume the CI status.
>
>
> 2015-09-21 20:36 GMT+08:00 Jay Vyas <[email protected]>:
>
> > Thanks Evans. I like your idea of separate Bigtop artifacts stored
> > somewhere...
> >
> > If Bigtop can publish its own jars to its own nexus (or else to upstream
> > apaches maven server) that is ideal I guess!
> >
> > > On Sep 21, 2015, at 4:19 AM, Evans Ye <[email protected]> wrote:
> > >
> > > Hi all !
> > >
> > > I spent some time looking into this and found that the massive job
> > failing
> > > is telling us that the build dependency feature is now working! Which is
> > > because of every build that has dependency setting start from building
> > > upstream packages locally. That fills up the disk size on every build
> > > slaves.
> > > As I mentioned earlier, our CI build env is a sub-optimal design because
> > of
> > > limited disk size on instances. I have no choice to split components
> > > equally on 4 slaves manually to ease the disk consumption.
> > >
> > > Maybe I should start trying nexus server to put built jars there?
> > > Or I can specify an option to tell gradle to fetch jars directly from
> > > public maven instead of building upstream components locally?
> > >
> > >
> > > Thanks,
> > > Evans
> >
