-
Notifications
You must be signed in to change notification settings - Fork 3.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cypress run does not log stderr from plugins #5884
cypress run does not log stderr from plugins #5884
Conversation
Thanks for the contribution! Below are some guidelines Cypress uses when doing PR reviews.
PR Review ChecklistIf any of the following requirements can't be met, leave a comment in the review selecting 'Request changes', otherwise 'Approve'. User Experience
Functionality
Maintainability
Quality
Internal
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @santoshyadav198613 We will need some tests written to verify this new behavior.
There is a Contributing guide that covers how to contribute and get Cypress running locally in generally here: https://github.com/cypress-io/cypress/blob/develop/.github/CONTRIBUTING.md#L500:L500
Instructions for running the cli
tests can be found here: https://github.com/cypress-io/cypress/blob/develop/cli/README.md
The tests for this specific spawn.js
file are here: https://github.com/cypress-io/cypress/blob/develop/cli/test/lib/exec/spawn_spec.js#L2:L2
Let us know if you have trouble getting the tests running locally.
Great will write the test case, thanks. |
Hi @jennifer-shehane , I am using windows7 and node 12. |
Try pulling this branch down, #5888 was just merged and that should fix the issue you're experiencing on Windows. |
ab32c7a
to
3e742ed
Compare
Hi @flotwig and @jennifer-shehane , |
Great, I want to do some testing and make sure it doesn't cause us to leak any extra |
Test added, so dismissing my previous review.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried testing this by merging it into the PR for #5269 and no stderr was captured for 1_system_node_spec
. onStderrData
gets passed as filterFn
here:
Lines 34 to 47 in 004067c
function shouldShowStderrLine (line, filterFn) { | |
// bail if this is warning line garbage | |
if (isGarbageLineWarning(line)) { | |
return false | |
} | |
// if we have a callback and this explictly returns | |
// false then bail | |
if (filterFn && filterFn(line) === false) { | |
return false | |
} | |
return true | |
} |
So this code change doesn't make a difference. I think that what needs to happen is, if debugElectron
is enabled, filter out the logs that are produced by electron and send them to debugElectron(line)
, otherwise, send them directly to stderr.
Cool @flotwig Will check it , will let you know if I need any help. |
adf047b
to
a66d09a
Compare
Hi @flotwig , |
@santoshyadav198613 Hey, do you still need help with this PR? I do not see any failing tests currently in CI, was there some staged code that you had questions about or is this ready for rereview? |
Hey @jennifer-shehane, yeah looks like CI is green, can you help with the review. |
cli/lib/exec/spawn.js
Outdated
@@ -251,8 +251,12 @@ module.exports = { | |||
// the stderr logs unless we've explicitly | |||
// enabled the electron debug logging | |||
if (!debugElectron.enabled) { | |||
debugElectron(str) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't make sense - "if the Electron debugger is disabled, then log this using the Electron debugger"?
cli/lib/exec/spawn.js
Outdated
@@ -251,8 +251,12 @@ module.exports = { | |||
// the stderr logs unless we've explicitly | |||
// enabled the electron debug logging | |||
if (!debugElectron.enabled) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since there was a PR to ignore garbage coming from Electron #4644, I'm almost wondering if we can just get rid of lines 253-259 and return true
here. Theoretically, all other stderr should either be from the plugin, or from a genuine error in Cypress.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's a problem on Linux, where we always log Electron's Chromium stderr by enabling , which isn't filtered out:
Lines 247 to 256 in 719fd98
const userFriendlySpawn = (linuxWithDisplayEnv) => { | |
debug('spawning, should retry on display problem?', Boolean(linuxWithDisplayEnv)) | |
let brokenGtkDisplay | |
const overrides = {} | |
if (linuxWithDisplayEnv) { | |
_.extend(overrides, { | |
electronLogging: true, |
Lines 158 to 160 in 719fd98
if (electronLogging) { | |
stdioOptions.env.ELECTRON_ENABLE_LOGGING = true | |
} |
So if a regex could be added to GARBAGE_WARNINGS
to filter Electron's Chromium stderr, we can just remove lines 253-259 in spawn.js
.
We still need to keep these Chromium stderrs though, because we rely on them to know why Cypress crashed in some situations:
Lines 260 to 262 in 719fd98
if (util.isBrokenGtkDisplay(str)) { | |
brokenGtkDisplay = true | |
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@santoshyadav198613 Do you want to try to implement this, or would you prefer me to do it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am traveling till 8th Feb, I can take it after that. But if you think it's urgent, please go ahead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for opening this PR!
Hey @santoshyadav198613, will you have time to address the changes asked of this PR? We will have to close this due to inactivity otherwise. |
Sorry for delay, will get the issues sorted tomorrow. |
a66d09a
to
711100f
Compare
Hi @jennifer-shehane , |
711100f
to
7fc0b81
Compare
7fc0b81
to
fa2b0d4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@santoshyadav198613 it looks like the comment here hasn't been addressed:
to clarify, we want to hide the Electron Chromium debug output. With the change you've made, all stderr from the Electron process will be printed, which is good. But it means we will also get lots of log lines in a format like this:
[25129:25129:0220/105230.858006:ERROR:vaapi_wrapper.cc(417)] vaInitialize failed: unknown libva error
These come from the Chromium process inside of Electron. There needs to be a regex added to GARBAGE_WARNINGS
to block these lines from getting printed out with the rest of the stderr. They should be sent to debugElectron
instead, so if somebody really needs to see these logs, they can by using DEBUG=cypress:electron
. Otherwise, all Linux users will see tons of garbage from Electron in their stderr.
Hey @santoshyadav198613, will you have time to address the changes mentioned here #5884 (review)? We will have to close this due to inactivity otherwise. |
Closing due to inactivity. Please reopen the PR or open a new PR to address the changes required for this issue. |
Fixes #5765
User facing changelog
Additional details
How has the user experience changed?
PR Tasks
cypress-documentation
?type definitions
?cypress.schema.json
?