On Wed, Aug 16, 2017 at 1:46 AM, Joan Touzet <woh...@apache.org> wrote: > Hi committers, > > I'd like to propose a change to our policy on version control, namely > that no check-ins be allowed on the master branch unless CI test runs > against that PR are clean. > > We've worked hard as a group to get runs clean. We need to protect > that achievement and investment in our test suite. That means not > letting rogue check-ins slip by because we are ignoring a red X in > GitHub (GH) from the Travis run. > > Things I see as exceptions: > * Changes to things clearly not related to the test suite, i.e. > documentation, support scripts, rel/overlay/etc/ files, etc. > * Changes already agreed upon in a previous PR/discussion for > administrative tasks >
I'd be +1 for requiring a clean Travis-CI run before something can be merged. I'm pretty sure we can configure that easily enough (via INFRA as you mention). However I'd make that absolutely no exceptions. I'd also disable commits directly to master not coming through PR so that it can't be bypassed. This is especially important for when merge PRs to dependencies we'd need to require the rebar.config.script update to PR'ed so it goes through CI. > Interesting situation right now for a discussion: Garren has a PR up[1] > that enables the mango tests to be part of the standard Travis/Jenkins > runs. Unfortunately, it doesn't pass on one of our platforms right now > and that needs investigation. Should we allow the PR to land and fix > the problems in master, or should the PR hold-up until it can land along > with the fixes for the failing mango tests? I can see both sides of this > argument. > > It may or may not be possible for our GH setup to actually prevent such > checkins (the Apache GH setup is somewhat restricted, and various things > like commit hooks and webhooks have to be configured by INFRA, not us). > > I'd like to further discuss whether people feel such a hook would be > acceptable, onerous or otherwise. Personally, I worry that such a setup > might prevent us from checking in some of the exceptions above, but if > there is a way around it, we could proceed down that path. > I don't think we should entertain any gray area as it muddies the waters. I'd say we either make it 100% or leave it in the current state of "best effort" which is what I believe your current example falls into which is the status quo. > What do you think, sirs?[2] > Joan > > > [1]: https://github.com/apache/couchdb/pull/753 > [2]: It's a Mystery Science Theatre 3000 Joel reference. :)
