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 try to run PhantomJS if there's already something running at the same port #25

Open
igorsantos07 opened this issue Jun 10, 2015 · 3 comments

Comments

@igorsantos07
Copy link

Given #20, we end up by having PhantomJS running all the time. That's not as bad, after all. However, if you try to run tests a second time, it hangs when trying to turn PhantomJS on.
Maybe it could skip running PhantomJS when the port is being used?

@grantlucas
Copy link
Owner

Though Phantoman could be set up to automatically detect an open port, I'm not sure if it would work with WebDriver. The issue is that the WebDriver module and Phantoman need to be set to the same port and I don't think Phantoman could alter WebDriver's settings.

It would be neat to have the open port detection in there but due to the nature of these extensions, I don't think it will be possible.

We use Phantoman in our automated tests in parallel by using a script we wrote to alter the Codeception configuration. So what it does is look for an open available port using PHP Port Finder between a certain range and then alters the Yaml config files to use the new port number for both WebDriver and Phantoman.

Something like that may be overkill for your setup and I'm really hoping #20 will fix all of this.

@igorsantos07
Copy link
Author

Indeed that seems overkill.
However, I didn't meant to detect an available port :)
I think the project could skip running/killing (and maybe print a warning) if the given port is occupied. This way if you already have phantomjs running (given other reasons) there's no need to alter CodeCeption settings to run the tests.
Without that, if we have another phantom running on the same port the tests will fail to run.

@grantlucas
Copy link
Owner

Ah true. Alright, that would be possible! I'll look into getting that added.

grantlucas added a commit that referenced this issue Jun 12, 2015
It seems that `proc_terminate` doesn't reliably shut down child
processes, especially in Windows.

A new method of `killProcess` has been set up that will use Windows
specific `taskkill` and Unix's `kill` to stop the process and its
children.

This in the aim to resolve issue #20 and to mitigate issue #25.
grantlucas added a commit that referenced this issue Jun 12, 2015
It seems that `proc_terminate` doesn't reliably shut down child
processes, especially in Windows.

A new method of `killProcess` has been set up that will use Windows
specific `taskkill` and Unix's `kill` to stop the process and its
children.

This in the aim to resolve issue #20 and to mitigate issue #25.
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

2 participants