[openstack-dev] All patches failing CI for validations stable/ocata branch - help needed
flfuchs at redhat.com
Thu Mar 30 14:37:09 UTC 2017
On Wed, Mar 29, 2017 at 11:46 PM, Jeremy Stanley <fungi at yuggoth.org> wrote:
> On 2017-03-29 18:32:09 +0200 (+0200), Florian Fuchs wrote:
>> The error in the logs however is always the same  and appears
>> to be related to an issue with setuptools 34, which apparently
>> hit other openstack projects as well. I tried to create a patch
>> with a fix (excluding setuptools 34),
> The way we "fixed" this for other projects was to update
> requirements caps and/or constraints entries for all of setuptools'
> direct and transitive install_requires (there are only three, if
> memory serves) on stable branches. This is usually not the sort of
> thing we'd want to have happening in stable branches, but keeping
> them installable with latest setuptools releases is important. Also
> pinning setuptools can be hard depending on the situation, since
> you're often using setuptools in the process of trying to control
> your version of setuptools... bit of a catch-22.
Thanks for your reply.
FYI: To solve this, I proposed a backport for a requirements patch
that already addresses the problem:
>> but couldn't test it because gerrit set the target patch to master
>> instead of stable/ocata (I guess it only allows me to propose
>> backport patches to stable branches, not creating a patch for a
>> stable branch only).
> If the .gitreview file in your stable/ocata branch doesn't have
> defaultbranch=stable/ocata, then you have to pass the branch name as
> a parameter when invoking git review, i.e. `git review stable/ocata`
> (or just fix the .gitreview file so you don't have to think about
> it). See https://docs.openstack.org/infra/git-review/usage.html for
We have separate a patch adding the default branch to .gitignore, but,
obviously, it fails due to the problem above...
But thanks for the hint! I wasn't aware the target could be set as a
git review param as well.
> Jeremy Stanley
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev