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
