<div dir="ltr"><div dir="ltr"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 18, 2021 at 5:20 AM Jakob Naucke <<a href="mailto:naucke@linux.vnet.ibm.com">naucke@linux.vnet.ibm.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 17.08.21 20:59, Cameron Meadors wrote:<br>
> The comment is that there is value in separating e2e/integration tests<br>
> that are not version specific from component/unit tests that are.<br>
<br>
That's valid, but...<br>
<br>
> I am not sure if we know which tests are version specific or not and<br>
> if we are ready to make a forward looking decisions like this now, but<br>
> I think keeping the test repo but only having non-versions specific<br>
> tests there would solve the problems that have been presented.<br>
<br>
...wouldn't this mean that we could never have E2E version-specific<br>
tests? I.e., to test a new feature E2E, it has to be released as stable<br>
first? I don't think that could work.<br>
<br></blockquote><div>I see how this could sound confusing.  In my mind there are two ways the tests in the tests repo can be used.  There are CI run , which are regression and only include tests for released features.  Then there are automated test runs for feature verification.  The case you are talking about is the later case.  There would need to be some very high level branching in the test repo that follows releases in the kata-container repo to manage this. Main or stable release branches in tests would only container regression tests.  New tests would go in branches for a new release.</div><div><br></div><div>In other words.  new features are version specific in that they only exist in release foo and newer, but once the feature is released.  If the feature does not change with each new release then that would be considered a non-version specific feature.  As i understand it, we only really support the latest release in anyway.  The process to manage running the right tests on the right versions should be simple.  One common way is to couple it with feature flags so tests only run for enabled features.  But that requires a lot of work to put in place, easy once there.</div><div><br></div><div>Not trying to trivialize this issue.  I am just throwing out how I have managed testing for other projects.  That may not work here.  There is also the fact that the tests repo has a lot of stuff in it that may or may not work the way people want it to work.  There might be some clever changes that take care of multiple issues.    </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>
Jakob Naucke<br>
IBM Deutschland Research & Development GmbH<br>
Vorsitzender des Aufsichtsrats: Gregor Pillen<br>
Geschäftsführung: Dirk Wittkopp; Sitz der Gesellschaft: Böblingen<br>
Registergericht: Amtsgericht Stuttgart, HRB 243294<br>
<br>
</blockquote></div></div>