ci: polyfill logger in edge cases for #541 #647
Conversation
This polyfill implementation of `logger` handles scenarios where the environment isn't fully initialized or where the logger stub isn't able to be run. Falling back to `printf` eliminates logged errors from these places and in their place prints the expected messages.
|
I approved because I'm sure it will work and be fine. However, is there a technical need for us to use logger? I'm not sure I like the idea of needing to write tooling just to be able to have some sort of structured logging just to echo messages in our build process. But perhaps I'm missing a piece of the puzzle that requires this. |
|
@zmrow this is for using the standard This makes the logging output consistent across our scripts and was recommended for use in an earlier PR (can't point to where at the moment). This PR makes calls to |
| fi | ||
|
|
||
| # Stream of messages sent to function as input | ||
| while read msg; do |
There was a problem hiding this comment.
What is msg in this context?
There was a problem hiding this comment.
$msg is a message that's read off of stdin piped into the "command" (the function at this point in the code). This is implemented here as you're able to pipe messages into (the real) logger and have it print out your messages with the same format for each read line:
logger -s -t INFO <<EOF
message 1 - hello, world!
message 2 - hi, there!
EOF
# <13>Jan 14 15:11:18 INFO: message 1 - hello, world!
# <13>Jan 14 15:11:18 INFO: message 2 - hi, there!
Issue #, if available:
#541
Description of changes:
This polyfill implementation of
loggerhandles scenarios where theenvironment isn't fully initialized or where the logger stub isn't able
to be run. Falling back to
printfeliminates logged errors from theseplaces and in their place prints the expected messages.
This helps reach full coverage for #541
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.