certbot/pytest.ini

# 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.
[pytest]
addopts = --numprocesses auto --pyargs
# ResourceWarnings are ignored as errors, since they're raised at close
# decodestring: https://github.com/rthalley/dnspython/issues/338
# ignore our own TLS-SNI-01 warning
filterwarnings =
    error
    ignore:decodestring:DeprecationWarning
    ignore:TLS-SNI-01:DeprecationWarning
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]`
Only error on DeprecationWarnings 2018-10-30 20:13:40 -04:00			`addopts = --numprocesses auto --pyargs`
Error on warning, unless it's a ResourceWarning 2018-11-01 19:39:29 -04:00			`# ResourceWarnings are ignored as errors, since they're raised at close`
remove pytest.mark, move to specific ignore in pytest.ini 2018-11-05 20:41:26 -05:00			`# decodestring: https://github.com/rthalley/dnspython/issues/338`
ignore our own TLS-SNI-01 warning 2018-11-05 20:42:19 -05:00			`# ignore our own TLS-SNI-01 warning`
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`
remove pytest.mark, move to specific ignore in pytest.ini 2018-11-05 20:41:26 -05:00			`ignore:decodestring:DeprecationWarning`
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			`ignore:TLS-SNI-01:DeprecationWarning`