Setting logger in CLI tasks

[PehaSimCorp]

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

[ITaluone]

How to handle the case where I want to ignore some log lines e.g. in a dotnet publish command (publishing a windows app), per default tries to invoke the tool mspdbcmf.exe. But this tool cannot be found and makes no difference at all. So until now I ignored such warnings with:

if (msg.Contains("warning : Path to `mspdbcmf.exe` could not be found.", StringComparison.Ordinal))
    return;

[matkoch]

I'd appreciate it if everyone could share their specific use-cases. I.e., for which tool you need to set a custom logger, and what messages you're trying to change severity / skip completely. From all I know, there's a high chance that a bunch of these should be built-in so everyone benefits from the parsing knowledge. I'm aware that others, like PowerShell invocations with custom scripts, are a very different topic.

I need more ground to make a decision, so far the obsoletion was just to ring some bells.

[lg2de]

1. Running DotNetBuild I want to prevent that warnings from the "Sonar Analyzer" are not marked as "warning". The Sonar Qube Server is responsible to communicate the issues, not the DevOps Server Pipeline run.
2. Running SonarScannerEnd failes if the SQ server reports failed the quality gate. But, I do not want to break the build. We are creating a Pull Request comment instead to verify the issue(s). So, I set the ProcessExitHandler to ignore the exit code.

[matkoch]

@PehaSimCorp I already said "specific use-cases". What you're describing is already known / too general.

[PehaSimCorp]

@matkoch, excuse my frustration here but if the "Specific use cases" were known, why is it being retired without a documented replacement?

[matkoch]

@PehaSimCorp excuse my frustration if you can't read a comment to the end

[dennisdoomen]

Here's an example from our codebase:

  DockerTasks.DockerExec(s => s
      .SetInteractive(true)
      .SetContainer(options.DockerContainer)
      .SetProcessLogger(logger.Log)
      .SetProcessExitHandler(p => p.AssertZeroExitCode())
      .SetArgs("sh", "-c")
      .SetCommand(dockerCommand)
  );

We intercept the logging to feed it into a piece of code that will scan the log for Oracle-specific warnings and errors and, depending on the configuration, change the log levels so to ignore certain things.

[kusc-leica]

I think the problem arises from the fact that a lot of tools write also warning and informative messages to stderr. It is a very common practice among modern tooling and Nuke picks it up as error logs. Unfortunately there is not really an agreed standard to differenciate different severity levels on stdout/stderr.

Just to name a few which are also built-into nuke:

• NPM. NPM has some prefixes like NPM warn and NPM notice to indicate severity.
• Docker
• Git

My usecase goes a bit beyond just redirecting the logs but I actually want to react on the outputs of these tools. Depending on the output of the tool I take decision if the "error messages" are neglectable or not. Beside changing the severity for some specific messages, I also take later decision if the failed execution is a pipeline error or not. Some example use-cases are:

• We have an advanced Git it merging process with a variety of branching, merging and fetch commands. Repositories might be cloned as sparse with branch-specs and shallow. e.g. on a fetch --unshallow it might print fatal: --unshallow on a complete repository does not make sense so we react and now it is not a shallow clone shallow and proceed accordingly.
• For NPM we detect authentication related errors from the outputs like npm ERR! code E401
• On various docker command we react on whether the docker daemon might be stopped on the system based on the stderr.

Beside the SetProcessLogger we also face problems with the missing SetProcessExitHandler. I understand that you want to make Nuke better and bring better error and output handling on the built in tools. But let's be realistic: Nuke cannot catch up with all the 3rd party tools and provide semantic output and error handling for all of them as some needs are simply specific to the pipelines to react accordingly.

While I would definitely appreaciate also some additional out-of-the-box output and exit code handling I also see the strong need of being able to customize when needed. I understand your wish to get improvements directly into Nuke, but expecting everyone to provide concrete use-cases and/or contribute concrete changes to Nuke is not really a user-friendly approach. IMO SetProcessLogger was a good solution for the needs of customization.

Similarly the replacement of SetProcessExitHandler with SetProcessExitHandling removes the possibility of reacting on the exit code yourself completely.

[dennisdoomen]

I suggest we do both. Try to improve the logging of built-in tools and allow customizations for the tools that are not supported.