<div dir="ltr">Cc'ing QA so they can see my latest reply.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 4, 2015 at 10:42 AM, Jon Robson <span dir="ltr"><<a href="mailto:jrobson@wikimedia.org" target="_blank">jrobson@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">Gather tests take around <span style="color:rgb(51,51,51);font-family:Helvetica,Arial,sans-serif;font-size:13px;text-align:right">7 min 21s to run [1]</span><div><span style="color:rgb(51,51,51);font-family:Helvetica,Arial,sans-serif;font-size:13px;text-align:right">Smoke tests 4 mins [2]</span></div><div><span style="color:rgb(51,51,51);font-family:Helvetica,Arial,sans-serif;font-size:13px;text-align:right">These would be the initial target.</span></div><div><span style="color:rgb(51,51,51);font-family:Helvetica,Arial,sans-serif;font-size:13px;text-align:right"><br></span></div><div><span style="color:rgb(51,51,51);font-family:Helvetica,Arial,sans-serif;font-size:13px;text-align:right">Yesterday 3 patches got merged that had been sitting in Gerrit for approx 3 days that caused the test to break in both Gather and MobileFrontend.</span></div><div><span style="color:rgb(51,51,51);font-family:Helvetica,Arial,sans-serif;font-size:13px;text-align:right">Had we run the smoke tests on these tests at some point during those 3 days we would have been able to fix them pre-merging.</span></div><div><span style="color:rgb(51,51,51);font-family:Helvetica,Arial,sans-serif;font-size:13px;text-align:right"><br></span></div><div><span style="color:rgb(51,51,51);font-family:Helvetica,Arial,sans-serif;font-size:13px;text-align:right">Personally I am fine with the delay and running the test jobs one at a time. </span><span style="color:rgb(51,51,51);font-family:Helvetica,Arial,sans-serif;font-size:13px;text-align:right">I see this as a low risk useful grass routes experiment by a smaller team that can be fed up to the rest of the Foundation and benefit all teams.  </span><span style="color:rgb(51,51,51);font-family:Helvetica,Arial,sans-serif;font-size:13px;text-align:right">I don't see this as duplicating efforts rather than investigating something we know we all want but on a smaller scale.</span></div><div><span style="color:rgb(51,51,51);font-family:Helvetica,Arial,sans-serif;font-size:13px;text-align:right"><br></span></div><div><div><span style="color:rgb(51,51,51);font-family:Helvetica,Arial,sans-serif;font-size:13px;text-align:right">I could easily imagine having an unofficial convention that something can only be merged once the browser tests have been verified to pass by the bot.</span></div></div><div><br></div><div><span style="color:rgb(51,51,51);font-family:Helvetica,Arial,sans-serif;font-size:13px;text-align:right">[1] </span><font color="#333333" face="Helvetica, Arial, sans-serif"><a href="https://integration.wikimedia.org/ci/view/Mobile/job/browsertests-Gather-en.m.wikipedia.beta.wmflabs.org-linux-chrome-sauce/144/testReport/" target="_blank">https://integration.wikimedia.org/ci/view/Mobile/job/browsertests-Gather-en.m.wikipedia.beta.wmflabs.org-linux-chrome-sauce/144/testReport/</a></font></div><div><font color="#333333" face="Helvetica, Arial, sans-serif">[2] <a href="https://integration.wikimedia.org/ci/view/Mobile/job/browsertests-MobileFrontend-SmokeTests-linux-chrome-sauce/140/testReport/(root)/" target="_blank">https://integration.wikimedia.org/ci/view/Mobile/job/browsertests-MobileFrontend-SmokeTests-linux-chrome-sauce/140/testReport/(root)/</a></font></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">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></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div class="gmail_extra"><span><div class="gmail_quote">On Wed, Jun 3, 2015 at 7:58 PM, Bryan Davis <span dir="ltr"><<a href="mailto:bd808@wikimedia.org" target="_blank">bd808@wikimedia.org</a>></span> wrote:<br></div></span><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><span>On Wed, Jun 3, 2015 at 8:09 PM, Jon Robson <<a href="mailto:jrobson@wikimedia.org" target="_blank">jrobson@wikimedia.org</a>> wrote:<br></span><span>
> The bits I need help on:<br>
> * I need a way to watch Gerrit for new patches, and then checkout those<br>
> patches and trigger my script. Anyone want to write it?<br>
<br>
</span></span><span>If this is going to run in labs, the trivially easy thing to do would<br>
be to setup a vm as a Jenkins slave and let Zuul notify Jenkins to<br>
fire a custom job pinned to our slave. Alternately there is a redis<br>
feed of the commits that can be used to watch for things. That is what<br>
powers grrrit-wm and some other bots. I've never used it but Kunal<br>
could probably give us some quick pointers.<br></span></blockquote><div><br></div><div>Setup isn't the problem. The real challenges center around performance and isolation: How do you plan to run a test suite that takes ~ 45 minutes to complete for every commit to your repo on a single labs instance, and ensure the level of isolation between concurrent runs that the suite will require?</div><div><br></div><div>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.</div><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><br></div><div>It seems clear to everyone that the current setup is not ideal, which is why we've been working hard to improve it.[1][2] In the meantime, wouldn't it be wise not to duplicate our efforts but to dedicate time squashing the elephant in the room: Fix, refactor, or delete the tests. Regardless of how you hear that they are broken, 45 minutes after your commit is merged or 24 hours; fix them. Grab someone from RelEng if the backtrace is obscure or utterly unintelligible, but fix them.</div><div><br></div><div>[1] <a href="http://www.mediawiki.org/wiki/Continuous_integration/Architecture/Isolation" target="_blank">http://www.mediawiki.org/wiki/Continuous_integration/Architecture/Isolation</a></div><div>[2] <a href="https://phabricator.wikimedia.org/T47499" target="_blank">https://phabricator.wikimedia.org/T47499</a></div><div><br></div></div><span>-- <br><div><div dir="ltr">Dan Duvall<div>Automation Engineer</div><div><a href="http://wikimediafoundation.org" target="_blank">Wikimedia Foundation</a><br></div></div></div>
</span></div></div>
<br></div></div><span class="">_______________________________________________<br>
reading-wmf mailing list<br>
<a href="mailto:reading-wmf@lists.wikimedia.org" target="_blank">reading-wmf@lists.wikimedia.org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/reading-wmf" target="_blank">https://lists.wikimedia.org/mailman/listinfo/reading-wmf</a><br>
<br></span></blockquote></div><br></div>
</blockquote></div><br></div>