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

[Po-Hsu Lin]

On Tue, Jun 8, 2021 at 2:11 PM Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com> wrote:
>
> 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.

Indeed.
This is more likely a case that people run it manually on a long-running
instance with a long existing autotest directory (which we don't have in our
current setup for SRU, that's probably the reason why the version number for
tests in autotest-client-tests was untouched for a while), it's unusual but
not impossible.

I just found that we can use autotest/client/shared/git.py for git related
commands in our tests:
    from autotest.client.shared import git
    git.get_repo(REPO_LINK)

It will try to fetch the repo in /tmp or any other specified places, if the
repo exists it will do a hard reset and fetch again.

But since this has become rather trivial now, I think we can just give it a
go and iterate from this patch.

Acked-by: Po-Hsu Lin <po-hsu.lin at canonical.com>
Applied and pushed.

Thanks
Sam