Hi, It turns out that there are some jobs in OpenStack's Zuul that were relying on a behavior in devstack-gate and zuul-cloner that would check out a tag when given an override branch.
Zuul v3 is a bit more literal -- the 'override-branch' option (for both jobs and projects) will only checkout a branch, and if it does not exist, it falls back in the usual manner. To support this case we could: 1) Extend 'override-branch' to support tags as well as branches. 2) Add 'override-tag' to support tags. 3) Add 'override-ref' to support branches + tags. We can of course do both 2 and 3 as well. 4) Add 'override-checkout' to support branches + tags. If we do 3 (only), or 4, we might choose to drop 'override-branch'. If we keep override-branch, we would need to establish whether more than one of these options is permitted, and if so, what the order of precedence is. And if we declare them exclusive, what do to in the case of inheritance. I'm inclined to do the following: Add 'override-checkout' to support branches + tags and drop (after a deprecation period) 'override-branch'. It's very clear what it does, and it relates to git terminology. Are there any other use cases (either in OpenStack or from other users) that we should consider that might suggest we should choose another solution? And are there any other suggestions for how we might handle this? Thanks, Jim _______________________________________________ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra