If a change has a change in the ZUUL_CHANGES for another patch, we attempt to build it (as a way to handle package dependencies) but if the ZUUL_CHANGES includes a repo that we don't package or doesn't have a stable branch we the upgrade job can break. Occassionally we get repos that are unrelated to the change but get passed because they are currently in the tripleo-ci gate.
For example, https://review.openstack.org/#/c/477637/ was gating with a change from tripleo-repos so the upgrades job got the following ZUUL_CHANGES
ZUUL_CHANGES='openstack/puppet-neutron:stable/newton:refs/changes/47/483047/1 openstack/tripleo-repos:master:refs/changes/17/466417/3 openstack/os-net-config:stable/newton:refs/changes/84/488884/2 openstack/os-net-config:stable/ocata:refs/changes/82/488882/2 openstack/puppet-tripleo:master:refs/changes/94/478894/7 openstack/networking-bgpvpn:stable/ocata:refs/changes/77/486877/1 openstack/tripleo-heat-templates:master:refs/changes/46/483846/4 openstack/puppet-nova:master:refs/changes/93/487493/3 openstack/puppet-nova:stable/ocata:refs/changes/26/487926/1 openstack/puppet-nova:stable/newton:refs/changes/27/487927/1 openstack/puppet-swift:master:refs/changes/46/483646/3 openstack/puppet-tripleo:stable/ocata:refs/changes/37/477637/3'
Unfortunately the tripleo-repos build failed (probably because it didn't have a stable/ocata branch)
http://logs.openstack.org/37/477637/3/gate/gate-tripleo-ci-centos-7-multinode-upgrades/1635650/console.html#_2017-07-31_18_02_03_776894
Rather than failing on these builds, we should probably throw a large warning in the logs and continue as these failures may not even be related to the change in question. In oooq we've had to implement similar work around especially for packages that don't exist (https://review.openstack.org/#/c/453326/ and Bug 1691579)
Is this still an issue?