Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Option to treat warnings as errors #1173

Closed
ghostsquad opened this issue Nov 6, 2015 · 12 comments
Closed

Option to treat warnings as errors #1173

ghostsquad opened this issue Nov 6, 2015 · 12 comments
Labels
topic: reporting related to terminal output and user-facing messages and errors type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature
Milestone

Comments

@ghostsquad
Copy link

as related to #812

I like the idea of "no tests found" as a warning, and a config option to treat warnings as errors. That way, you can build up your CI without tests at first, and maybe with a few other "problems" that just bubble up as warnings. Then as you button things up, switch over to "treat warnings as errors".

@The-Compiler
Copy link
Member

There should probably be some mechanism to ignore specific errors then - I'm still using various plugins which raise deprecation warnings (pytest-capturelog, pytest-bdd), and I don't have the time to fix them all (mainly an issue for pytest-bdd).

@nicoddemus
Copy link
Member

There should probably be some mechanism to ignore specific errors then

Agreed, perhaps something like this?

[pytest]

# turn all pytest-warnings in errors
warnings_as_errors=all

# a few warnings by code: I9 and C1
warnings_as_errors=I9,C1

Btw, @RonnyPfannschmidt @hpk42, what does the "code" warnings mean? Here are a few examples for illustrations:

# cacheprovider.py
warn(code='I9', message='could not create cache path %s' % (path,)
warn(code='I9', message='cache could not write path %s' % (path,))

# config.py
warn("I2", "could not load setuptools entry import: %s" % (e,))

# junitxml.py
request.config.warn(code='C3', message=msg, fslocation=request.node.location[:2])

@RonnyPfannschmidt
Copy link
Member

im not sure myself, unfortunately i couldnt partake in the design of the warnings system in detail

@The-Compiler
Copy link
Member

@nicoddemus I think a way to say "all except ..." makes more sense - in my case I'd like to have all warnings as errors, except a few deprecation warnings I can't fix easily.

@nicoddemus nicoddemus added type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature topic: reporting related to terminal output and user-facing messages and errors labels Nov 18, 2015
@nicoddemus nicoddemus added this to the 2.9 milestone Nov 26, 2015
@RonnyPfannschmidt
Copy link
Member

by now i think the warning codes where a misstake, and would rather see something like the warning classes of the warnings module

@The-Compiler
Copy link
Member

I agree - some plugins also use custom pytest warnings, and it's hard to think of a good warning code.

@The-Compiler The-Compiler modified the milestones: 2.10, 2.9 Feb 26, 2016
@nicoddemus nicoddemus modified the milestones: 2.10, 3.0 Jun 26, 2016
@The-Compiler
Copy link
Member

I think this should be done after a bigger refactoring of the warning system like @RonnyPfannschmidt mentioned. I'm not sure if that can be done in a backwards-compatible way, so I'm tenatively changing the milestone for this one to 4.0.

@nicoddemus
Copy link
Member

Related to #2452

@Zac-HD
Copy link
Member

Zac-HD commented Oct 19, 2018

Since version 3.8, pytest uses Python's standard warnings mechanisms. You can treat warnings as errors in any of the normal ways, and also by running pytest -Werror or equivalent entries in a config file.

@Zac-HD Zac-HD closed this as completed Oct 19, 2018
@nicoddemus
Copy link
Member

@Zac-HD just wanted to mention that I really appreciate the issue triaging you have been doing in the repository lately!

@Zac-HD
Copy link
Member

Zac-HD commented Oct 19, 2018

Just clearing stale questions and labelling untagged issues has gone a surprisingly long way 😄

@nicoddemus
Copy link
Member

Just clearing stale questions and labelling untagged issues has gone a surprisingly long way

Definitely!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic: reporting related to terminal output and user-facing messages and errors type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature
Projects
None yet
Development

No branches or pull requests

5 participants