Changes to deploy output?

[gdman]

Summary

Have there been recent changes to the deploy console output again?

Since the most recent build the output is much less clear than it was in the previous version.

Before - clear output that says how many components and tests:

After - output that probably looks nice and pretty in an interactive terminal but is much worse in CI output (where deploy is most commonly run):

Version: 2.63.7

[github-actions]

Hello @gdman 👋 It looks like you didn't include the full Salesforce CLI version information in your issue.
Please provide the output of version --verbose --json for the CLI you're using (sf or sfdx).

A few more things to check:

• Make sure you've provided detailed steps to reproduce your issue.
  • A repository that clearly demonstrates the bug is ideal.
• Make sure you've installed the latest version of Salesforce CLI. (docs)
  • Better yet, try the rc or nightly versions. (docs)
• Try running the doctor command to diagnose common issues.
• Search GitHub for existing related issues.

Thank you!

[github-actions]

Thank you for filing this issue. We appreciate your feedback and will review the issue as soon as possible. Remember, however, that GitHub isn't a mechanism for receiving support under any agreement or SLA. If you require immediate assistance, contact Salesforce Customer Support.

[smithmd]

I'd like to also add the feedback that while this change is nice in a normal terminal's output, it makes my CI output completely unreadable and the page is a mile long. I was hoping that SF_USE_PROGRESS_BAR would help, but it seems that env var does nothing now.

[git2gus]

This issue has been linked to a new work item: W-17060727

[VivekMChawla]

@smithmd and @gdman - Thank you for your feedback. We're working on a fix now.

Once fixed, the CI output will look like this:

► Deploying Metadata...
   Components: 21/30 (70%)
   Components: 28/30 (93%)
   Components: 29/30 (97%)
   Components: 30/30 (100%)
► Running Tests...
   Tests: 4/1377 (0%)
   Tests: 8/1377 (1%)
   Tests: 70/1377 (5%)

And will follow these rules:

1. Polling for status updates will occur every five seconds
   • This interval can be modified via an ENV variable.
2. Updates, like Components: 21/30 (70%), will only print when information changes, preventing long pages of output.
3. If five minutes pass with no updates, the last update will be printed again.
   • This serves as a "heartbeat" for folks with "no output timeout" configurations in their CI system. See #1126 for additional context.
   • This "heartbeat" interval can be modified via an ENV variable.

Feedback or questions?

Please let us know if you think the proposed fixes will work or if we've missed anything.

Thank you!

[gdman]

That sounds great to me. Thanks for the fast response!

[gdman]

@VivekMChawla

Feedback or questions?

Please let us know if you think the proposed fixes will work or if we've missed anything.

Thank you!

I had one thought overnight. How are component/test failures handled? Is there immediate feedback in the build output or does the user need to wait until the end?

There have been a few iterations of deploy logging over the years, some have provided instant logging of a component or test failure, whereas others say there is an error but not what it is or nothing until the end. Deploy processes can be long - test runs can take hours, the sooner the developer knows about any failure the better. For context, the developers don't necessarily have access to the org where a build is being validated so the only thing they have to go on is the logs.

[avesolovksyy]

@VivekMChawla
Is it possible to keep the old output as default behaviour, but introduce some switcher for guys who want this "better" more detail output?
With such changes to default behaviour of sf cli (not just output formatting), you are making cli less stable and predictable with new releases.

Regarding this particular change, after upgrading to latest cli version I got ~2 million records of output in my CI/CD logs for metadata retrieve, validate and deploy jobs. In some cases browser tab is simply crashing when I try to open jobs with such big logs.

Moreover, we've found that some of our pretty heavy metadata retrieve jobs for big orgs are simply crashing due to heap out of memory errors - I got all this trouble just becuase of this "better" output, I've not been asking for)