I favor versioned nightlies for testing so everyone is using the exact binary distribution.
As far as actually building the packages go, I would prefer a Docker based solution like Jon mentioned. It provides a controlled, reproducible, clean room environment. Ideally the build script should ensure that the git branch is clean and that there aren't any local changes if the packages are being published to maven. Does anyone see a need to publish the git branch metadata in the build like the git-sha, branch and repo url? I am not sure if this is already captured somewhere. Its useful to trace a build's provenance. Dinesh > On Sep 20, 2018, at 2:26 PM, Jonathan Haddad <j...@jonhaddad.com> wrote: > > Sure - I'm not disagreeing with you that pre-built packages would be nice > to have. That said, if someone's gone through the trouble of building an > entire testing infrastructure and has hundreds of machines available, > running `docker-compose up build-deb` is likely not a major issue. If I'm > trying to decide between solving the 2 problems I'd prefer to make builds > easier as very few people actually know how to do it. I'm also biased > because I'm working on a tool that does _exactly_ that (build arbitrary C* > debs and deploy them to AWS for perf testing with tlp-stress which we've > already open sourced https://github.com/thelastpickle/tlp-stress). > > I'll building it for internal TLP use but there's not much TLP specific > stuff, we'll be open sourcing it as soon as we can. > > TL;DR: we need both things > > On Thu, Sep 20, 2018 at 2:12 PM Scott Andreas <sc...@paradoxica.net> wrote: > >> Mick – Got it, thanks and sorry to have misunderstood. No fault in your >> writing at all; that was my misreading. >> >> Agreed with you and Kurt; I can’t think of a pressing need or immediate >> use for the Maven artifacts. As you mentioned, all of the examples I’d >> listed require binary artifacts only. >> >> Re: Jon’s question: >>> It seems to me that improving / simplifying the process of building the >> packages might solve this problem better. >> >> Agreed that making builds easy is important, and that manually-applied >> patches were involved in a couple cases I’d cited. My main motivation is >> toward making it easier for developers who’d like to produce >> fully-automated test pipelines to do so using common artifacts, rather than >> each replicating the build/packaging step for tarball artifacts themselves. >> >> Publishing binary artifacts in a common location would enable developers >> to configure testing and benchmarking pipelines to pick up those artifacts >> on a daily basis without intervention. In the case of a build landing DOA >> due to an issue with a commit, it’d be enough for zero-touch automation to >> pick up a new build with the fix the following day and run an extended >> suite across a large number of machines and publish results, for example. >> >> >> On September 19, 2018 at 8:17:05 PM, kurt greaves (k...@instaclustr.com >> <mailto:k...@instaclustr.com>) wrote: >> >> It's pretty much only third party plugins. I need it for the LDAP >> authenticator, and StratIO's lucene plugin will also need it. I know there >> are users out there with their own custom plugins that would benefit from >> it as well (and various other open source projects). It would make it >> easier, however it certainly is feasible for these devs to just build the >> jars themselves (and I've done this so far). If it's going to be easy I >> think there's value in generating and hosting nightly jars, but if it's >> difficult I can just write some docs for DIY. >> >> On Thu, 20 Sep 2018 at 12:20, Mick Semb Wever <m...@apache.org> wrote: >> >>> Sorry about the terrible english in my last email. >>> >>> >>>> On the target audience: >>>> >>>> [snip] >>>> For developers building automation around testing and >>>> validation, it’d be great to have a common build to work from rather >>>> than each developer producing these builds themselves. >>> >>> >>> Sure. My question was only in context of maven artefacts. >>> It seems to me all the use-cases you highlight would be for the binary >>> artefacts. >>> >>> If that's the case we don't need to worry about publishing snapshots >> maven >>> artefacts, and can just focus on uploading nightly builds to >>> https://dist.apache.org/repos/dist/dev/cassandra/ >>> >>> Or is there a use-case I'm missing that needs the maven artefacts? >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >>> For additional commands, e-mail: dev-h...@cassandra.apache.org >>> >>> >> > > > -- > Jon Haddad > http://www.rustyrazorblade.com > twitter: rustyrazorblade --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
