upstream/certbot
1
0
Fork 0
mirror of https://github.com/certbot/certbot.git synced 2026-02-03 20:40:36 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions 1
certbot/pytest.ini

42 lines
2.3 KiB
INI
Raw Normal View History

Don't use pytest.ini during the release. (#6550) Currently the release script in master fails for a few reasons. First, it's trying to use --numprocesses which comes from a pytest plugin that we're not installing in the release script. Second, many new warnings are raised when we're not using pinned versions of our dependencies. I'm not sure I agree, but one could argue that we should fix these issues and use the file during the release. I'm particularly hesitant for us to do this when it comes to warnings. We currently do not pin our dependencies in the release script. Do we really want to stop the release because a new package was released and is warning about something? One could argue we do because these warnings may be visible to the user, but they very rarely are and I think this makes the release process much too painful. I especially do not think we should block the release on this now as we are not up to date on the warnings raised by the latest versions of our packages so there is a lot to work through. * Don't use pytest.ini during the release. * State that pytest.ini isn't used in release script.
2018-11-30 20:40:55 -05:00
# This file isn't used while testing packages in tools/_release.sh so any
# settings we want to also change there must be added to the release script
# directly.
move values to pytest.ini
2018-07-11 20:25:48 -04:00
[pytest]
Add warning about ignoring our own warnings (#7971) Coming out of the conversation at #7863 in the linked Google Doc, we should always have at least 1 release between updating one of our plugins to stop using a deprecated acme/certbot API and removing it from acme/certbot. Doing this gives the plugin changes time to propagate rather than potentially having the plugin break because Certbot was updated before the plugin had made the necessary changes. This comment here should help ensure this. * Add pytest warnings warning. * clarify comment
2020-05-04 19:54:09 -04:00
# Warnings being triggered by our plugins using deprecated features in
# acme/certbot should be fixed by having our plugins no longer using the
# deprecated code rather than adding them to the list of ignored warnings here.
# Fixing things in this way prevents us from shipping packages raising our own
# deprecation warnings and gives time for plugins that don't use the deprecated
# API to propagate, especially for plugins packaged as an external snap, before
# we release breaking changes.
Update coverage and pytest (#8875) * unpin pytest and update pinnings * ignore external mock warnings * fix assertion * fix test_revoke_mutual_exclusive_flags * fix output count * capture stdout and stderr separately * undouble counts * rename variable * don't use capture_output * fix leaky test * update coverage
2021-05-31 03:01:01 -04:00
#
# The current warnings being ignored are:
# 1) The warning raised when importing certbot.tests.util and the external mock
# library is installed.
Finish pinning system rewrite (#8934) * add oldest pyproject.toml file that works * make single oldest_constraints.txt file * remove unused merge_requirements.py * remove unused import * make conditional right * simplify pip_install.py * fix typo * bump min dns-lexicon dependency * fix zope import warning * pin back wheel * refactor pinning script * Add oldest script. * add pip comment * add pipstrap extra * simplify pinning scripts * remove pipstrap extra * update contributing * Add design doc * Update tools/pinning/DESIGN.md Co-authored-by: ohemorange <erica@eff.org> * Update tools/pinning/DESIGN.md Co-authored-by: ohemorange <erica@eff.org> * Update tools/pinning/DESIGN.md Co-authored-by: ohemorange <erica@eff.org> * Update tools/pinning/DESIGN.md Co-authored-by: ohemorange <erica@eff.org> * rename normal to current * no dummies * script improvements * mention need to update setup.py * try and clarify poetry behavior * tweak section title Co-authored-by: ohemorange <erica@eff.org>
2021-07-22 15:00:30 -04:00
# 2) An ImportWarning is raised with older versions of setuptools and
# zope.interface. See
# https://github.com/zopefoundation/zope.interface/issues/68 for more info.
Emit deprecation warnings for Zope interfaces (#8970) * Monkeypatch certbot.interfaces module to warn about deprecations * Ignore our own warning * Fix type * Add a changelog entry
2021-08-14 17:06:29 -04:00
# 3) The deprecation warning raised when importing old Zope interfaces from
# the certbot.interfaces module.
Add deprecation warnings for deprecated elements in certbot.display.util (#8989) Fix #8982. This PR takes essentially the same approach than in #8970 and https://github.com/certbot/certbot/pull/6859/files#diff-e5eaf744409c293203b898ba9896da75689fd04ff5f1566c035940a5b195c257 Co-authored-by: Brad Warren <bmw@users.noreply.github.com>
2021-08-17 12:13:54 -04:00
# 4) The deprecation warning raised when importing deprecated attributes from
# the certbot.display.util module.
dns-rfc2136: use certbot's own is_ipaddress func (#9035) * dns-rfc2136: use certbot's own is_ipaddress func * oldest: pin dnspython==1.15.0 (epel8 version) * inhibit deprecationwarning for dnspython==1.15.0 * dns-rfc2136: declare minimum version of dnspython * add changelog entry
2021-09-13 17:48:15 -04:00
# 5) A deprecation warning is raised in dnspython==1.15.0 in the oldest tests for
# certbot-dns-rfc2136.
Add Python 3.10 support and tests (#9077) Fixes https://github.com/certbot/certbot/issues/9058. The changes to the CI config are equivalent to the ones made in https://github.com/certbot/certbot/pull/8460. Other than ignoring some warnings raised by botocore, the main additional work that had to be done here was switching away from using `distutils.version.LooseVersion` since the entire `distutils` module was deprecated in Python 3.10. To do that, I took a few different approaches: * If the version strings being parsed are from Python packages such as Certbot or setuptools, I switched to using [pkg_resources.parse_version](https://setuptools.pypa.io/en/latest/pkg_resources.html#parsing-utilities) from `setuptools`. This functionality has been available since [setuptools 8.0 from 2014](https://setuptools.pypa.io/en/latest/history.html#id865). * If the version strings being parsed are not from Python packages, I added code equivalent to `distutils.version.LooseVersion` in `certbot.util.parse_loose_version`. * The code for `CERTBOT_PIP_NO_BINARY` can be completely removed since that variable isn't used or referenced anywhere in this repo. * add python 3.10 support * make some version changes * don't use looseversion in setup.py * switch to pkg_resources * deprecate get_strict_version * fix route53 tests * remove unused CERTBOT_PIP_NO_BINARY code * stop using distutils in letstest * add unit tests * more changelog entries
2021-11-08 18:55:32 -05:00
# 6) The vendored version of six in botocore causes ImportWarnings in Python
# 3.10+. See https://github.com/boto/botocore/issues/2548.
# 7) botocore's default TLS settings raise deprecation warnings in Python
# 3.10+, but their values are sane from a security perspective. See
# https://github.com/boto/botocore/issues/2550.
Deprecate Python 3.6 support (#9160) Fixes https://github.com/certbot/certbot/issues/8983 Python 3.6 is now EOL: https://endoflife.date/python This is normally a good time to create warnings about Python 3.6 deprecation the Certbot upcoming release 1.23.0 so that its support is removed in 1.24.0. We have to say here that EPEL maintainers asked us to keep maintaining support of Python 3.6 because Python 3.7 will never be shipped to CentOS 7. This support would be needed in theory up to 2 more years, basically until CentOS 7 EOL in 2024-06-30. It has been said that we could support as a best effort until a reasonable need on Certbot side requires to drop Python 3.6. See https://github.com/certbot/certbot/issues/8983 for more information. However some of us (including me) consider that there is already a reasonable need right now. Indeed, keeping the support on Python 3.6 while the Python community globally moves away from it will pin implicitly some Certbot dependencies to the last version of these dependencies supporting Python 3.6 as the upstream maintainers decide to make the move. At any point in a future time, one of these dependencies could require an urgent upgrade (typically a critical uncovered vulnerability): then we would require to drop Python 3.6 immediately without further notice instead of following an organized deprecation path. This reason motivates to proactively deprecate then drop the Python versions once they are EOL. You can see the discussion in Mattermost starting from [this post](https://opensource.eff.org/eff-open-source/pl/ntzs9zy1fprjmkso3xrqspnoce) to get more elements about the reasoning. * Deprecate Python 3.6 support. * Ignore our own PendingDeprecationWarning
2022-01-21 15:42:05 -05:00
# 8) Ignore our own PendingDeprecationWarning about Python 3.6 soon to be dropped.
# See https://github.com/certbot/certbot/pull/9160.
Only error on DeprecationWarnings
2018-10-30 20:13:40 -04:00
filterwarnings =
Move back to using a warning whitelist
2018-10-30 20:24:29 -04:00
error
Update coverage and pytest (#8875) * unpin pytest and update pinnings * ignore external mock warnings * fix assertion * fix test_revoke_mutual_exclusive_flags * fix output count * capture stdout and stderr separately * undouble counts * rename variable * don't use capture_output * fix leaky test * update coverage
2021-05-31 03:01:01 -04:00
ignore:The external mock module:PendingDeprecationWarning
Finish pinning system rewrite (#8934) * add oldest pyproject.toml file that works * make single oldest_constraints.txt file * remove unused merge_requirements.py * remove unused import * make conditional right * simplify pip_install.py * fix typo * bump min dns-lexicon dependency * fix zope import warning * pin back wheel * refactor pinning script * Add oldest script. * add pip comment * add pipstrap extra * simplify pinning scripts * remove pipstrap extra * update contributing * Add design doc * Update tools/pinning/DESIGN.md Co-authored-by: ohemorange <erica@eff.org> * Update tools/pinning/DESIGN.md Co-authored-by: ohemorange <erica@eff.org> * Update tools/pinning/DESIGN.md Co-authored-by: ohemorange <erica@eff.org> * Update tools/pinning/DESIGN.md Co-authored-by: ohemorange <erica@eff.org> * rename normal to current * no dummies * script improvements * mention need to update setup.py * try and clarify poetry behavior * tweak section title Co-authored-by: ohemorange <erica@eff.org>
2021-07-22 15:00:30 -04:00
ignore:.*zope. missing __init__:ImportWarning
Emit deprecation warnings for Zope interfaces (#8970) * Monkeypatch certbot.interfaces module to warn about deprecations * Ignore our own warning * Fix type * Add a changelog entry
2021-08-14 17:06:29 -04:00
ignore:.*attribute in certbot.interfaces module is deprecated:DeprecationWarning
dns-rfc2136: use certbot's own is_ipaddress func (#9035) * dns-rfc2136: use certbot's own is_ipaddress func * oldest: pin dnspython==1.15.0 (epel8 version) * inhibit deprecationwarning for dnspython==1.15.0 * dns-rfc2136: declare minimum version of dnspython * add changelog entry
2021-09-13 17:48:15 -04:00
ignore:.*attribute in certbot.display.util module is deprecated:DeprecationWarning
ignore:decodestring\(\) is a deprecated alias:DeprecationWarning:dns
Add Python 3.10 support and tests (#9077) Fixes https://github.com/certbot/certbot/issues/9058. The changes to the CI config are equivalent to the ones made in https://github.com/certbot/certbot/pull/8460. Other than ignoring some warnings raised by botocore, the main additional work that had to be done here was switching away from using `distutils.version.LooseVersion` since the entire `distutils` module was deprecated in Python 3.10. To do that, I took a few different approaches: * If the version strings being parsed are from Python packages such as Certbot or setuptools, I switched to using [pkg_resources.parse_version](https://setuptools.pypa.io/en/latest/pkg_resources.html#parsing-utilities) from `setuptools`. This functionality has been available since [setuptools 8.0 from 2014](https://setuptools.pypa.io/en/latest/history.html#id865). * If the version strings being parsed are not from Python packages, I added code equivalent to `distutils.version.LooseVersion` in `certbot.util.parse_loose_version`. * The code for `CERTBOT_PIP_NO_BINARY` can be completely removed since that variable isn't used or referenced anywhere in this repo. * add python 3.10 support * make some version changes * don't use looseversion in setup.py * switch to pkg_resources * deprecate get_strict_version * fix route53 tests * remove unused CERTBOT_PIP_NO_BINARY code * stop using distutils in letstest * add unit tests * more changelog entries
2021-11-08 18:55:32 -05:00
ignore:_SixMetaPathImporter.:ImportWarning
ignore:ssl.PROTOCOL_TLS:DeprecationWarning:botocore
Deprecate Python 3.6 support (#9160) Fixes https://github.com/certbot/certbot/issues/8983 Python 3.6 is now EOL: https://endoflife.date/python This is normally a good time to create warnings about Python 3.6 deprecation the Certbot upcoming release 1.23.0 so that its support is removed in 1.24.0. We have to say here that EPEL maintainers asked us to keep maintaining support of Python 3.6 because Python 3.7 will never be shipped to CentOS 7. This support would be needed in theory up to 2 more years, basically until CentOS 7 EOL in 2024-06-30. It has been said that we could support as a best effort until a reasonable need on Certbot side requires to drop Python 3.6. See https://github.com/certbot/certbot/issues/8983 for more information. However some of us (including me) consider that there is already a reasonable need right now. Indeed, keeping the support on Python 3.6 while the Python community globally moves away from it will pin implicitly some Certbot dependencies to the last version of these dependencies supporting Python 3.6 as the upstream maintainers decide to make the move. At any point in a future time, one of these dependencies could require an urgent upgrade (typically a critical uncovered vulnerability): then we would require to drop Python 3.6 immediately without further notice instead of following an organized deprecation path. This reason motivates to proactively deprecate then drop the Python versions once they are EOL. You can see the discussion in Mattermost starting from [this post](https://opensource.eff.org/eff-open-source/pl/ntzs9zy1fprjmkso3xrqspnoce) to get more elements about the reasoning. * Deprecate Python 3.6 support. * Ignore our own PendingDeprecationWarning
2022-01-21 15:42:05 -05:00
ignore:Python 3.6 support will be dropped:PendingDeprecationWarning
Reference in a new issue Copy permalink