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

Runner::runPHPCS() is exiting #1484

Closed
spranger opened this issue May 24, 2017 · 7 comments
Closed

Runner::runPHPCS() is exiting #1484

spranger opened this issue May 24, 2017 · 7 comments

Comments

@spranger
Copy link

spranger commented May 24, 2017

I'd appreciate Runner::runPHPCS() returning to the caller with a return code instead of exiting the whole script.
I run Runner inside a testcase that should fail in case of codesniffer errors in my code.
But because of the exit(...) it never returns to the testcase.

@gsherwood
Copy link
Member

This would be a pretty easy change, but it's not actually going to work like that in all cases. Other parts of PHPCS also exit when they encounter errors, and there is no current way for them to instead pass up that code to the main caller so it can return an exit code. So the best I can do is just return the exit codes that the runPHPCS and runPHPCBF methods generate and you'll have to assume you don't have any config errors causing other exits.

If that still sounds ok, I'll make the change, but it's obviously not available to you right now.

If you want to check for PHPCS errors in a test case today, you're best bet is using a custom runner. Something like this: https://gist.github.com/gsherwood/aafd2c16631a8a872f0c4a23916962ac

Or copy the way the runPHPCS() method works but rip out all the bits about generators, explaining standards etc.

@spranger
Copy link
Author

I tried inheriting from the Runner-class, but failed because of several "private" functions.
Making my own CustomRunner. I'd have to re-implement the whole file scanning stuff (or at least borrow the code from somewhere).
Normally, I'd assume an config-error etc. causing exceptions, potentially handled by the calling function.
A "main"-function can simply deal with exceptions and return codes and exit if needed.

@gsherwood
Copy link
Member

The two methods will now return their exit codes from version 3.0.1.

@gsherwood gsherwood added this to the 3.0.1 milestone Jun 11, 2017
gsherwood added a commit that referenced this issue Jun 15, 2017
This allows the exit code to bubble up to the main run methods in the Runner class. It also allows for PHPCBF to be used by a custom runner by catching the DeepExitException and getting the message, which will be the fixed contents.
@gsherwood
Copy link
Member

From version 3.0.2, the exit codes will also work for internal errors. Instead of exiting, the code now throws a new DeepExit exception so that it can be caught higher up in the run methods.

@hchow77
Copy link

hchow77 commented Jul 11, 2017

Not sure if this should be a new issue or if it should be tacked onto this one, but noticed a version of the phpcs phar that I built from the build-phar.php script did not also return an exit code. Noticed the changes for this don't appear to have touched that script and at least from the looks of it, the stub section of build-phar.php that mirrors the code in the bin versions of phpcs/phpcbf may need to get updated as well in order to mirror this functionality for the built phar. Would it be reasonable to make that change as well or is there a specific reason why that was not added to the script?

Thanks for the consideration.

@gsherwood
Copy link
Member

@hchow77 I can't thank you enough for finding that before release - I just plain forgot to change the stub for the phars, but I've fixed that now.

@hchow77
Copy link

hchow77 commented Jul 12, 2017

Great! Already pulled that in a re-ran the build script, and looks like it's working as expected now. Thanks!

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

No branches or pull requests

3 participants