For tox 3.x and earlier, passenv was a space-separated list; as of tox
4.0.0, it's comma-separated. For a while, our spaces would be silently
included in the now-one-and-only passenv value parsed (which wasn't
great, but mostly just caused confusion) -- as of tox 4.0.6, however, it
became a hard error, and all tests would fail like
pass_env values cannot contain whitespace, use comma to have multiple
values in a single line, invalid values found 'SWIFT_* *_proxy'
Unfortunately, we don't really know what versions of tox all our various
stakeholders might want/need to use (though we previously set a
minversion of 2.3.2). We might be able to spread values over multiple
lines to make it compatible with both tox 3 *and* tox 4, but I'm fairly
certain *_proxy was only included for some variables that are recent
versions of tox include by default anyway, so just increase our
minversion (which was too low, anyway -- allowlist_externals which we
already configure was added in 3.18.0) and get rid of *_proxy.
FWIW, python-swiftclient was already specifying 3.18.0 as a minversion,
so I expect the new minversion to not be a problem.
Also, add ./.functests to a bunch of allowlist_externals, as newer tox
is more strict about that sort of thing.
Drop skipsdist in a bunch of places so we can import swift from func
tests and docs. (Still not sure why I don't see us hitting a similar
problem for unit tests...)
Change-Id: I4be1e86e3291ad1619c695fb93d7cadf053b556d
nose has not seen active development for many years now. With py310, we
can no longer use it due to import errors.
Also update lower contraints
Closes-Bug: #1993531
Change-Id: I215ba0d4654c9c637c3b97953d8659ac80892db8
PasteDeploy version 3.0 (2022-10-16) dropped support for python2 (as
well as <3.7), which causes our py2 tests to fail. So cap the version
here at 2.1.1, the last which is compatible with our tests.
Even doing this doesn't stop pip install swift pulling in a newer
PasteDeploy in the
tools/playbooks/saio_single_node_setup/make_rings.yaml playbook
(causing the probes test on CentOS-7 to fail); so handle CentOS 7
explicitly.
Change-Id: If69ae0f8eac8fe8ff7d5e4f4f1bff6d0ea9e7a8b
Signed-off-by: Matthew Vernon <mvernon@wikimedia.org>
As part of that, the ceph test runner needed up-rev'ing to run under
py3. As a result, the known-failures shifted.
Trim the on-demand rolling upgrade jobs list -- now that it's running
py3, we only expect it to pass for train and beyond.
Also, pin smmap version on py2 -- otherwise, the remaining experimental
jobs running on centos-7 fail.
Change-Id: Ibe46aecf0f4461be59eb206bfe9063cc1bfff706
We've recently started seeing some failures in the gate related to these
projects, and they have final py2-supporting versions.
Change-Id: If81fc352c8b2b1f03f3fa7b79c56dfcf981ced70
...and, since the previous tag didn't have the Bandit pin, make the
rolling upgrade job non-voting. We should plan on backporting this so we
can check that upgrades from stable branches are still OK.
See also: https://github.com/PyCQA/bandit/issues/654
Change-Id: If7f3ad8b275271d748426133232ed06c2a1cd1de
* Drop osc from test-requirements (and lower-constraints)
I'm not clear on where/how we use it; I think it was a hold-over from
swift3?
* Pin python-keystoneclient in our py2-constraints
Something sees to have changed with the pip resolver that means it
keeps trying to install a newer, py3-only version for our py2 jobs.
Change-Id: Ie37ac077517e1ece5fa6bf163d1ab5e316ced509
The global upper constraints repo will no longer track py2 packages,
meaning upper constraints for the py2.7 runtime will need to be handled
locally.
This adds an in-repo file for upper constraints enforcement using the
last py27 constraints from openstack/requirements to validate
functionality.
Change-Id: I624f914c6155178cbe474f1eae2871e2aef721eb
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>