<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
</span>OK - is there any way that I can assist?<br>
<br>
What about the challenges I discussed in my initial mail related to<br>
long AIO build times etc..?<br>
<div class="m_8944483036875771703m_-7015869306531741194m_997264563947859564HOEnZb"><div class="m_8944483036875771703m_-7015869306531741194m_997264563947859564h5"><br></div></div></blockquote><div><br></div><div>I think there are some options, but the idea we're going with at the moment is to look into setting this up as a periodical - we're at about 1hr per full AIO build, so i don't think we'll be able to (reliably) keep the gate to under 1hr30 if we include an upgrade scenario - unless we have some ideas around how we build the initial AIO build - that could cut down the time.</div><div><br></div><div>That's mostly conjecture at this point though - since we don't have a test scenario setup. </div><div><br></div><div>The work we can do now, which if you're able to help with would be really great, is:</div><div><br></div><div>Plan how we execute the actual job - at the moment the aio is run through a script (scripts/gate-check-commit.sh) - the upgrade test would have to hook into this (using the SCENARIO=upgrade) var, or we'd need to look into changing this method up entirely (role gates all use tox for example).</div><div><br></div><div>If the current method is sufficient we need to set the job up. Once we have a working scenario (regardless of time taken for the test), we can look into ways we can ensure this gets run, and what options we have.</div><div><br></div><div>Andy</div><div><br></div></div></div></div>