<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jun 4, 2015 at 11:22 AM, Gergo Tisza <span dir="ltr"><<a href="mailto:gtisza@wikimedia.org" target="_blank">gtisza@wikimedia.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Thu, Jun 4, 2015 at 10:34 AM, Dan Duvall <span dir="ltr"><<a href="mailto:dduvall@wikimedia.org" target="_blank">dduvall@wikimedia.org</a>></span> wrote:<br></span><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span><div class="gmail_quote">In other words, there were 12 non-merge commits made yesterday to MobileFrontend alone; that's around 9 hours of run time for the tests to complete which, on a single instance, will have to be run in serial to ensure the tests don't interfere with one another; that essentially nullifies the more expedient feedback that you're hoping to gain.<br></div></span><div class="gmail_quote"><div><br></div><div>You could scale up the number of instances in the pool, but at that point the ad hoc setup will be duplicating a large portion of our shared CI infrastructure, which brings me to the next unanswered question: Who is going to maintain this setup? I don't mean to be a naysayer here, but I worry about the effects of implementing such a complex—and seemingly volatile setup—without a clear understanding within Infrastructure or Reading about its real value or long-term maintenance burden. Perhaps this is misplaced anxiety, but this screams tech debt incarnate.</div></div></div></div></blockquote><div><br></div></span><div>A separate instance (or full serialization) for each test seems like an enormous waste of resources.</div></div></div></div></blockquote><div><br></div><div>Mostly definitely. We've talked about using LXC (or perhaps Docker) to achieve the isolation without having to spin up a new instance for each build. The trick here is to achieve a setup where we can quickly and cleanly initialize the workspace while still facilitating some level of caching for expensive dependencies (composer, npm, bundler) outside of its environment—containers seem like the right option for this.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>At worst, each test needs a separate database and can share the VM and run fully parallel; setting up a new database from a dump of a known good state should be in the seconds range. Ideally, most tests would be read-only and marked as such, and those could run on the same DB.</div></div></div></div></blockquote><div><br></div><div>I'm not sure we'll ever be able to assume atomic read-only tests, maybe for integration tests but not end-to-end tests—another reason why I think it's important to differentiate our tests—which is why we need the isolation.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>_______________________________________________<br>
QA mailing list<br>
<a href="mailto:QA@lists.wikimedia.org">QA@lists.wikimedia.org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/qa" target="_blank">https://lists.wikimedia.org/mailman/listinfo/qa</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Dan Duvall<div>Automation Engineer</div><div><a href="http://wikimediafoundation.org" target="_blank">Wikimedia Foundation</a><br></div></div></div>
</div></div>