<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 15 Jan 2021, at 16:07, Cameron Meadors <<a href="mailto:cmeadors@redhat.com" class="">cmeadors@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">David,<div class=""><br class=""></div><div class="">All the issues you have pointed out are definitely valid and need to be resolved. I think all t of these have been discussed in the ongoing effort to improve Upstream CI. The suggestion of merging the tests repo has been brought up before with some debate. I would like to point out that we also have a CI repo that is separate as well that is also part of testing and CI.</div><div class=""><br class=""></div><div class="">The current approach to improvements are described in <a href="https://docs.google.com/document/d/15YobCIUFMEvdNIGem0CJ_g30hJY4YH5Lr6ty7_8ASPY/edit" class="">https://docs.google.com/document/d/15YobCIUFMEvdNIGem0CJ_g30hJY4YH5Lr6ty7_8ASPY/edit</a> It takes the approach of trying to understand and clean up what currently exists and solve he issues of test maintenance, debugging failures, and local execution of CI tests. I think all of these can be resolved to various degrees without merging repos. That is not an argument against the idea but a preference to do what we can that is not dependent on where the code/tests lives.</div><div class=""><br class=""></div><div class="">Your point 2 is the most compelling to me for merging repos, Having tests committed along with new features would be a great place be. Currently I don't see many tests being committed, unit, manual verification, or automation. Maybe I am missing them (can't review every PR). I would like to understand if the state of having separate test repos is a factor in not getting more tests with code changes, or if the other issues are really the cuplrit. I suspect the later because I have seen 100% code coverage through integration tests being committed separately along with code changes when integration tests were in a separate repo (unit tests in repo with code).</div></div></div></blockquote><div><br class=""></div><div>It is definitely a factor.</div><div><br class=""></div><div>- If you push the test first, then other commits will presumably fail.</div><div><br class=""></div><div>- If you push the code first, chances are it does not pass the test in the CI.</div><div><br class=""></div><div>So right now, pushing a test is hard (on a scale of 1 to 10, I'd say a solid 20).</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">That's my two cents. Thank you for reaffirming that the issues we identified are still issues and that we really need to put more effort in to resolve them.</div><div class=""><br class=""></div><div class=""><br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 15, 2021 at 8:27 AM David Gibson <<a href="mailto:david@gibson.dropbear.id.au" class="">david@gibson.dropbear.id.au</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Jan 15, 2021 at 10:49:34AM +0100, Christophe de Dinechin wrote:<br class="">
> <br class="">
> <br class="">
> > On 15 Jan 2021, at 04:29, David Gibson <<a href="mailto:david@gibson.dropbear.id.au" target="_blank" class="">david@gibson.dropbear.id.au</a>> wrote:<br class="">
> > <br class="">
> > Hi all,<br class="">
> > <br class="">
> > I'm a pretty recently started Kata contributor. One of many things I<br class="">
> > found frustrating when I started working on Kata was the way the code<br class="">
> > was split into a whole batch of repositories. I'm relieved that<br class="">
> > they're now merged together for Kata 2.x.<br class="">
> > <br class="">
> > However, the tests repository is still separate, and AIUI there are no<br class="">
> > plans to integrate it. I still find that really annoying, so I want<br class="">
> > to make the case for integrating it into the kata-containers<br class="">
> > repository as well.<br class="">
> > <br class="">
> > 1. It removes delays fixing test bugs<br class="">
> > <br class="">
> > On several occasions when working on code changes, I've hit CI<br class="">
> > failures due to what turn out to be bugs in the tests code. These<br class="">
> > have often been problems with static checks essentially unrelated to<br class="">
> > what I'm actually trying to accomplish.<br class="">
> > <br class="">
> > To deal with this, I've had to file a separate issue and PR against<br class="">
> > the tests repo, wait for that to be tested and reviewed, and only then<br class="">
> > can I resume work on what I was actually trying to do. Especially<br class="">
> > since I'm a different timezone from most of the Kata team, that can<br class="">
> > easily be several days of delay.<br class="">
> > <br class="">
> > If the tests were integrated, I could include a fix for the test as a<br class="">
> > commit in the same PR, it would automatically fix the CI for that PR<br class="">
> > and could be reviewed with the same batch.<br class="">
> > <br class="">
> > 2. Allows tests to be commited along with new features<br class="">
> > <br class="">
> > Obviously it's desirable for new features to come with tests for those<br class="">
> > features. Integrating the tests repo means that can be done in the<br class="">
> > same PR, reducing the amount of github busywork involved in doing so.<br class="">
> > It also means the code and tests can be reviewed and discussed in the<br class="">
> > same place.<br class="">
> > <br class="">
> > In addition to being more convenient, that means we don't need to<br class="">
> > rerun basically the same tests for both the code PR and the tests PR.<br class="">
> > That means less demand on the CI infrastructure, which helps everyone.<br class="">
> > <br class="">
> > 3. Testing scripts can be simplified<br class="">
> > <br class="">
> > AFAICT the current scripts in the tests code have a bunch of<br class="">
> > conditionals for various different configurations: Kata1 vs. Kata 2.x,<br class="">
> > Rust agent vs. Go agent amongst others. If the tests repo is<br class="">
> > integrated we can cut down the test scripts to just the cases that are<br class="">
> > relevant for the current version of the code.<br class="">
> > <br class="">
> > Understanding how the test scripts work is a real barrier to debugging<br class="">
> > Kata at the moment, so simplifying them is valuable.<br class="">
> > <br class="">
> > 3. Removes a barrier to running CI tests locally<br class="">
> > <br class="">
> > At the moment debugging CI failures is really painful, because<br class="">
> > duplicating the problem in a debuggable environment is extremely<br class="">
> > awkward. One (certainly not the only) reason for that is that the<br class="">
> > code repo and tests repo need to be both assembled together in a<br class="">
> > suitable environment. The CI scripts do that, but this often involves<br class="">
> > downloading one or the other repo from a global URL. If you want to<br class="">
> > do frequently repeated tests on a local repo while debugging, that has<br class="">
> > to be worked around.<br class="">
> > <br class="">
> > If tests and code are in the same repo, it removes the need to<br class="">
> > download either one from a global URL, making it easier to replicate<br class="">
> > the CI test in a local environment and with an ad-hoc tree. It also<br class="">
> > allows some further simplifications of the CI scripts.<br class="">
> > <br class="">
> > <br class="">
> > I could probably come up with more reasons, but those 3 seem like a<br class="">
> > solid start.<br class="">
> <br class="">
> Solid +1 from me ;-)<br class="">
> <br class="">
> Now, in the interest of exhaustivity, can you think of reasons not to?<br class="">
<br class="">
I really can't, but I'm kind of assuming someone will tell me some.<br class="">
<br class="">
> I can think of a couple, but I'm interested in your viewpoint here.<br class="">
> <br class="">
<br class="">
-- <br class="">
David Gibson | I'll have my music baroque, and my code<br class="">
david AT <a href="http://gibson.dropbear.id.au/" rel="noreferrer" target="_blank" class="">gibson.dropbear.id.au</a> | minimalist, thank you. NOT _the_ _other_<br class="">
| _way_ _around_!<br class="">
<a href="http://www.ozlabs.org/~dgibson" rel="noreferrer" target="_blank" class="">http://www.ozlabs.org/~dgibson</a><br class="">
_______________________________________________<br class="">
kata-dev mailing list<br class="">
<a href="mailto:kata-dev@lists.katacontainers.io" target="_blank" class="">kata-dev@lists.katacontainers.io</a><br class="">
<a href="http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev" rel="noreferrer" target="_blank" class="">http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev</a><br class="">
</blockquote></div>
</div></blockquote></div><br class=""></body></html>