git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[oslo][requirements] Bandit Strategy


Should uncap patches be -W until next bandit release?

Em ter, 14 de mai de 2019 às 17:26, Doug Hellmann <doug at doughellmann.com>
escreveu:

> Zane Bitter <zbitter at 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 <https://www.redhat.com>

<https://red.ht/sig>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190515/cc39b2f3/attachment.html>