On Fri, Oct 09, 2015 at 02:55AM, Evans Ye wrote: > Yes. We'll do that on new CI. > Changing every job setting is a big headache to me. ;)
Could be done with sed right on the config files, instead of doing this via webUI. The latter is a pain in the butt, of course. Cos > 2015-10-09 2:52 GMT+08:00 Evans Ye <[email protected]>: > > > The CI currently running on cloudera master is still using old images w/o > > trunk prefix, hence it's still not maven 3.3.3 yet. > > I'd prefer to switch to new images on our new CI master. In new CI env w/ > > sufficient disk we don't need to have bunch of jobs for each package > > separately. Using a multi-parameter build job would be much easier to > > maintain. > > > > My observation on HBase build is it is flipping. Sometimes it's good, > > sometimes not. I guess it's the upstream issue... > > > > BTW, I noticed that BIGTOP-2059 > > <https://issues.apache.org/jira/browse/BIGTOP-2059>, BIGTOP-2063 > > <https://issues.apache.org/jira/browse/BIGTOP-2063> have been pushed w/o > > +1. > > Are you doing CTR, Cos? > > If so that's fine but we should have a short announcement to officially > > start the trial. :) > > > > > > 2015-10-09 1:51 GMT+08:00 Olaf Flebbe <[email protected]>: > > > >> hi, > >> > >> The build dockers are updated. Be sure to use > >> bigtop/slaves:trunk-centos-7 for instance. The trunk-... containers denote > >> the current git trunk built by docker/build-slaves/... recipies. > >> > >> -olaf > >> > >> > >> > Am 08.10.2015 um 19:32 schrieb Konstantin Boudnik <[email protected]>: > >> > > >> > Indeed, but I don't think we have upgraded the build dockers just yet. > >> > Otherwise, the build would be just fine, I think. > >> > > >> > Cos > >> > > >> > On Thu, Oct 08, 2015 at 10:11AM, Jonathan Kelly wrote: > >> >> Maven should already be 3.3.3 as of > >> >> https://issues.apache.org/jira/browse/BIGTOP-1953, right? > >> >> > >> >> On Thu, Oct 8, 2015 at 9:32 AM, Konstantin Boudnik <[email protected]> > >> wrote: > >> >> > >> >>> Looks like we are pretty much all-green on the CI side. Two issues > >> left: > >> >>> - Mahout expects Maven >=3.3.3 (which I think is coming with the new > >> >>> containers, right?) > >> >>> - Hbase is failing weirdly and don't know what to make out of it > >> >>> 08:57:25 [ERROR] Failed to execute goal > >> >>> org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on > >> >>> project > >> >>> hbase: Error during page generation: Error rendering Maven report: > >> Failed > >> >>> during checkstyle execution: Unable to find suppressions file at > >> location: > >> >>> hbase/checkstyle-suppressions.xml: Could not find resource > >> >>> 'hbase/checkstyle-suppressions.xml'. -> [Help 1] > >> >>> > >> >>> It seems like an upstream issue, isn't it? Andrew, any suggestions? > >> >>> > >> >>> Thanks, > >> >>> Cos > >> >>> > >> >>> On Mon, Sep 28, 2015 at 10:23PM, Evans Ye wrote: > >> >>>> Fix tez build, which was failing because of some docker daemon issue > >> on > >> >>> the > >> >>>> build slave. :) > >> >>>> > >> >>>> 2015-09-25 19:06 GMT+02:00 Evans Ye <[email protected]>: > >> >>>> > >> >>>>> With nodeps setting added now our CI is almost back to normal. > >> >>>>> There're still 5 components failing but the other's are good. > >> >>>>> I need to update our build slaves so that mahout can resume to > >> normal. > >> >>>>> I don't know why the others still failing. > >> >>>>> Will look into them when back from budapest ;) > >> >>>>> > >> >>>>> 2015-09-22 2:50 GMT+08:00 Konstantin Boudnik <[email protected]>: > >> >>>>> > >> >>>>>> 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 > >> >>>>>>>> > >> >>>>>> > >> >>>>> > >> >>>>> > >> >>> > >> > >> > >
