Feature Request: Adding a --concise flag to more commands

[amtrack]

When dealing with thousands of metadata components or hundreds of Apex unit tests, some CI logs are almost 10 MB large and it is difficult to browse and search the logs.

@daveespo reported a similar issue forcedotcom/salesforcedx-apex#243 2.5 years ago.

I'd like to have a --concise flag for more commands which reduces the human output printed on the terminal to a minimum.

Here are a few examples of what I could imagine a --concise flag could do:

1. sf apex run test --concise --result-format human: still display details for all failed tests but only show a summary of passed tests (e.g. number of passed tests)
   Notes:

   • I'm mostly interested in the failures.
   • I've tried to use Bash redirection and only show the output in case of a failure, but this isn't a good solution.

2. sf project retrieve start --concise: still display errors/warnings/problems but only show a summary of retrieved components (e.g. number of retrieved components/files)
   Notes:

   • I'm mostly interested in whether there were problems or whether some of my requested components were ignored by .forceignore.

In general I assume that JSON output shouldn't be changed. Or are there any use cases to change the JSON output as well?

I'd appreciate if the Salesforce team implements this to have a common understanding/behaviour of --concise in all official commands. 😄

[mshanemc]

we've had a request before about really large --json needing to omit successes because it was causing buffer overflow in some environment.

project deploy start has --concise where it does filter the json so we'd probably do the same here for similar reasons and to have consistent behavior.

[mshanemc]

for #1, that's code not owned by the CLI team (VSCode uses the same library and the result formatting/printing stuff is part of the library.

So I can't commit to that part without getting them on board.

[AllanOricil]

I believe cli team could solve this problem enabling custom log transports so that developers can choose to use services that were created to interact with logs, such as cloudwatch, datadog, relic and more. This would solve 2 problems at once:

1. no more buffer issues as logs are streamed when using clients that were created specifically to interact with logs.
2. Inspecting logs become much easier in clients that are made for it.

Read more about logger transports here:
https://github.com/winstonjs/winston/blob/master/docs%2Ftransports.md

Why concise does not seem an ideal solution for the use case mentioned above?

concise should be seen as a way to reduce the amount of logs only, and not as a way to enable logs to be read in file editors because it reduces the size of the output file enough to be loaded into mem. This is not ideal. Developers have to learn about tools that are created specifically to handle logs.

Proposal:

Developers can use and create their own custom log transports. These transports are just oclif plugins. Salesforce can create one as an example to guide people.

Then developers will install their desired log transport on the sf cli

sf plugins install sf-datadog-log-transport --default

# a custom log transport plugin can have multiple different transports, something like what winston logger offers

sf plugins install sf-my-amazing-multiverse-log-transport --default

There would exist a required env variable [email protected] to set the default log transport, which receives a package name following npm packages convention (versioning is important). When installing a log transport using --default, this env variable is automatically set.

From now on, developers can do whatever they want with sf cli logs.

Use winston api to ease the creation of custom log transports.

With this solution developers can even send logs to their self-hosted (it could even be local app) logger tool.

local logger tool

This is an alternative to datadog which developers could use locally to analyze logs generated by sf cli when using a custom logger transport

https://github.com/SigNoz/signoz

And in this link people can see other alternatives they can install locally

https://www.opensourcealternative.to/alternatives-to/Datadog

Hope this helps people stop opening logs on text editors

API

It would be necessary to Inject command context in the custom logger transport because developers might want to create transports that process logs for certain commands. For example, devs are interested to send logs of a 1 or 2 commands to datadog only, because their outputs are always huge.

function registerCustomLoggerTransport(cliComandContext, customLoggerTransport){
    customLoggerTransport.bind(cliCommandContext);
    logger.addTransport(customLoggerTransport);
}

[amtrack]

UPDATE: sf v2.56.7

NEW: The apex run test and apex get test commands now have a new --concise flag

Setting this flag for apex run test or apex get test will suppress passing test results and the code coverage table. Only failing tests and the summary table will be displayed. (plugin-apex PR salesforcecli/plugin-apex#504, Github Issue forcedotcom/salesforcedx-apex#243, Github Discussion #2872)

Many thanks to Kyle Capehart for contributing this useful new flag!