If I remember correctly, the requirement of providing test results along with each patch was because of tick-tock, where the goal was to have stable release branches at all times. Without CI for testing each individual commit on all branches, this just won't work anymore. But would that really be that bad? Can't we just get away with a single CI run per branch and day?
E.g. in the future we could commit to dev branches that are used to run all tests automatically on Apache CI on daily basis, which is then exclusively used for that. We don't have that many commits on a single day, some of them rather trivial, and I think we'd be able to figure out the one of them causing a regression on the day after. If all tests pass, we can merge dev manually or even better automatically. If anyone wants to run tests on his own CI before committing to dev, that's fine too and will help analyzing any regressions if they happen, as we then don't have to look at those patches (and all commits before on dev). On 09.03.2017 19:51, Jason Brown wrote: > Hey all, > > A nice convention we've stumbled into wrt to patches submitted via Jira is > to post the results of unit test and dtest runs to the ticket (to show the > patch doesn't break things). Many contributors have used the > DataStax-provided cassci system, but that's not the best long term > solution. To that end, I'd like to start a conversation about what is the > best way to proceed going forward, and then add it to the "How to > contribute" docs. > > As an example, should contributors/committers run dtests and unit tests on > *some* machine (publicly available or otherwise), and then post those > results to the ticket? This could be a link to a build system, like what we > have with cassci, or just upload the output of the test run(s). > > I don't have any fixed notions, and am looking forward to hearing other's > ideas. > > Thanks, > > -Jason > > p.s. a big thank you to DataStax for providing the cassci system >
