<div dir="ltr"><div>See inline below,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 8, 2021 at 2:12 AM Krzysztof Kozlowski <<a href="mailto:krzysztof.kozlowski@canonical.com">krzysztof.kozlowski@canonical.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 07/06/2021 16:02, Po-Hsu Lin wrote:<br>
> I agree that the second run on the same SUT should not alter the test<br>
> result.<br>
> <br>
> We don't have this failed-with-second-run issue before because we will<br>
> clean up the autotest directory by rsync'ing a clean tree from our<br>
> jenkins server no matter it's a freshly deployed system or a manually<br>
> provisioned one. The old autotest/client/tmp/<test-suite> directory<br>
> will be gone, the test will start fresh.<br>
> <br>
> This is defintely an issue we need to deal with if we want to run tests<br>
> for multiple times manually on the same SUT (I just clean out the<br>
> aformentioned tmp directory manually).<br>
<br>
I would expect that's regular process for autotest since they<br>
implemented this setup() caching (being called only once).<br></blockquote><div><br></div><div>+1 , Running the test setup() should always be step one. Even if the test has already been run on the SUT. I feel that is the correct workflow, i never like the autotest versioning scheme that required </div><div>the version to increment `foo+=1` </div><div><br></div><div>Autotest is old and EOL. it's no longer maintained, so for the time being we gotta fix the pieces that do not work correctly. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
> As discussed on Mattermost, I think this fix is base on the assumption<br>
> that the change to autotest f6e444df45f45 ("UBUNTU: SAUCE: fix missing<br>
> setup on second run") is correct.<br>
<br>
Mentioned autotest change indeed looks wrong. However this does not make<br>
this change here wrong, either.<br>
<br>
Consider case when test version is bumped, while being executed for<br>
second time. The setup() will be called and all git clones will fail.<br>
<br>
Making setup() idempotent or resistent to existing stuff is good idea IMHO.<br></blockquote><div><br></div><div>Moving forward imo, all tests should be written/updated with the intention that we are not using autotest.  </div><div><br></div><div>I know that sounds sort of confusing, I'm trying to convey that each of the tests should be able to effectively and quickly accomplish their goal without </div><div>any added helpers from the autotest client program. I know and well aware that many of them are tightly intertwined with decorators and functions that call on the autotest client. </div><div>But if the test is actually under review and going through some sort of triage like Krzsztof has done, then we can take that time to fix this.</div><div><br></div><div>I believe each of the tests should indeed have a setup() that is responsible for ensuring the SUT is correctly staged prior to running the desired test. regardless of how many executions occur on the SUT</div><div><br></div><div>Sean</div><div> </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> <br>
> With a quick test on the ubuntu_ltp_syscalls test, this will make the<br>
> test clone the source and build it twice before running the actual<br>
> syscall tests from LTP. From this fact it looks like the setup() was<br>
> called twice with one execution.<br>
> <br>
> On the other hand, this issue does not exist in libhugetlbfs test,<br>
> which will do a git clone for an external source as well, therefore<br>
> it doesn't look like a real fix to me.<br>
<br>
<br>
<br>
Best regards,<br>
Krzysztof<br>
<br>
-- <br>
kernel-team mailing list<br>
<a href="mailto:kernel-team@lists.ubuntu.com" target="_blank">kernel-team@lists.ubuntu.com</a><br>
<a href="https://lists.ubuntu.com/mailman/listinfo/kernel-team" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/kernel-team</a><br>
</blockquote></div></div>