OSDir


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

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 [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
>
>

-- 
Jon Haddad
http://www.rustyrazorblade.com
twitter: rustyrazorblade