https://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842021-05-05T12:46:19ZopenSUSE Project Management ToolopenQA Project - action #92164: t/01-test-utilities.t fails in 'test would have failed' in unrelated PRhttps://progress.opensuse.org/issues/92164?journal_id=4040742021-05-05T12:46:19Zokurzokurz@suse.com
<ul></ul><p>On my work notebook local environment 1k runs (!) have succeeded, in circleCI a second run failed: <a href="https://app.circleci.com/pipelines/github/os-autoinst/openQA/6386/workflows/ba9d9a66-05f7-4c14-b2ea-921dd5a2e272/jobs/60180/steps" class="external">https://app.circleci.com/pipelines/github/os-autoinst/openQA/6386/workflows/ba9d9a66-05f7-4c14-b2ea-921dd5a2e272/jobs/60180/steps</a> . Anyone an idea?</p>
openQA Project - action #92164: t/01-test-utilities.t fails in 'test would have failed' in unrelated PRhttps://progress.opensuse.org/issues/92164?journal_id=4040772021-05-05T12:47:16Zokurzokurz@suse.com
<ul></ul><p>mkittler mentioned maybe it's because of coverage analysis. Trying with</p>
<pre><code>runs=2000 count_fail_ratio make coverage KEEP_DB=1 TESTS=t/01-test-utilities.t
</code></pre>
<p>but that fails for me with <code>Can't read /home/okurz/local/os-autoinst/openQA/cover_db/runs/1620218733.13161.31806/cover.14 with Sereal: Sereal: Error: Bad Sereal header: Not a valid Sereal document. at offset 1 of input at srl_decoder.c line 600 at /usr/lib/perl5/vendor_perl/5.26.1/x86_64-linux-thread-multi/Devel/Cover/DB/IO/Sereal.pm line 34, <$fh> chunk 1.</code>. I think I had something like this already in the past. What's missing now?</p>
openQA Project - action #92164: t/01-test-utilities.t fails in 'test would have failed' in unrelated PRhttps://progress.opensuse.org/issues/92164?journal_id=4041462021-05-05T14:33:23Zokurzokurz@suse.com
<ul></ul><p>Using <a href="https://github.com/os-autoinst/openQA/pull/3885" class="external">https://github.com/os-autoinst/openQA/pull/3885</a> as workaround I can proceed. Running tests with coverage now in a loop locally …</p>
openQA Project - action #92164: t/01-test-utilities.t fails in 'test would have failed' in unrelated PRhttps://progress.opensuse.org/issues/92164?journal_id=4045242021-05-06T10:00:40Zokurzokurz@suse.com
<ul><li><strong>Due date</strong> set to <i>2021-05-19</i></li><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Feedback</i></li><li><strong>Priority</strong> changed from <i>High</i> to <i>Normal</i></li></ul><p>experiment finished, <code>runs=2000 count_fail_ratio make coverage KEEP_DB=1 TESTS=t/01-test-utilities.t</code> yields:</p>
<pre><code>## count_fail_ratio: Run: 2000. Fails: 0. Fail ratio 0%
</code></pre>
<p>so at least not easily reproducible this way with coverage locally, must be something else. Any other ideas what to try?</p>
openQA Project - action #92164: t/01-test-utilities.t fails in 'test would have failed' in unrelated PRhttps://progress.opensuse.org/issues/92164?journal_id=4047222021-05-06T13:42:33Ztinitatina.mueller+trick-redmine@suse.com
<ul></ul><p>Maybe not a new observation, but at least I wanted to note it:<br>
I ran the tests on CircleCI in a loop (with a dummy fail and RETRY), and in the failing cases the output</p>
<pre><code>ok 1 - warning logged
...
</code></pre>
<p>always appeared around 40 seconds after the note</p>
<pre><code># waiting at most 42 seconds for SIGCHLD (sleep is supposed to be interrupted by SIGCHLD)
</code></pre>
<p>So at least we know that the SIGCHLD is <em>not</em> interrupting the sleep in this case.</p>
<p>Full log of 20 runs:<br>
<a href="https://app.circleci.com/pipelines/github/perlpunk/openQA/167/workflows/a5c11032-e6b3-4bf4-a548-70a029d0f4c0/jobs/743" class="external">https://app.circleci.com/pipelines/github/perlpunk/openQA/167/workflows/a5c11032-e6b3-4bf4-a548-70a029d0f4c0/jobs/743</a></p>
openQA Project - action #92164: t/01-test-utilities.t fails in 'test would have failed' in unrelated PRhttps://progress.opensuse.org/issues/92164?journal_id=4047642021-05-06T14:17:49Ztinitatina.mueller+trick-redmine@suse.com
<ul></ul><p>I added more logging, and it appears that the SIGWARN handler setup in <code>OpenQA::Test::Utils::_setup_sub_process</code> is simply called <em>before</em> the SIGCHLD handler has been installed.</p>
openQA Project - action #92164: t/01-test-utilities.t fails in 'test would have failed' in unrelated PRhttps://progress.opensuse.org/issues/92164?journal_id=4047972021-05-06T15:02:14Ztinitatina.mueller+trick-redmine@suse.com
<ul><li><strong>Assignee</strong> changed from <i>okurz</i> to <i>tinita</i></li></ul><p>PR: <a href="https://github.com/os-autoinst/openQA/pull/3890" class="external">https://github.com/os-autoinst/openQA/pull/3890</a></p>
openQA Project - action #92164: t/01-test-utilities.t fails in 'test would have failed' in unrelated PRhttps://progress.opensuse.org/issues/92164?journal_id=4048542021-05-06T20:14:32Zokurzokurz@suse.com
<ul></ul><p>This is a great finding! I just hope we find a better way than sleep 1 which I despise :D</p>
openQA Project - action #92164: t/01-test-utilities.t fails in 'test would have failed' in unrelated PRhttps://progress.opensuse.org/issues/92164?journal_id=4051962021-05-07T11:53:46Ztinitatina.mueller+trick-redmine@suse.com
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>Resolved</i></li></ul> openQA Project - action #92164: t/01-test-utilities.t fails in 'test would have failed' in unrelated PRhttps://progress.opensuse.org/issues/92164?journal_id=4060392021-05-10T12:57:36Zmkittlermarius.kittler@suse.com
<ul></ul><p>Not sure whether it helped: <a href="https://github.com/os-autoinst/openQA/pull/3877#issuecomment-836523675" class="external">https://github.com/os-autoinst/openQA/pull/3877#issuecomment-836523675</a></p>
openQA Project - action #92164: t/01-test-utilities.t fails in 'test would have failed' in unrelated PRhttps://progress.opensuse.org/issues/92164?journal_id=4072572021-05-14T09:40:54Zokurzokurz@suse.com
<ul></ul><p>We assume that the last failure was in an older branch. We assume the problem is resolved, otherwise we can reopen or try in a new ticket.</p>