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 <sc...@paradoxica.net> 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 (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 > > -- Jon Haddad http://www.rustyrazorblade.com twitter: rustyrazorblade
