Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Return separate error codes for fixable vs. non-fixable errors. #930

Closed
greg-1-anderson opened this issue Mar 20, 2016 · 4 comments
Closed
Milestone

Comments

@greg-1-anderson
Copy link

At the moment, phpcs returns with an exit code of 0 when no errors or warnings are found, and a 1 if there are any errors or warnings. The exit code is the same regardless of whether the errors are fixable or not.

It would be nice if phpcs would return an exit code of 2 when one or more of the encountered errors or warnings were fixable by phpcbf.

@aik099
Copy link
Contributor

aik099 commented Mar 20, 2016

Isn't fact, that errors are fixable reflected in report itself?

@gsherwood
Copy link
Member

Exit code 2 has always been used for error cases, so I'd need to put in arbitrary exit code of 3 for this.

If there a reason you can't just read an error report, or use a custom report that outputs whatever values you want (--report=/path/to/your/report.php)? A custom report allows you to control the output for a run, which doesn't need to be human readable if you don't want it to. You can also send your custom report output to one file and standard report output to another, if you need that.

Here is an example report used for a SublimeText plugin. It prints a special header message if there are fixable errors in the file: https://github.com/squizlabs/sublime-PHP_CodeSniffer/blob/master/STPluginReport.php

@greg-1-anderson
Copy link
Author

I don't care much about which exit code is used; 3 is as good as any other value.

The use-case is for a wrapper script that asks the user if they want to call phpcbf to fix the errors reported, if there are any. This is a minor issue, but would be nice to have.

@gsherwood
Copy link
Member

gsherwood commented Jun 30, 2016

Thinking about this again, exit code 3 makes no sense - feels like a bolt-on hack. It's going to be nicer to use the following codes:

0: no errors found
1: errors found
2: fixable errors found
3: processing error

So I'll target this for 3.0 and do a BC break with everything else I'm breaking over there.

@gsherwood gsherwood added this to the 3.0 milestone Jun 30, 2016
gsherwood added a commit that referenced this issue Jun 30, 2016
…tween fixable and non-fiable errors (request #930)

The meaning of codes is now:
0: no coding standard errors found
1: coding standard errors found, but none are fixable
2: fixable coding standard errors found
3: script processing error
arnested added a commit to arnested/gulp-phpcs that referenced this issue May 15, 2017
arnested added a commit to arnested/gulp-phpcs that referenced this issue May 15, 2017
arnested added a commit to arnested/gulp-phpcs that referenced this issue May 15, 2017
arnested added a commit to arnested/gulp-phpcs that referenced this issue May 15, 2017
arnested added a commit to arnested/gulp-phpcs that referenced this issue May 17, 2017
arnested added a commit to arnested/gulp-phpcs that referenced this issue May 17, 2017
# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

No branches or pull requests

3 participants