<div dir="ltr">Based on additional IRC clarifications, seems simple enough. I'll give it a shot.<div><br></div><div>-Dave</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 31, 2017 at 6:44 PM, James E. Blair <span dir="ltr"><<a href="mailto:corvus@inaugust.com" target="_blank">corvus@inaugust.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Something we need to be aware of for the Zuul v3 migration is the use of<br>
the zuul-cloner tool.  In many of the more "standardized" jobs, this<br>
will be taken care of either by the fact that we have reworked the jobs<br>
into native v3 format (eg unittests), or the migration script will map<br>
existing JJB builders (zuul-git-prep) into v3 equivalents.  However,<br>
there are many jobs which perform their own zuul-cloner actions, some<br>
defined in project-config, and others scattered throughout project<br>
repos.<br>
<br>
In those cases, it would take considerable time to track down all the<br>
uses and put a migration plan in place.  Instead, I propose a<br>
compatibility shim.<br>
<br>
We can create a new script which takes the same arguments as<br>
zuul-cloner.  It will ignore most of the arguments except the repos and<br>
the destination which it will use to copy the specified repos from<br>
~zuul/src/<a href="http://git.openstack.org/." rel="noreferrer" target="_blank">git.openstack.org/.</a>.<wbr>. to the destination.<br>
<br>
When jobs run this script, they will get the Zuul v3 prepared repos, and<br>
they will be placed in the locations that the job expects.  If it can<br>
support the clonemap file, that's even better.<br>
<br>
If jobs provide arguments to zuul-cloner which alter its behavior about<br>
which branches are checked out, they may fail with this plan.  It will<br>
be easy to correct this by altering the Zuul v3 job configuration to<br>
specify override branches, however, this is likely a situation which<br>
will require human intervention to fix.  Ideally, there won't be very<br>
many of these cases.<br>
<br>
Additionally, any of the repos used by zuul-cloner in a job will need to<br>
be specified as required-projects in Zuul.  Determining this<br>
automatically is hard, but we can handle many cases with heuristics.<br>
For example, a substantial number of these jobs are for neutron<br>
plugins.  We can easily tell the migration script to add 'neutron' as a<br>
required-project for all such jobs.<br>
<br>
Zuul-cloner is baked into our images.  In order to allow us to easily<br>
move between Zuul v2 and v3, I propose we have the Zuul v3 base job<br>
automatically replace the zuul-cloner script with the one proposed here,<br>
so we can continue to use the same images for Zuul v2 and v3 during the<br>
transition.<br>
<br>
Ultimately, it would be useful to have this in Zuul v3 for other users.<br>
It probably makes the most sense to add this to the feature/zuulv3<br>
branch as the zuul-cloner binary.  We can release it as a deprecated<br>
migration tool.  The base job can just wget it from git.o.o for<br>
simplicity.  To facilitate that, we may want to ensure the script is<br>
self-contained.  After we fully migrate to v3, we can bake it into the<br>
image again.<br>
<br>
-Jim<br>
<br>
______________________________<wbr>_________________<br>
OpenStack-Infra mailing list<br>
<a href="mailto:OpenStack-Infra@lists.openstack.org">OpenStack-Infra@lists.<wbr>openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-infra</a></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>David Shrewsbury (Shrews)<br></div></div></div>
</div>