<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Jul 20, 2015 at 1:36 PM R. David Murray <<a href="mailto:rdmurray@bitdance.com">rdmurray@bitdance.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, 20 Jul 2015 19:49:50 -0000, Brett Cannon <<a href="mailto:bcannon@gmail.com" target="_blank">bcannon@gmail.com</a>> wrote:<br>
> In my ideal workflow scenario, these are the steps a patch would take:<br>
><br>
>    1. Issue is created<br>
>    2. Issue is triaged to have right affected versions, etc.<br>
>    3. Patch is uploaded<br>
>    4. CI kicks the patch off for *all* branches and OSs that are affected<br>
<br>
This may be a non-starter.  Instead, I believe it will be much more<br>
practical to have core dev review first, with a way for the core dev to<br>
trigger the CI run.  Specifically, I as a buildbot owner do not want<br>
arbitrary patch uploads to be able to run on my servers.  Nor will<br>
infrastructure allow this on any platform they control (we asked).<br>
<br>
If there is a CI system out there that will allow this and whose free<br>
(or donated) tier will support our test suite, then it might be viable,<br>
but I doubt very much that it will cover all our platforms.  That may<br>
not be a blocker, though...this CI could just be a "basic check" run,<br>
with the buildbots continuing to provide the all-supported-platforms<br>
(and then some) post-commit check they do now.<br>
<br>
On the other hand, steps 1 to 3 are a problem regardless.  It often<br>
happens that a patch is uploaded before triage is done, and the branches<br>
are not set correctly.  And you'd need some way to re-trigger a build<br>
anyway.  So, I think really we want triggered CI builds, not automatic<br>
ones.<br></blockquote><div><br></div><div>That's all very convincing and I'm happy to let CI be a privileged, triggered event if we stick with buildbots for our testing fleet.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
We already have something that Kushal built that will do the triggered<br>
build for the linux platform...I haven't played with it yet because I<br>
haven't had time to do any full review/commit cycles since he made it<br>
available.  It does not yet report back to the tracker, but I don't<br>
think that will be hard to add (he may have already written the code, in<br>
fact).  I think it just does default and not all branches, but I'm not<br>
sure.  Regardless, it is a place to start.<br></blockquote><div><br></div><div>I haven't played with it myself for the same reasons as you, David. I'm very appreciative to have the tool available today, although I would like to see it integrated with Roundup so I don't have to log into IRC just to fire off a CI run. Plus Linux obviously doesn't cover everything.</div><div><br></div><div>Ideally we would then gate committal on passing CI and then commit it. The issue with that, though, is possible race conditions on commits where you would need to run the CI again to verify that the tests all still pass once the commit landed. So I don't think we can avoid at least two CI runs per patch (making sure it's basically sound and then verifying that it doesn't require a rollback).</div></div></div>