-
Notifications
You must be signed in to change notification settings - Fork 14
Test coverage for the customised logger setup #232
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
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In addition, pass through stderr as the stream for the nice formatter to probe because that's where output goes, and it might be different to stdout.
…o confirm they work.
…we install. This includes several tests marked as expected failures due to issues in the current implementation of the formatter.
|
✅ 40/40 passed, 2 skipped, 1m21s total Running from acceptance #270 |
This was referenced May 15, 2025
This was referenced May 15, 2025
sundarshankar89
approved these changes
May 15, 2025
Collaborator
sundarshankar89
left a comment
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.
LGTM
asnare
added a commit
that referenced
this pull request
May 15, 2025
#235) This PR updates the log formatter so that when non-colorised logs are being produced, we the timestamps include second-granular timestamps. Previously only the minute was logged, which aside from being inconsistent with the colorised output is insufficient for a logged timestamp. This PR is stacked on top of #232.
asnare
added a commit
that referenced
this pull request
May 15, 2025
This PR fixes an issue with the colorised log formatter whereby it wasn't properly formatting log entries if they contained `%`-style placeholders (with arguments). Although we don't generally use this style in our own projects, 3rd-party code does and if we don't support this then logging from those components is incorrect. This is stacked on top of #232 and resolves #230.
asnare
added a commit
that referenced
this pull request
May 16, 2025
…236) When colorising logger output, the logger name (conventionally the module) is abbreviated: this abbreviating throws an exception during formatting if the logger name contains `..`. This is unlikely to occur during normal use, but may occur if the logger is used in a script that was referred to via a path that includes `..`. This PR is stacked on top of #232.
asnare
added a commit
that referenced
this pull request
May 16, 2025
This PR updates the names we use for the `WARNING` and `CRITICAL` log-levels when produced colorised logs. Prior to this PR: - When not-colorised, we used the conventional `WARNING` and `CRITICAL` names. - When colorised, we used `WARN` and `FATAL` instead. Although the latter is more compact, it's more important to: a) be consistent; b) conform to the norms of the Python ecosystem and use the conventional names for the logging levels. This PR is stacked on top of #232 and resolves #229.
asnare
added a commit
that referenced
this pull request
May 16, 2025
This PR updates the format of logs to be consistent when exception
information is included, irrespective of whether the logs are colorised
or not. Prior to this PR, colorised logs were formatted slightly
differently to the Python norms:
```
16:06:10 ERROR [d.l.module] An error occurred: Traceback (most recent call last):
File "/path/to/file.py", line 410, in some_function
raise RuntimeError("Test exception.")
RuntimeError: Test exception.
```
(Note that the traceback starts on the line of the error.)
This PR updates this to be:
```
16:08:18 ERROR [d.l.module] An error occurred
Traceback (most recent call last):
File "/path/to/file.py", line 410, in some_function
raise RuntimeError("Test exception.")
RuntimeError: Test exception.
```
This PR is stacked on top of #232.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR provides test coverage of the custom logger that blueprint installs, and establishes the baseline behaviour. Changes include:
install_logger()method to verify the configuration that it sets up.NiceFormatterSome of the tests currently fail due to problems with the existing implementation that will be fixed in subsequent PRs.
All updates to the external interfaces are API-compatible.
Relates: #229, #230.