On 11/3/14, 10:55 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote:
>> >> >I didn't run these locally, as I didn't expect changes to >>SystemManager to >> >affect anything but the very core of the SDK. >> >> I would be surprised if your changes made a difference as well but you >> never know. I thought the “unofficial” policy was that if your checkins >> are tied to a run that fails that you have to investigate, by at >>minimum, >> reverting or showing that the tests pass locally for you. >> > >I "wrote" that policy ;-) But there weren't any tests that consistently >failed, the failures have been all over the place. I could revert, but my >assessment was that not my changes, but something on the VM was the root >cause. I’m wondering if there is some easy way to show which tests are failing more often than not. My records show that these two tests: gumbo/components/DataGrid/Properties/DataGrid_Properties_editable Editable_twoWayBinding_test Failed AssertMethodValue (method cannot be shown)(body:step 13) method returned , expected test1234 gumbo/components/RichEditableText/Properties/RichEditableText_layout_test3 RichEditableText_Property_maxChars_1 Failed DispatchKeyEvent(body:step 2) Timeout waiting for change from retEditable1 failed in runs: 1137 1136 1135 1134 1133 1132 1129 1128 1126 1125 1124 1123 Yes, there were other intermittent failures, and run #1130 was full of bad stuff. But #1121 passed, then #1123 with your changes, fails, and those two tests are the repeat offenders since. I have no idea how they can be broken by your changes either, but right or wrong, I think you have try a revert or see if the tests pass locally. -Alex
