Skip to content
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

Don't fail on stderr output, but print the output to stderr #110

Merged
merged 4 commits into from
Sep 25, 2016

Conversation

Tapppi
Copy link
Member

@Tapppi Tapppi commented Sep 22, 2016

For #91, this would stop standard-version from failing fast when git or hooks or something prints to stderr, but prints it out. Added test case it for as well. Also, errors are now printed to stderr/console.error instead of stdout/console.log.

/CC @nexdrew @duclet @e-cloud @stevemao @bcoe

@coveralls
Copy link

coveralls commented Sep 22, 2016

Coverage Status

Coverage decreased (-0.3%) to 94.805% when pulling 82cabab on 91-no-fail-fast into 2ce4160 on master.

@Tapppi
Copy link
Member Author

Tapppi commented Sep 22, 2016

I suspect coverage decrease is because the actual amount of code went down, since the git tags error handling got rolled into handleExecError? Can't figure out another reason.

@@ -108,6 +108,17 @@ function outputChangelog (argv, cb) {
})
}

function handleExecError (err, stderr) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought we should handle err and stderr differently?
the problem is with stderr shouldn't terminate the program. But for err we keep the same behaviour. No?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I misread your code. It LGTM now.

Copy link
Member

@stevemao stevemao left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible to test exit code for all different scenarios?

@stevemao
Copy link
Member

I suspect coverage decrease is because the actual amount of code went down, since the git tags error handling got rolled into handleExecError? Can't figure out another reason.

You can check out the coverage output and see why

// If exec returns an error or content in stderr, log it and exit with return code 1
var errMessage = stderr || (err && err.message)
if (errMessage) {
console.error(chalk.red(errMessage))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think when err is null, better to use console.warn to output the error message. Red message means real error.
Since console.error/warn's output will have its own color, should it continue to use chalk to control the color?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since console.error/warn's output will have its own color

I don't think so

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The console.warn() function is an alias for console.error().
https://nodejs.org/api/console.html#console_console_warn_data

Copy link
Member Author

@Tapppi Tapppi Sep 23, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should print to stderr (console.error), but how about yellow color for when the exit code was 0?

Since console.error/warn's output will have its own color, should it continue to use chalk to control the color?

AFAIK chalk should handle coloring the output correctly regardless of the stream it will be printed to.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sorry for my poor knowledge, yellow would be great!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in 458da35

@Tapppi
Copy link
Member Author

Tapppi commented Sep 23, 2016

@stevemao:

Is it possible to test exit code for all different scenarios?

What do you mean by this? What scenarios should we be checking for? One thing that is missing, is rolling back changes made by standard-version when the whole process doesn't go through, but I think that's another PR as it's a bigger change.

You can check out the coverage output and see why

Thanks! Yeah, the missed line count stayed the same at 4, but overall line count went down. Should actually find out what is not being tested.. I'll get to it soon, as I'll have some time.

@coveralls
Copy link

coveralls commented Sep 23, 2016

Coverage Status

Coverage decreased (-0.3%) to 94.805% when pulling 458da35 on 91-no-fail-fast into 2ce4160 on master.

@stevemao
Copy link
Member

stevemao commented Sep 24, 2016

Is it possible to test exit code for all different scenarios?

looks like we only test result.code.should.equal(0), but not 1. As long as we cover all scenarios we are fine :)

Nice work! @Tapppi

Copy link
Contributor

@e-cloud e-cloud left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

code logic could be more clear

var errMessage = stderr || (err && err.message)
if (errMessage) {
console.error(chalk.red(errMessage))
console.error(err ? chalk.red(errMessage) : chalk.yellow(errMessage))
if (err) {
process.exit(1)
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Tapppi , i think it would be better to be:

    if (err) {
      console.error(chalk.red(stderr || err.message))
      process.exit(1)
    } else if(stderr) {
      console.warn(chalk.yellow(stderr))
    }

the prior stderr in console.error could be dropped.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea, changed in 6338f32

@coveralls
Copy link

coveralls commented Sep 24, 2016

Coverage Status

Coverage decreased (-0.3%) to 94.805% when pulling 6cf3cbd on 91-no-fail-fast into 2ce4160 on master.

@coveralls
Copy link

coveralls commented Sep 24, 2016

Coverage Status

Coverage decreased (-0.3%) to 94.805% when pulling 6338f32 on 91-no-fail-fast into 2ce4160 on master.

Copy link
Member

@stevemao stevemao left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@bcoe
Copy link
Member

bcoe commented Sep 25, 2016

@Tapppi looks good to me land it.

@stevemao stevemao merged commit f9984d0 into master Sep 25, 2016
@stevemao stevemao deleted the 91-no-fail-fast branch September 25, 2016 00:46
stevemao pushed a commit that referenced this pull request Sep 25, 2016
…#110)

* test: add test for not exiting on stderr content and match stderr output

* feat: don't fail fast on stderr content, and print stderr, closes #91

* fix: print warnings in yellow instead of red

* style: simplify handleExecError if logic
@e-cloud
Copy link
Contributor

e-cloud commented Sep 26, 2016

when will this fix release? coz now it's some kind of blocking bug.

@e-cloud
Copy link
Contributor

e-cloud commented Sep 26, 2016

a beta release is welcomed too.

@stevemao
Copy link
Member

@bcoe could you publish this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

5 participants