+1 for publishing official snapshot artifacts for 4.0 and even other branches.
We're publishing snapshot artifacts to our internal artifactory. One minor bug we found is: currently build.xml won't publish any snapshot artifact: https://issues.apache.org/jira/browse/CASSANDRA-12704 On Thu, Sep 20, 2018 at 11:35 PM Dinesh Joshi <dinesh.jo...@yahoo.com.invalid> wrote: > 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 > >
