ok 5 empty test file runs zero tests ok 6 one passing test not ok 7 summary passing tests # (in test file test/bats.bats, line 46) # `[ "${lines[1]}" = "1 test, 0 failures" ]' failed not ok 8 summary passing and skipping tests ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 13.0-desktop-plasma-systemd_abi32+64_20170924-152248 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-6.4.0 * Available Python interpreters, in order of preference: [1] python3.4 [2] python2.7 (fallback) [3] pypy3 (fallback) [4] pypy (fallback) java-config: The following VMs are available for generation-2: 1) IcedTea JDK 7.2.6.11 [icedtea-bin-7] *) IcedTea JDK 3.5.1 [icedtea-bin-8] Available Java Virtual Machines: [1] icedtea-bin-7 [2] icedtea-bin-8 system-vm emerge -qpv dev-util/bats [ebuild N ] dev-util/bats-0.4.0_p20170219
Created attachment 498090 [details] emerge-info.txt
Created attachment 498092 [details] dev-util:bats-0.4.0_p20170219:20171008-105039.log
Created attachment 498094 [details] emerge-history.txt
Created attachment 498096 [details] environment
Created attachment 498098 [details] etc.portage.tbz2
Created attachment 498100 [details] temp.tbz2
Cannot reproduce, please execute the following in the unpacked tarball in the workdir and post the output: for test in test/fixtures/bats/passing.bats test/fixtures/bats/passing_and_skipping.bats test/fixtures/bats/failing_and_passing.bats test/fixtures/bats/passing_failing_and_skipping.bats; do echo ">>> $test" echo ">> tap" bash -x ./bin/bats --tap $test echo ">> pretty" bash -x ./bin/bats --pretty $test done
Created attachment 498588 [details] log.log
That output matches what bats tests for, so it shouldn't be failing. A bit suspicious are the log files in tmp, where test results are written to fd 3, which has been closed early. This may not be related though. Is the test suite failing permanent or intermittent? Please pack the chroot and send the link, an environment to reproduce the failures in would help a lot. Thanks.
(In reply to Nelo-T. Wallus (ntnn) from comment #9) you don't want that : tinderbox@mr-fox ~ $ scw img2/13.0-desktop-plasma-systemd_abi32+64_20170924-152248 mr-fox / # du -hs . 45G . Well, let see, if this repeats at an image where test is activated again.
It's been almost two months, can we close the issue or hasn't a test build been repeated yet?
it works now fine at current images - will close this therefore
got at the unstable amd64 chroot image 17.0-desktop-gnome-systemd_test_20180520-112305 this : not ok 7 summary passing tests
Created attachment 532608 [details] emerge-info.txt
Created attachment 532610 [details] dev-util:bats-0.4.0_p20170219:20180521-204425.log
Created attachment 532612 [details] emerge-history.txt
Created attachment 532614 [details] environment
Created attachment 532616 [details] etc.portage.tbz2
Created attachment 532618 [details] temp.tbz2
Thanks, I'll try to replicate the issue next weekend.
I wasn't able to reproduce the issue again. Do you record CPU/IO/memory usage and load? That could theoretically also be an issue. At least the same tests failed again, so it isn't a random issue but rather intermittent.
Handing the bug off to the new maintainer of dev-util/bats.
Not sure what i am looking at here. I think we need a repro-case for 1.2.1 and an arch that is affected by it.
In fact the latest stable for amd64 (which seems to have been the problem) is 1.2.1. So i am closing this because it is for 0.4.0_p20170219 While the old ebuild might still be affected, the resolution might just be retiring it in favour of the newer one. Please re-open if it happens again with that newer version.