10 Commits

Author SHA1 Message Date
Tim Burke
2d7c1dc6dd CI: Fix our usage of tox
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
2022-12-29 13:36:06 -08:00
Tim Burke
ef155bd74a Switch to pytest
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
2022-12-09 11:38:02 -08:00
Matthew Vernon
cc033154ad py2constraints: pin PasteDeploy version
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>
2022-10-17 13:43:24 +01:00
Tim Burke
d29cbc3996 CI: Run ceph and rolling upgrade tests under py3
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
2022-04-04 17:17:06 -07:00
Tim Burke
086aa5c4f3 CI: fix lower-constraints job
Newer pathlib2 doesn't work with our ancient six.

Change-Id: I4e1db60c7bd1e1888d641e9a4c9f40b0bd20f03d
2022-02-09 11:01:33 -08:00
Tim Burke
1895213d25 Update some constraints for py2
We've recently started seeing some failures in the gate related to these
projects, and they have final py2-supporting versions.

Change-Id: If81fc352c8b2b1f03f3fa7b79c56dfcf981ced70
2021-04-06 11:33:44 -07:00
Tim Burke
f819fc8c24 Give functional tests another chance to pass
In the process, move from using os-testr to stestr.

Change-Id: Ib6651aab8b009605bf0855ec217003936c0fae6e
2021-03-26 10:13:19 -07:00
Tim Burke
232cb85cb9 Pin Bandit on py2
...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
2020-12-07 15:18:50 -08:00
Tim Burke
0d37492c65 Clean up requirements a bit
* 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
2020-12-01 15:41:18 -08:00
Sean McGinnis
0f2da2aee6
Use local py2 upper-constraints
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>
2020-05-04 07:03:53 -05:00