On Wed, Oct 27, 2021 at 9:22 PM Tom Rini <tr...@konsulko.com> wrote: > > On Wed, Oct 27, 2021 at 12:43:38PM +0800, Bin Meng wrote: > > Hi Simon, > > > > gitlab reported the following test error below: > > > > =================================== FAILURES > > =================================== > > __________________________ test_ut[ut_dm_rtc_set_get] > > __________________________ > > test/py/tests/test_ut.py:43: in test_ut > > assert output.endswith('Failures: 0') > > E AssertionError: assert False > > E + where False = <built-in method endswith of str object at > > 0x7f3bb792dcb0>('Failures: 0') > > E + where <built-in method endswith of str object at 0x7f3bb792dcb0> = > > 'Test: dm_test_rtc_set_get: rtc.c\r\r\nexpected: 27/10/2021 > > 03:38:15\r\r\nactual: 27/10/2021 03:38:14\r\r\ntest/dm/rtc...w, &cmp, > > 1): Expected 0x0 (0), got 0xffffffea (-22)\r\r\nTest: > > dm_test_rtc_set_get: rtc.c (flat tree)\r\r\nFailures: 1'.endswith > > ----------------------------- Captured stdout call > > ----------------------------- > > => > > > > See https://source.denx.de/u-boot/custodians/u-boot-x86/-/jobs/341905 > > > > But the same branch same commit, azure test results passed: > > https://dev.azure.com/bmeng/GitHub/_build/results?buildId=460&view=results > > > > It looks like the error is an off-by-one where actual time is 1 second > > behind the expected time? > > > > expected: 27/10/2021 03:38:15 > > actual: 27/10/2021 03:38:14 > > > > Is this a known issue? > > Yes, which is why the test checks for a certain amount of "fuzz" around > the return value. I've wondered about if we need to increase that value > slightly sometimes, or just live with hitting the re-run failed jobs > button on whatever CI system was a bit too slow sometimes. >
Thanks Tom. So it is a known issue. It's just my first time seeing this failure in CI :) Regards, Bin