> > ci-cassandra.a.o needs to be our canonical CI it's the only one fully usable by a volunteer based
only green in both counts as green I think today might just be my day to annoy you Mick. :D Sorry! I think this is contradictory. We can't require circle to be green for a release if the free tier usage of it a) doesn't pass tests, and/or b) requires a license incompatible w/some contributors. That effectively would make circle + asf ci our canonical ci, right? less flakies than the previous release This statement makes me wary. :) Why not "no test failures"? ~Josh On Thu, Dec 16, 2021 at 10:41 AM Mick Semb Wever <m...@apache.org> wrote: > > > > Mick, did I miss anything? > > > > > Yup, ci-cassandra.a.o needs to be our canonical CI because of the > reasons you state, and because it's the only one fully usable by a > volunteer based PMC, i.e. community donated hardware, controlled by > ASF, and no need for a proprietary licence. > > I think we should be making that post-commit pipeline as comprehensive > as possible. > > I also really appreciate that we have CircleCI, apart from its > benefits (particularly speed for pre-commit), it provides valuable > double-accounting over CI results. A few times we have broken because > one system didn't properly catch errors. It can be frustrating that we > get green in one system and then it breaks in the other, but if we > embrace this strengthening tactic: only green in both counts as green; > then we end up in a better place. > > Let's continue to make post-commit CI as comprehensive as possible, > and figure out as-we-go what the most efficient pre-commit gate is, > and accept that if you break it post-commit you still broke it. > > For releases I think we have to have no hard failures, and less > flakies than the previous release. Using Butler we can more easily > visualise failures from flakies from CI infra instabilities, and > ensure tickets are created and if a dev broke it that they are > assigned accordingly (and prioritise its fix above all other > non-critical work in the project). > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
