-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
feat: add option to use posix exit code upon fatal signal #4989
base: master
Are you sure you want to change the base?
Conversation
This PR hasn't had any recent activity, and I'm labeling it |
We should probably disable the stale action, pending picking up reviewing PRs. |
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.
Nice and clean implementation, thanks! ✨
Requesting changes on a few things. But let me know, please, if I'm off base here 🙂.
Note that after this lands, we'll want to file a followup issue about making this the default behavior in some future version of Mocha. |
Co-authored-by: Josh Goldberg ✨ <git@joshuakgoldberg.com>
Address PR review comments mocha org
Address PR review comments mocha org
@JoshuaKGoldberg Thanks for the review! Hopefully that latest update addresses your questions, but let me know if there's anything else you'd like to see. Looking froward to not using our own fork of mocha! 😆 |
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.
Progress! Thanks for adding in the tests. I think we'll need to capture some more cases?
Co-authored-by: Josh Goldberg ✨ <git@joshuakgoldberg.com>
Co-authored-by: Josh Goldberg ✨ <git@joshuakgoldberg.com>
Address PR comments; use os.constants
@JoshuaKGoldberg do you want to take a look at this again? I went with your suggestion to exit with 1 like Jest and Vitest when you've asked for posix/unix shell exit codes and you've got test failures. @plroebuck raised the point that there's a distinction between posix exit codes and unix shell exit codes but I think the naming is okay given the following documentation from the GNU libc manual page on exit status:
[edit: this mention of non-POSIX systems implies that the exit status reporting described in the GNU libc manual is pretty standard for POSIX systems, hence my feeling that |
Will take a look, thanks! |
Remove test that asserts the problematic behavior
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.
Omit win32 from signals test suite
@JoshuaKGoldberg just circling back to see if there's anything you need from me to unblock this enhancement? lmk 🙏 |
Thanks for the ping! Nothing yet. The other maintainers have been swamped (so much happening in the ecosystem!) but I'm still holding onto hope someone will be able to review. I've personally time boxed this one to within June. |
Update package.json
Requirements
Description of the Change
Mocha uses the number of failed tests as an exit code, which is unconventional and has led to a number of issues when trying to integrate mocha into ci/cd pipelines.
To resolve these issues, this PR introduces a
--posix-exit-codes
boolean command-line option. If this option is specified, a fatal signal (eg.SIGABRT
, et al) will cause the process to consistently exit with a standard posix exit code (128 + the numeric ID of the signal) when mocha is run as a child process (which is the case when passing node options). This helps to solve issues for toolchains that expect standard posix exit codes, for example by preventing out-of-memory crashes from being silently ignored.The GNU libc manual page provides additional context on why using the number of errors as an exit status is problematic:
Providing the option to exit with standard posix shell exit codes avoids these problems and solves a number of downstream issues listed below.
Alternate Designs
The alternatives considered were not in the scope of the mocha project.
Why should this be in core?
This option is implemented in the core repository where signal handling occurs.
Benefits
This PR provides a solution for #3559 and various downstream issues reported by mocha consumers; it preserves non-zero exit codes when mocha is spawned as a child process via various CI/CD or reporting tools and prevents silently swallowing out-of-memory errors.
Possible Drawbacks
Introduces another option. Requires docs. Leaves non-standard exit code behavior to remain as the default.
Applicable issues
fixes #3559
#3893
#2445
#2438
istanbuljs/nyc#798
cypress-io/cypress#24695