osdir.com

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: QA signup


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 (mck@xxxxxxxxxx<mailto:mck@xxxxxxxxxx>) 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-unsubscribe@xxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx