-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Fixes to live logs #3175
Fixes to live logs #3175
Conversation
Hi @s0undt3ch thanks for the PR. Can you explain why do you think we need to capture logs during |
So, I was the one who first implemented live logs, first as my own pytest plugin, which got merged to pytest catchlog plugin, and now pytest. With that said, sorry for the mess 😄 @nicoddemus the reason why those sections are being handled is because on my CI process I set 2 different log levels for live and file logs. With the latest changes, the live logs get sections which helps a ton, but the logfile just gets a ton of logs and it's really hard to know when a test started and/or finished, so I use those sections to log the start and end of tests. Additionally on this PR, and because I was previously using And, additionally, because I think it's what was really missing from #3124, if a user explicitly set's the cli level setting, either in the ini or as an argument to pytest, automatically enable live logs. (Should we add a |
try: | ||
yield # run test | ||
finally: | ||
del item.catch_log_handler | ||
if item: | ||
del item.catch_log_handler | ||
if when == 'teardown': |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be indented (under if item:
) right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not necessarily because item does exist on teardown. But it can be moved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh you are right, well up to you!
@@ -0,0 +1 @@ | |||
Enable live logs is log_cli_level is passed/set explicitly |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure about this, I can imagine someone setting log_cli_level
in their pytest.ini
file so that they can enable/disable live logging in the command line without having to also pass the log level each time...
@Thisch what do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In that case I think we need a CLI flag to enable live logs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have the log_cli
configuration option, which can be changed directly in the command-line: -o log_cli=True
. 😉
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if setting log_cli_level
on the command line or in an ini file should automatically set log_cli
to True. I would prefer if we have a similar shortcut for live logging, like we have for disabling stream capturing (-s
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Thisch --log-cli
? --logs-stream
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm OK about having a --log-cli
flag, although it is so close to -o log_cli=true
that I'm not sure it adds much. What about having a short option for it instead? And what that would be?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe -S
in analogy to -s
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Too close IMHO... @RonnyPfannschmidt are you 👎 on having a command-line for this, as you mentioned in #3190 (comment)?
Thanks @s0undt3ch and sorry for the delay!
Not at all, thanks for all your work! 😁
This is great, but I believe we should split this PR:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please see my comments! 👍
Ok. I'll split these up tomorrow morning. Thanks for the review. |
Thanks! Looking forward to the PRs. 👍 |
Thanks @s0undt3ch! |
Thanks for submitting a PR, your contribution is really appreciated!
Here's a quick checklist that should be present in PRs:
$issue_id.$type
for example (588.bugfix)removal
,feature
,bugfix
,vendor
,doc
ortrivial
bugfix
,vendor
,doc
ortrivial
fixes, targetmaster
; for removals or features targetfeatures
;Unless your change is a trivial or a documentation fix (e.g., a typo or reword of a small section) please:
AUTHORS
, in alphabetical order;