Re: QA signup
It seems to me that improving / simplifying the process of building the
packages might solve this problem better. For example, in the tests you
linked to, they were using a custom build that hadn't been rolled into
trunk. I expect we're going to see a lot of that.
If we make building a deb package as easy as running `docker-compose run
build-deb` then that addresses the problem of testing all branches.
This sort of exists already in cassandra-builds, but it's doing a little
more than just building a basic deb package. Might be easier if it was
directly in the Cassandra repo.
On Wed, Sep 19, 2018 at 5:00 PM Scott Andreas <scott@xxxxxxxxxxxxxx> wrote:
> 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 . 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  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
> On September 18, 2018 at 5:47:18 PM, Mick Semb Wever (mck@xxxxxxxxxx
> <mailto:mck@xxxxxxxxxx>) wrote:
> > @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
> 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
> See https://www.apache.org/legal/release-policy.html#host-rc
> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx