Hi, I like to have Continous Testing/Deployment for bigtop. So I am ++1 to enhance/enable it.
we already procduce new repos as part of our Bigtop-trunk Jenkins job every night. We archive the artifacts generated. We have issues, right now: * gradle.org repository is rather unstable breaking 50% of our builds. I already addressed this with BIGTOP-2474, since we do not need to access gradle.org from our build infra. * The repositories are not signed. This can be fixed with a dummy signature. Right now, we have two different Compile job: Bigtop-trunk: Compiling all the stack, very unstable. Bigtop-packages-trunk: Compiling all packages as a single compile. Does not generate a repository. This is intended as an test compile only. I would recommend to stick at the Bigtop-trunk repositories for now. olaf > Am 08.06.2016 um 07:22 schrieb Konstantin Boudnik <[email protected]>: > > Makes all the sense to me. To me the only question is what we can do in the CI > to start producing the repos on each nightly run. > > Cos > > On Tue, Jun 07, 2016 at 04:44PM, Antonio Rosales wrote: >> On Tuesday, June 7, 2016, Jonathan Kelly <[email protected]> wrote: >> >>> Oh, sorry, yes, I misunderstood. Nightly builds of Bigtop trunk would >>> certainly make a lot more sense than any sort of nightly build of the >>> trunks of each supported application. :) >> >> >> The intent here is to enable charms to deploy a stable release or the >> latest Bigtop "bleeding edge." Ideally we would like to run benchmarks and >> integration tests on nightly builds to identify issues earlier in the dev >> pipeline. >> >> Would folks find that helpful? >> >> -Antonio >> >> >>> On Tue, Jun 7, 2016 at 3:24 PM Konstantin Boudnik <[email protected] >>> <javascript:;>> wrote: >>> >>>> On Tue, Jun 07, 2016 at 09:08PM, Jonathan Kelly wrote: >>>>> I'm not sure this will work very well, since many apps depend upon >>> other >>>>> apps but have not yet upgraded to support the latest version of their >>>>> dependencies. >>>>> >>>>> For example, Spark 2.0 is going to be released in the next month or so, >>>> but >>>>> Hive, Mahout, Oozie, Zeppelin and possibly more do not yet support >>> Spark >>>>> 2.0. As another example, Hive 2.1 will be released somewhat soon too, >>> but >>>>> some apps might not yet support Hive 2.x, let alone Hive 2.1. (Bigtop >>> is >>>>> still only on Hive 1.2.1.) >>>> >>>> I believe Konstantinos' question is about the "bleeding state" of Bigtop >>>> stack. Where all you said is completely true - we don't simply leap >>> forward >>>> and switch a version of a component that is unsupported by the rest of >>> the >>>> ecosystem. >>>> >>>> Yet, our trunk has a number of advances compared to any previous release >>>> and >>>> for some people such deployments might be very desirable. >>>> >>>> Cos >>>> >>>>> ~ Jonathan >>>>> >>>>> On Tue, Jun 7, 2016 at 12:19 AM Konstantinos Tsakalozos < >>>>> [email protected] <javascript:;>> wrote: >>>>> >>>>>> Hi everyone, >>>>>> >>>>>> Is there a way to deploy the bleeding edge of the components Bigtop >>>>>> packages? This would greatly benefit Apache project developers as >>> well >>>> as >>>>>> users that want to try out the latest features. >>>>>> >>>>>> Do we have a mirror with deb packages nightly builds that install >>> what >>>> is >>>>>> on the head of the Apache projects offered by Bigtop? We would also >>>> need to >>>>>> grab the head of Bigtop on github, right? >>>>>> >>>>>> Thank you, >>>>>> Konstantinos >>>>>> >>>> >>> >> >> >> -- >> -Thanks >> Antonio
signature.asc
Description: Message signed with OpenPGP using GPGMail
