Don't suppress messages when logging is not configured#1813
Don't suppress messages when logging is not configured#1813Byron merged 4 commits intogitpython-developers:mainfrom
Conversation
This has each module use `__name__` for the path to its own logger. Previously, most modules did this several hard-coded their names in calls to logging.getLogger.
These globals were nonpublic, because even though they were named
without leading underscores, they all appeared in modules in which
__all__ was defined and did not list them. (They remain nonpublic.)
This renaming is to avoid confusion between those log attributes
ang logging features of Git itself ("git log", "git reflog"), and
more importantly, with the related git.refs.log module, referred to
by the log attribute of the git.refs module, and the log attribute
of the git module (git/__init__.py has a * import from git.refs).
This changes a couple tests that access specific loggers to use the logger name instead, as code outside GitPython should do.
This stops adding `NullHandler` instances to GitPython's loggers. As noted in gitpython-developers#1806, when they were added in gitpython-developers#300 this prevented errors when GitPython logged messages and logging was not enabled, but since Python 3.2 there is a logger of last resort providing a nicer default behavior of showing the messages. (They are still shown with better formatting if logging is configured, even if just done with logging.basicConfig(), so applications should still typically configure logging.)
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| cmdline = remove_password_if_present(cmdline) | ||
|
|
||
| log.debug("Cmd(%s)'s unused stdout: %s", cmdline, stdout) | ||
| _logger.debug("Cmd(%s)'s unused stdout: %s", cmdline, stdout) |
Check failure
Code scanning / CodeQL
Clear-text logging of sensitive information
|
|
||
| except Exception as ex: | ||
| log.error(f"Pumping {name!r} of cmd({remove_password_if_present(cmdline)}) failed due to: {ex!r}") | ||
| _logger.error(f"Pumping {name!r} of cmd({remove_password_if_present(cmdline)}) failed due to: {ex!r}") |
Check failure
Code scanning / CodeQL
Clear-text logging of sensitive information
| redacted_command = remove_password_if_present(command) | ||
| if self.GIT_PYTHON_TRACE and (self.GIT_PYTHON_TRACE != "full" or as_process): | ||
| log.info(" ".join(redacted_command)) | ||
| _logger.info(" ".join(redacted_command)) |
Check failure
Code scanning / CodeQL
Clear-text logging of sensitive information
| ) | ||
| elif stdout_value: | ||
| log.info("%s -> %d; stdout: '%s'", cmdstr, status, as_text(stdout_value)) | ||
| _logger.info("%s -> %d; stdout: '%s'", cmdstr, status, as_text(stdout_value)) |
Check failure
Code scanning / CodeQL
Clear-text logging of sensitive information
| _logger.info("%s -> %d; stdout: '%s'", cmdstr, status, as_text(stdout_value)) | ||
| else: | ||
| log.info("%s -> %d", cmdstr, status) | ||
| _logger.info("%s -> %d", cmdstr, status) |
Check failure
Code scanning / CodeQL
Clear-text logging of sensitive information
Byron
left a comment
Byron
left a comment
There was a problem hiding this comment.
Thanks a lot for your help!
Once CI is green I will merge this PR and hope this can pave the way to improve the git.refresh() messaging as well :).
|
It looks like pypi packages fail to refresh in the cygwin job for some reason, the last one timed out after 6h. Merging anyway. |
|
Sorry about leaving this in the draft state without explanation. I had hoped to check if the CodeQL results would cause a "Code scanning results" failure in the merge commit, as well as to improve on, or if not then to describe, the new Cygwin failure where It looks like the current situation on this repository's main branch is difficult to evaluate because many more CI checks on the pushed merge commit have been cancelled than are affected by either of these issues. Would you be willing to rerun the CI workflows on 10cdd03 other than the Cygwin one? |
|
Apologies for the premature merge, indeed I considered all failures unrelated and decided to just ignore them, particularly after having seen 6h timeouts for Cygwin. After restarting CI on the 10cdd03 , Cygwin still hangs. Does that mean that Cygwin based workflows don't work for anyone right now? That would be major breakage and I have no idea how it can stall forever. |
|
Thanks for rerunning the checks on 10cdd03. I see everything other than the Cygwin job is okay. (I suspected this, since it is the situation in my fork since fast-forwarding, but I wasn't sure if there was more going on related to their cancellation.)
The merge seems fine to me--no need to apologize. The CodeQL failure was due to the changes here, though the new alerts were replacing equivalent previous alerts. But I think you're mainly talking about the Cygwin failure, which is not from the changes here. It happens even when rerunning the Cygwin test job on a commit where it has successfully completed before.
They're probably not broken for everyone, because the problem seems only to happen with
Even though
My guess is that it's something else, though. I'll look into it further. |
|
I've learned enough about the Cygwin problem to find what I believe to be a reasonable workaround, which I've proposed in #1814 along with my findings. |
2 participants
Fixes #1806
This stops adding
NullHandlerinstances to GitPython's loggers. As noted in #1806, when they were added in #300 this prevented errors when GitPython logged messages and logging was not enabled, but since Python 3.2 there is a logger of last resort providing a nicer default behavior of showing the messages. (They are still shown with better formatting if logging is configured, even if just done withlogging.basicConfig(), so applications should still typically configure logging.)This also makes a few more minor related changes, detailed in the commit messages. This includes changing variable names from
logto_logger, as mentioned in #1806 (comment), as well as consistently passing__name__tologging.getLoggerinstead of hard-coding names in a few places, as mentioned in #1808 (comment).The major effect of the changes here is that messages of level
WARNINGor higher are not suppressed by default anymore, even when logging is not configured. So I could have included a change here to take care of #1808 as well, such as dc62096. But I plan to introduce that in a future pull request instead, because it would be best to add tests for it, which I think should build on the tests proposed in #1812. If both #1812 and this PR are merged, I can add tests followed by the changes from dc62096 that would make them pass. (If they are not merged, or they are merged with major changes, then that will also clarify how to move forward with making a warning from the initial refresh use the logging framework.)This shows as resolving several CodeQL alerts and also adding new alerts that correspond exactly to them. This happens as a result of renaming
logto_logger; CodeQL considers the alert resolved because there are no more calls tolog, and issues new equivalent alerts for the same situations with_logger. The new alerts produce a failing Code scanning results check for the PR.