Got it, thanks! On the target audience:
This would primarily be C* developers who are working on development, testing, and validation of the release. The performance testing exercise Joey, Vinay, Sumanth, Jason, Jordan, and Dinesh completed yesterday is a good example [1]. 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. Some purposes that could serve: – Ensuring we’re testing the same artifact. While a build produced from a given SHA should be ~identical, we can make stronger statements about particular build artifacts produced by common infrastructure than local builds produced by individual developers. – Automation: the ability to automate test suite runs on publication of a new build (e.g., perf, replay, traffic shadowing, upgrade tests, etc). – Faster dev/test/validation cycles. The perf tests in [1] identified two issues whose fixes will land in C-14503. Being able to pick up these fixes on commit via automation provides quicker feedback than waiting for a new build to be manually cut. – Fewer developers experiencing blocked automation. In a case where a regression is identified in a build produced by a commit (e.g., a snapshot build is “DOA” for testing purposes), a quick fix could resolve the issue with a new testable artifact produced within a day. – Better delineation between developer builds and those we recommend to the user community. Our ability to produce snapshot/nightly artifacts reduces pressure to cut an alpha for testing, reducing pressure to nominate community-facing releases in order to further the developer-focused goals above. –– [1] https://cwiki.apache.org/confluence/display/CASSANDRA/4.0+Performance+Testing On September 18, 2018 at 5:47:18 PM, Mick Semb Wever (m...@apache.org<mailto:m...@apache.org>) wrote: Scott, > @Mick, thanks for your reply re: publishing snapshots/nightlies. In > terms of what’s needed to configure these, would it be automation around > building release artifacts, publishing jars to the Maven snapshots repo, … Maven artefacts are deployed to the ASF snapshot repository in Nexus. The short of it is to add credentials for `apache.snapshots.https` to ~/.m2/settings.xml and run `ant publish`. It looks like `ant publish` won't run when it's not a release, but otherwise the maven deploy properties in `build.xml` look correct for snapshots. I haven't looked into how to automate this in Jenkins in regards to the settings.xml credentials and the gpg signing. For info at: http://www.apache.org/dev/publishing-maven-artifacts.html I question I have is who are we targeting with maven snapshots? Is this an audience that can easily enough be building the jars themselves to test during the feature freeze period? > and to dist/dev/cassandra on dist.apache.org for binary artifacts? This is a simpler task, just upload (`svn commit`) the nightly binaries to https://dist.apache.org/repos/dist/dev/cassandra/<nighly-version> See https://www.apache.org/legal/release-policy.html#host-rc regards, Mick --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
