Re: [VOTE] CI tests RFC

Hi! > Update test seems like questionable action, but see that you and mike > voted for it, can I hear reasoning for that ? Some tests may test for wrong outcome. Simplest example - you've added an item for function returning an array, but did not update some test to include it. Or, you've fixed a bug but some test had the buggy output included in the test. > I don't see when there would be a good reason to retain a broken commit > for a week, isn't that going to just render all of this pointless if > tests can fail for a week at a time ? I agree. But this is an option, so I put it up for the vote. If most of the people think week is too long (and we've had many instance where the CI was red for more than a week, so this is not an invented scenario) I'd be glad to hear it and we'd have it officially acknowledged. > > Wouldn't it be better if all changes were done on branches, so they can > be reviewed and integrated before being merged at all ? Of course, it would. That's why changes should be done in pulls, and pulls should be green before merging. However, it happens that both rules are not followed, and that even if they are, for some reason the merge is still not green. And in general, I don't think we can enforce anything in this regard until we know we agree on this subject. > Maybe problematic for minor fixes but are they really the kind of thing > that cause CI to bork ? Hopefully not. If the fix breaks the CI and can not be fixed in a short time - then maybe the fix is not as minor as previously thought :) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227