Moises Guimaraes de Medeiros <moguimar@redhat.com> writes:
Should uncap patches be -W until next bandit release?
I would expect them to fail the linter job until then, so I don't think that's strictly needed.
Em ter, 14 de mai de 2019 às 17:26, Doug Hellmann <doug@doughellmann.com> escreveu:
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 <https://www.redhat.com>
-- Doug