Checkbox-ng on Testhost does not generate a tar.xz at the end of test run

[Doug Jacobs]

[Summary]I'm running CDTS against a remote machine.
Testhost -> SUT

Due to an issue with fwts, it was suggested I try out checkbox 1.26.dev on the SUT. I also went ahead and upgraded checkbox on the testhost as well. (I was worried about version mismatches.)

I select one test unit (Power Management) to run, all the tests pass and I should get a .html, .junit.xml and .tar.xz file of the results.

However when Power Management completed, I see this:
1.64MB [00:00, 1.80MB/s, file=/home/u/.local/share/checkbox-ng/submission_2022-02-24T02.14.45.344489.html]
file:///home/u/.local/share/checkbox-ng/submission_2022-02-24T02.14.45.344489.html
32.0kB [00:00, 1.35MB/s, file=/home/u/.local/share/checkbox-ng/submission_2022-02-24T02.14.45.344489.junit.xml]
file:///home/u/.local/share/checkbox-ng/submission_2022-02-24T02.14.45.344489.junit.xml
Problem with a '2_tar_file' report using 'com.canonical.plainbox::tar' exporter sent to '/home/u/.local/share/checkbox-ng/submission_2022-02-24T02.14.45.344489.tar.xz' transport.

There is no .tar.xz file.

[Steps to reproduce]
Setup CDTS on a testhost and SUT.
Run cdts.odm-certification on testhost
Select 20.04 Desktop Automated tests
Select Power Management (it's short and quick.)

[Expected result]
Tests should pass, you should get all 3 output files automatically.

[Actual result]
You'll see the .xml and .html files generated but there's an error for the tarball.

[Failure rate]
100%

[Additional information]
CID:
SKU:
system-manufacturer: Dell Inc.
system-product-name: G5 5590
bios-version: 0.7.8
CPU: Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz (12x)
GPU: 00:02.0 Display controller [0380]: Intel Corporation Device [8086:3e9b]
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:1f50] (rev a1)
kernel-version: 5.11.0-40-generic

[Stage]
Issue reported and logs collected right after it happened

[Doug Jacobs (djacobs98)]

Automatically attached

[Doug Jacobs (djacobs98)]

Automatically attached

[Doug Jacobs (djacobs98)]

Automatically attached

[Maciej Kisielewski (kissiel)]

This got fixed in #1960584.