> 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]
Sorry I'm just getting to this mail now. We don't have this issue upstream, at least that I've seen when making releases, but let me try a Bigtop build tomorrow and see if I can reproduce it there. > On 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 >>> >>>
