<div dir="auto">Hi Clark,<div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">You might find the following series of commands help automate this a little more.</div><div dir="auto"><br></div><div dir="auto">git merge -s ours --no-commit feature/zuulv3</div><div dir="auto">git read-tree -u --reset feature/zuulv3</div><div dir="auto">git commit -m "replace mainline with feature/zuulv3"</div><div dir="auto"><br></div><div dir="auto">Basically it replaces the current branch contents with everything that came from feature/zuulv3, so no risk that changes get merged at all, whatever was on the master branch is ignored.</div><div dir="auto"><br><div data-smartmail="gmail_signature" dir="auto">Darragh Bailey<br>"Nothing is foolproof to a sufficiently talented fool" - unknown</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 12 Jan 2018 22:43, "Clark Boylan" <<a href="mailto:cboylan@sapwetik.org">cboylan@sapwetik.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
I think we are very close to being ready to merge the zuulv3 feature branch into master in both the Zuul and Nodepool repos. In particular we merged <a href="https://review.openstack.org/#/c/523951/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/523951/</a> which should prevent breakages for anyone using that deployment method (single_node_ci) for an all in one CI suite.<br>
<br>
One thing I've noticed is that we don't have this same handling in the lower level individual service manifests. For us I don't think that is a major issue, we'll just pin our builders to the nodepool 0.5.0 tag, do the merge, then update our configs and switch back to master. But do we have any idea if it is common for third part CI's to bypass single_node_ci and construct their own like we do?<br>
<br>
As for the actual merging itself a quick test locally using `git merge -s recursive -X theirs feature/zuulv3` on the master branch of nodepool appears to work. I have to delete the files that the feature branch deleted by hand but otherwise the merge is automated. The resulting tree does also pass `tox -e pep8` and `tox -epy36` testing.<br>
<br>
We will probably want a soft freeze of both Zuul and Nodepool then do our best to get both merged together so that we don't have to remember which project has merged and which hasn't. Once that is done we will need to repropose any open changes on the feature branch to the master branch, abandon the changes on the feature branch then delete the feature branch. Might be a good idea to merge as many feature branch changes as possible before hand?<br>
<br>
Am I missing anything?<br>
<br>
Thank you,<br>
Clark<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></div>