Should uncap patches be -W until next bandit release?
Zane Bitter <zbitter@redhat.com> writes:
> On 13/05/19 1:40 PM, Ben Nemec wrote:
>>
>>
>> On 5/13/19 12:23 PM, Ben Nemec wrote:
>>> Nefarious cap bandits are running amok in the OpenStack community!
>>> Won't someone take a stand against these villainous headwear thieves?!
>>>
>>> Oh, sorry, just pasted the elevator pitch for my new novel. ;-)
>>>
>>> Actually, this email is to summarize the plan we came up with in the
>>> Oslo meeting this morning. Since we have a bunch of projects affected
>>> by the Bandit breakage I wanted to make sure we had a common fix so we
>>> don't have a bunch of slightly different approaches in each project.
>>> The plan we agreed on in the meeting was to push a two patch series to
>>> each repo - one to cap bandit <1.6.0 and one to uncap it with a
>>> !=1.6.0 exclusion. The first should be merged immediately to unblock
>>> ci, and the latter can be rechecked once bandit 1.6.1 releases to
>>> verify that it fixes the problem for us.
>
> I take it that just blocking 1.6.0 in global-requirements isn't an
> option? (Would it not work, or just break every project's requirements
> job? I could live with the latter since they're broken anyway because of
> the sphinx issue below...)
Because bandit is a "linter" it is in the blacklist in the requirements
repo, which means it is not constrained there. Projects are expected to
manage the versions of linters they use, and roll forward when they are
ready to deal with any new rules introduced by the linters (either by
following or disabling them).
So, no, unfortunately we can't do this globally through the requirements
repo right now.
--
Doug
--
Moisés Guimarães
Software Engineer
Red Hat