NAK/cmnt: [ACT][PATCH 1/4] UBUNTU: SAUCE: fix git clone failures and setups not being idempotent

Krzysztof Kozlowski krzysztof.kozlowski at
Tue Jun 8 06:11:46 UTC 2021

On 07/06/2021 16:02, Po-Hsu Lin wrote:
> I agree that the second run on the same SUT should not alter the test
> result.
> We don't have this failed-with-second-run issue before because we will
> clean up the autotest directory by rsync'ing a clean tree from our
> jenkins server no matter it's a freshly deployed system or a manually
> provisioned one. The old autotest/client/tmp/<test-suite> directory
> will be gone, the test will start fresh.
> This is defintely an issue we need to deal with if we want to run tests
> for multiple times manually on the same SUT (I just clean out the
> aformentioned tmp directory manually).

I would expect that's regular process for autotest since they
implemented this setup() caching (being called only once).

> As discussed on Mattermost, I think this fix is base on the assumption
> that the change to autotest f6e444df45f45 ("UBUNTU: SAUCE: fix missing
> setup on second run") is correct.

Mentioned autotest change indeed looks wrong. However this does not make
this change here wrong, either.

Consider case when test version is bumped, while being executed for
second time. The setup() will be called and all git clones will fail.

Making setup() idempotent or resistent to existing stuff is good idea IMHO.

> With a quick test on the ubuntu_ltp_syscalls test, this will make the
> test clone the source and build it twice before running the actual
> syscall tests from LTP. From this fact it looks like the setup() was
> called twice with one execution.
> On the other hand, this issue does not exist in libhugetlbfs test,
> which will do a git clone for an external source as well, therefore
> it doesn't look like a real fix to me.

Best regards,

More information about the kernel-team mailing list