Unable to deescalate tools that log to the error stream even though the outcome is successful in the near future? #1455
PehaSimCorp
announced in
General
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Usage Information
Nuke: 9.0.1, .net9.0, windows
Description
We just upgraded to Nuke 9.0.1 and logging is moving towards an attribute based system. In the upgrade to Nuke 9.0.1, the ToolOptions extension "SetProcessLogger" is marked as obsolete (To be removed), and the DockerTasks.DockerLogger has been removed.
What is the preferred way to deescalate tools that log to the error stream even though the outcome is successful? Could the FAQ be updated for the tools that are notoriously logging to the error stream while the outcome is still successful?
I apologize if this isn't a bug, I wasn't sure how to categorize this.
Reproduction Steps
DockerTasks.DockerImageBuild(x => x .AddBuildArg($"ASSEMBLYVERSION=\"{GitVersion.AssemblySemVer}\"", $"FEED_ACCESSTOKEN=\"{NuGetToken}\"") .AddTag(generatedImageName) .SetFile(RootDirectory / "src" / DockerFilePathRelativeToSrc) .SetPath(RootDirectory / "src") .SetProcessLogger((x , y) => { if (IgnoreErrorLogfileOutputFromDocker) { Logger.Info(y); } }));
(Above raises an obsolete message, but cannot add attributes to class outside of assembly)
Expected Behavior
Know how to override the Logger after "SetProcessLogger" is removed. The FAQ has been updated with the preferred way to address this problem.
Actual Behavior
We do not know how to override the logger correctly.
Regression?
8.1.4
Known Workarounds
Continue to use the SetProcessLogger method, use the command line tool instead?
Could you help with a pull-request?
No
Beta Was this translation helpful? Give feedback.
All reactions