Display daemon messages on standard error

gejohnston commented 1 month ago

What It Does

The zowe executable, which controls the daemon, now sends all informational messages, progress messages, and error messages to standard error instead of standard output.

How to Test

On Linux, you can run a command that starts the daemon and observe that the "starting" message goes to standard error.

$ zowe --version 2>stderr.txt
CLI Version: 8.0.0-next.202405161750
Zowe Release Version: V3

$ type stderr.txt
Starting a background process to increase performance ...

On Windows, redirecting stdout or stderr on a Zowe command when the daemon is being started locks stdout and stderr until the daemon process is terminated. The Zowe command hangs until the daemon is terminated. This is existing daemon behavior. Instead, run one Zowe command just to start the daemon. You can then redirect stdout and stderr on subsequent Zowe commands.

> zowe --version
Starting a background process to increase performance ...
CLI Version: 8.0.0-next.202405161750
Zowe Release Version: V3

# Now that the daemon is running, you can redirect stdout or stderr on Zowe commands.
# Corrupt your environment to cause a daemon communication error, which will
# display an error message on stderr.
#
# In File Explorer, on the file C:\Users\YourUserName\.zowe\daemon\daemon.lock,
# RightClick - Properties - Security - Edit
# Select your user name. Check the following 'Deny' boxes:
# Read & execute, Read, and Write

> zowe --version
Unable to create zowe daemon lock file = C:\Users\ej608771\.zowe\daemon\daemon.lock.
Reason = Access is denied. (os error 5).

> zowe --version 2> stderr.txt
> type stderr.txt
Unable to create zowe daemon lock file = C:\Users\ej608771\.zowe\daemon\daemon.lock.
Reason = Access is denied. (os error 5).

# Undo your changes if you want to run a daemon command ever again.

You can also confirm that the daemon's executable version number continues to be displayed on standard output.

> zowe --version-exe
1.2.3

> zowe --version-exe > stdout.txt
> type stdout.txt
1.2.3

Review Checklist I certify that I have:

[x] tested my changes
[x] added/updated automated tests
[x] updated the changelog
[x] followed the contribution guidelines

Additional Comments

Similar system tests fail on the master branch when run as daemon. My conclusion is that the system tests have not been affected by this change.

codecov[bot] commented 1 month ago

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 91.21%. Comparing base (2214b7a) to head (80fe511). Report is 2 commits behind head on next.

Additional details and impacted files

```diff @@ Coverage Diff @@ ## next #2150 +/- ## ======================================== Coverage 91.21% 91.21% ======================================== Files 628 628 Lines 17891 17891 Branches 3689 3793 +104 ======================================== Hits 16319 16319 Misses 1571 1571 Partials 1 1 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

sonarcloud[bot] commented 1 month ago

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarCloud

github-actions[bot] commented 1 month ago

Release failed for the next branch. :cry:

Error: The process '/opt/hostedtoolcache/node/20.13.1/x64/bin/npm' failed with exit code 1
    at ExecState._setResult (/home/runner/work/_actions/zowe-actions/octorelease/v1/dist/npm.js:974:21)
    at ExecState.CheckComplete (/home/runner/work/_actions/zowe-actions/octorelease/v1/dist/npm.js:960:16)
    at ChildProcess.<anonymous> (/home/runner/work/_actions/zowe-actions/octorelease/v1/dist/npm.js:863:21)
    at ChildProcess.emit (node:events:514:28)
    at maybeClose (node:internal/child_process:1105:16)
    at ChildProcess._handle.onexit (node:internal/child_process:305:5)

Check the workflow run for more error details.

_{Powered by Octorelease :rocket:}