Change:
appears to have been trying to improve the logging in e2e test runs, but it seems to have affected much more than that, and now when a build fails, it logs so many useless messages that you have to scroll back to see why your compile actually failed. before: after: /assign cc (re )
GitHub didn't allow me to assign the following users: oxxenix. Note that only with read permissions, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : appears to have been trying to improve the logging in e2e test runs, but it seems to have affected much more than that, and now when a build fails, it logs so many useless messages that you have to scroll back to see why your compile actually failed. after: /assign cc (re ) Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
thanks for tracking this down. I agree that the additional error message is distracting and would like to see implemented differently so that it's not shown for manual invocations.
/sig release
do you have any tips or recommendations how to implement it differently? Thanks
It looks like that extra ouput is a from . I'd suggest to either revert or strip BASHCOMMAND from the error message if it's not that useful.
It looks like what you wanted in is the location and time stamp ("The update now displays both the specific location of the error in the code and a timestamp."), which is what we also get from the calltree after "make build". I would revert and then investigate why that shorter calltree is not shown after an E2E test failure. Keeping the calltree around as in Dan's "before" seems reasonable to me.
It shows a little bit more location info with the change. Here is how failure looks like with the change (but without BASH_COMMAND: and without the change:
I mean, the call tree is pretty useless in the "compile error" case... if your problem is that the code doesn't compile, you don't need to be told what part of the build scripts it is that invokes . It's just that before it was a small amount of useless output that was easy to ignore, whereas now it's a lot of useless output, which completely pushes the useful output offscreen. But IMO, "no backtrace" would be nicer than "short backtrace"... (I realize there are probably other cases where the backtrace is useful, and I'm not saying we should get rid of it in those cases, whatever they are.)
I agree, stack trace for compilation errors is quite useless. Unfortunately a lot of targets 'make test-e2e-node' included, build binaries, so we can't easily show traceback in one case and don't show in another. Removing BASH_COMMAND from the output looks like a good trade-off to me, though. It has a little bit more info(sometimes usefull) about callstack and less verbose than currently. I'm also ok with reverting and investigating later.
/assign

Discussion:
local stack_skip="${3:-0}" stack_skip=$((stack_skip + 1)) <del> # Always print the error message, regardless of KUBE_VERBOSE value kube::log::error "${message}" # Additional debug information printed if KUBE_VERBOSE is 4 or greater </del> if [[ ${KUBE_VERBOSE} -ge 4 ]]; then local source_file=${BASH_SOURCE[${stack_skip}]} local source_line=${BASH_LINENO[$((stack_skip - 1))]}