-
-
Notifications
You must be signed in to change notification settings - Fork 929
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
Handle non-integer error codes as exit code 1 (#2115) #2140
Handle non-integer error codes as exit code 1 (#2115) #2140
Conversation
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 work @nkabardin! 👍
@davidtheclark thanks! something is frozen on ci though. Can't understand what's happening. |
Checked log on Travis, and there might be issues with running this system test on jenkins — any ideas what's happening there? |
@nkabardin I've restarted the CI tests so lets see what happens... |
Coveralls is failing in both |
So I guess it's something related to |
Playing around with error logging in system test, let's see what CI will tell us... |
2d5400b
to
b05bef1
Compare
did several attempts trying to log out the problems with running stuff, added three Any ideas? |
efae32d
to
02afd14
Compare
Rebased branch over current master (so, support babel drop and no need to use babel-node to run cli) and also and removed all debug stuff and it's currently ready and well tested, and surprisingly issues on CI are also solved, so we got green build there, so yay! |
LGTM, though let's get another review from @davidtheclark 👍 Edit: Coveralls coverage is pretty volatile at the moment with the "drop babel" changes, we can redress any coverage issues in follow up PRs |
Coverage tests were failing if less than 95%, I've dropped that value to 90% So ignore the Coveralls failure here in this PR (I couldn't find a way to restart the job) |
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.
One comment, then let's merge.
const localPath = path.resolve(__dirname) | ||
const cliPath = path.join(localPath, "../../lib/cli.js") | ||
|
||
const cliProcess = spawn("node", [ cliPath, `${localPath}/*.css` ], { cwd: localPath }) |
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.
Could you add an 'error'
listener to this process?
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.
done
02afd14
to
006e775
Compare
006e775
to
e606bbb
Compare
const cliProcess = spawn("node", [ cliPath, `${localPath}/*.css` ], { cwd: localPath }) | ||
|
||
cliProcess.on("error", function (error) { | ||
console.log("error running cli:", error) // eslint-disable-line no-console |
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 think we should have failed test if have error in error
event
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.
it fails anyway if there is an error, it just added logging for that.
Couldn't reproduce a case when it didn't fail on error
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.
@nkabardin we can use mock
for reproduce error, we got non zero code (thoretically 😄 ) and test failed, lgtm
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 didn't get it, current code looks good to you, or it will look good to you when some mocking will be added? :)
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.
@nkabardin no, all ok
Thanks again @nkabardin! |
Changelog entry
|
@davidtheclark glad I was able to help the project! thanks for |
Fixes #2115
When there is an error in require() in configuration file, cli gets an error code which is not actually integer, so passing it to process.exit is not a good idea.
Now value is getting checked if it's a number or not, and if it's not a number, it's replaced with plain
1
.System test added that runs cli in ensures that exit code != 0