Le lun. 26 oct. 2020 à 15:11, Eliot Miranda <eliot.miranda@gmail.com> a écrit :Hi Nicolas,On Oct 26, 2020, at 6:59 AM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:Hi all,I have restored (I think) the green status of minheadless build.Thank you so much!We could eventually authorize failure of all those builds, or restrict the number of flavours that we build (it takes really loooong time before we get CI feedback).But if we abandon all those now, I fear that we never catch up; it's a one way ticket. IMO there are still interesting ideas to take, even if development has continued in Pharo fork...One approach might be to split them into “essential” and “nice to have” so we get faster feedback from the “essential” set.+1, but I do not know how to configure the CI like that...Could these test failures be nothing to do with the VM but instead to do with the (growing) divergence between trunk/spur and Squeak 4.6?Now the next failing build on travis is about squeak.cog.v3. Did some incompatible VM change took place?####################################################### Squeak-4.6 on Travis CI (2278.23) ## 3401 Tests with 5 Failures and 0 Errors in 112.13s ################################################################################# 5 tests did not pass: ##########################SUnitToolBuilderTests837fef_266b✗ #testHandlingNotification (10023ms)TestValueWithinFix2a65cb_266b✗ #testValueWithinTimingBasic (1005ms)e9a7ab_266b✗ #testValueWithinTimingNestedInner (1001ms)c57415_266b✗ #testValueWithinTimingNestedOuter (1002ms)e89da3_266b✗ #testValueWithinTimingRepeat (3004ms)Executed 3401 Tests with 5 Failures and 0 Errors in 112.13s.To reproduce the failed build locally, download smalltalkCI, and try to run something like:bin/smalltalkci -s Squeak-4.6 --headfull /path/to/.smalltalk.ston_,,,^..^,,,_ (phone)No idea...I've downloaded a Squeak4.6-15102.image, compiled a squeak.cog.v3 on windows10, and the test pass...I will retry on other OSes this evening (the test fails on linux...).At least one of those failures is a timeout. So it may just be that the CI box is slow. We might cure the issues by lengthening the timeouts. Or we could make them expected failures, especially if we can find out some way to identify that we’re running on a CI box.There's something fishy...Only the linux brand times out.The test waits 10 times 200msec, so should last about 2s.[SUnitToolBuilderTests new testHandlingNotification] timeToRun.does answer something around 2048 on macos brand, but 7706 on linux (???).The build.itimerheartbeat brand does complete the test in about 2020ms so it's OK.squeak.cog.spur/build/squeak also performs the test in about 7700ms in an updated trunk image...So it's not just squeak.cog.v3 here...I can only run linux thru a VM (Parallels), so if someone can confirm the behavior on some native linux