[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cassandra-dev
Subject:    Re: Proposed changes to CircleCI testing workflow
From:       Sumanth Pasupuleti <sumanth.pasupuleti.is () gmail ! com>
Date:       2018-10-29 4:57:00
Message-ID: CAKad6UNGUOWQ+pqCDR161C9NUNmjOKoVbBb1PG_Mg_S4JnXVhg () mail ! gmail ! com
[Download RAW message or body]


Hi Stefan,

+1 on the CircleCI changes.

A few months ago, I took a shot at CircleCI to add support for Java 1.7 and
in the process (perhaps the more important takeaway), explored adding
"aliases" to avoid code duplication in the yml file (
https://github.com/apache/cassandra/pull/248/commits/47855675f4805a09b78059f7231311566f0e66f0).
I believe we can do similar optimization to
https://github.com/spodkowinski/cassandra/blob/WIP-14806/.circleci/config.yml
.

Also, with your changes, I believe we can close out CASSANDRA-14609.

I was also planning to work on CASSANDRA-14718 to validate artifacts
generation - let me know what you think.

Thanks,
Sumanth


On Fri, Oct 26, 2018 at 10:05 AM Ariel Weisberg <ariel@weisberg.ws> wrote:

> Hi,
>
> Thank you for working on this. These all sound like good changes to me.
>
> Ariel
>
> On Fri, Oct 26, 2018, at 10:49 AM, Stefan Podkowinski wrote:
> > I'd like to give you a quick update on the work that has been done
> > lately on running tests using CircleCI. Please let me know if you have
> > any objections or don't think this is going into the right direction, or
> > have any other feedback!
> >
> > We've been using CircleCI for a while now and results are used on
> > constant basis for new patches. Not only by committers, but also by
> > casual contributors to run unit tests. Looks like people find the
> > service valuable and we should keep using it. Therefor I'd like to make
> > some improvements that will make it easier to add new tests and to
> > continue making CircleCI an option for all contributors, both on paid
> > and free plans.
> >
> > The general idea of the changes implemented in #14806, is to consolidate
> > the existing config to make it more modular and have smaller jobs that
> > can be scheduled ad-hoc by the developer, instead of running a few big
> > jobs on every commit. Reorganizing and breaking up the existing config
> > was done using the new 2.1 config features. Starting jobs on request,
> > instead of automatically, is done using the manual approval feature,
> > i.e. you now have to click on that job in the workflow page in order to
> > start it. I'd like to see us having smaller, more specialized groups of
> > tests that we can run more selectively during development, while still
> > being able to run bigger tests before committing, or firing up all of
> > them during testing and releasing. Other example of smaller jobs would
> > be testing coverage (#14788) or cqlsh tests (#14298). But also
> > individual jobs for different ant targets, like burn, stress or
> benchmarks.
> >
> > We'd now also be able to run tests using different docker images and
> > different JDKs. I've already updated the used image to also include Java
> > 11 and added unit and dtest jobs to the config for that. It's now really
> > easy to run tests on Java 11, although these won't pass yet. It seems to
> > be important to me to have this kind of flexibility, given the
> > increasingly diverse ecosystem of Java distributions. We can also add
> > jobs for packaging and doing smoke tests by installing and starting
> > packages on different docker images (Redhat, Debian, Ubuntu,..) at a
> > later point.
> >
> > As for the paid vs free plans issue, I'd also like us to discuss how we
> > can make tests faster and less resource intensive in general. As a
> > desired consequence, we'd be able to move away from multi-node dtests,
> > to something that can be run using the free plan. I'm looking forward to
> > see if #14821 can get us into that direction. Ideally we can add these
> > tests into a job that can be completed on the free plan and encourage
> > contributors to add new tests there, instead of having to write a dtest,
> > which they won't be able to run on CircleCI without a paid plan.
> >
> > Whats changing for you as a CircleCI user?
> > * All tests, except unit tests, will need to be started manually and
> > will not run on every commit (this can be further discussed and changed
> > anytime if needed)
> > * Updating the config.yml file now requires using the CircleCI cli tool
> > and should not be done directly (see #14806 for technical details)
> > * High resource settings can be enabled using a script/patch, either run
> > manually or as commit hook (again see ticket for details)
> > * Both free and paid plan users now have more tests to run
> >
> > As already mentioned, please let me know if you have any thoughts on
> > this, or if you think this is going into the wrong direction.
> >
> > Thanks.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>


[prev in list] [next in list] [prev in thread] [next in thread]