-
Notifications
You must be signed in to change notification settings - Fork 8
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
Report buses out of realistic voltage range in sub reports #1105
Conversation
Signed-off-by: Joris Mancini <[email protected]>
Signed-off-by: Joris Mancini <[email protected]>
9ea5d83
to
1b6b732
Compare
Signed-off-by: Damien Jeandemange <[email protected]>
Signed-off-by: Damien Jeandemange <[email protected]>
Signed-off-by: Damien Jeandemange <[email protected]>
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 don't think that TRACE is the right severity level for the message displaying the bus names, since users need to know them in order to fix the problem as explained in a previous comment.
But if no application developer is shouting I have no reason to block at this time. Hence my approval.
Quality Gate passedIssues Measures |
Signed-off-by: Joris Mancini <[email protected]> Signed-off-by: Didier Vidal <[email protected]>
Please check if the PR fulfills these requirements
What kind of change does this PR introduce?
Split a report where a message can be really big into smaller sub-reports
What is the current behavior?
We're creating a report with a message based on a map that gathers all the network elements that are in error. This list can be really big and we feel this is not a good practice to do so.
What is the new behavior (if this is a feature change)?
Instead of one report gathering all the detailed information we split it into sub-reports with TRACE level and one summary message with ERROR level
Does this PR introduce a breaking change or deprecate an API?