Implement a method "isTtySupported" for setTty method.

[mamor]

I tried dusk with PhantomJS on Wercker. and I have same issue this.
https://laracasts.com/discuss/channels/testing/tty-mode-requires-devtty-to-be-writable

Like that comment "run as script" can be executed.
but Wercker continued build when dusk fails, probably exit code does not return.
This problem will be occored on CircleCI, GitLab CI, cron and more.

I fixed that, change to the same logic Symfony\Component\Process\Process#setTty()
https://github.com/symfony/process/blob/master/Process.php#L1036

and this is execution result.

$ cat /tmp/test.php 
<?php

var_dump(PHP_OS !== 'WINNT');

var_dump(PHP_OS !== 'WINNT' && (bool) @proc_open('echo 1 >/dev/null', [['file', '/dev/tty', 'r'], ['file', '/dev/tty', 'w'], ['file', '/dev/tty', 'w']], $pipes));

iTerm2

$ php /tmp/test.php 
bool(true)
bool(true)

jenkins on MacOSX

+ php /tmp/test.php
bool(true)
bool(false) // no supported tty even if OS is not Windows.

[taylorotwell]

Would like a cleaner solution than this. Just turn off TTY entirely to be honest.

[head1328]

I think this is a real problem. Sometimes tty is available but not writeable. I have a similar problem at the moment:

docker-compose exec -T container php artisan dusk or docker exec -ti container php artisan dusk -> TTY mode requires /dev/tty to be read/writable.

Without -T I will run into this issue: docker/compose#3352

Perpaps it's a docker/docker-compose issue and it will be fixed with docker 1.14.

notice perhaps it's a docker-compose issue because this works for me: docker exec -ti container php artisan dusk

[kevin-coyle]

Yeah I'm getting this issue when trying to run it through Jenkins

[slava-vishnyakov]

Was this fixed anywhere?

[matrunchyk]

The same issue when running php artisan dusk in Bitbucket pipeline:

php artisan dusk --colors --debug

[Symfony\Component\Process\Exception\RuntimeException]
TTY mode requires /dev/tty to be read/writable.

[giolf]

same issue in Gitlab CI

[deleugpn]

Can anybody from this thread confirm if #223 fixes the problem?

@giolf @matrunchyk @mamor

[giolf]

@deleugpn
building time ... i'll let you know soon ...

[giolf]

$ php artisan dusk --colors --debug                                                        
  [Symfony\Component\Process\Exception\RuntimeException]  
  TTY mode requires /dev/tty to be read/writable.
  ERROR: Job failed: exit code 1                                                             

IMHO it's a docker's issue.

If i run:
ls -la /dev/tty
in the container of the pipeline i get:
crw-rw-rw-. 1 root root 5, 0 Apr 17 20:28 /dev/tty

it would seem dev/tty has the right permissions
damn, i need a beer.

[matrunchyk]

@deleugpn I'll give it a try in a few minutes.

[giolf]

@matrunchyk let me know. By me it still doesn't work.

[mamor]

@deleugpn still doesn't work.
https://app.wercker.com/madworks/dusk-on-wercker-example/runs/build/58f602828820930001515994?step=58f60318285d5d0001a2925e

and set "false", worked fine.
mamor/dusk-on-wercker-example@ac0666f#diff-2188cf5d4ddf4333bd48355426788696

https://app.wercker.com/madworks/dusk-on-wercker-example/runs/build/58a90efbf717a60100ba38a7

[matrunchyk]

@giolf You're right! It doesn't work for me as well.
/dev/tty is writeable (and is_writeable/is_readable return true) but it fails unless I set directly false (as @mamor did). Super weird.

[darkblackart]

I try run in php file with ssh, but i have this error:

[2] =>   [Symfony\Component\Process\Exception\RuntimeException]  
[3] =>   TTY mode requires /dev/tty to be read/writable.         

Who knows how to fix?

[matrunchyk]

As a workaround,

1. Run a command

php artisan make:command RunDusk

2. Open app/Console/Commands/RunDusk.php
3. Change declaration class RunDusk extends DuskCommand
4. Remove all methods and properties from this class and add the only one:

public function handle()
    {
        $this->purgeScreenshots();
        $this->purgeConsoleLogs();
        $options = array_slice($_SERVER['argv'], 2);
        return $this->withDuskEnvironment(function () use ($options) {
            return (new ProcessBuilder())
                ->setTimeout(null)
                ->setPrefix($this->binary())
                ->setArguments($this->phpunitArguments($options))
                ->getProcess()
                ->setTty(false) // <--------------------------- DOES THE TRICK
                ->run(function ($type, $line) {
                    $this->output->write($line);
                });
        });
    }

5. php artisan dusk

[mamor]

this problem occurred "Symfony\Component\Process\Process" following line.
https://github.com/symfony/process/blob/master/Process.php#L1039

To solve this problem, should avoid that.

[deleugpn]

@mamor I just pushed #226 to supress that exception

[matrunchyk]

@deleugpn Due to some no-idea-reason it doesn't work.

[deleugpn]

@matrunchyk Sorry if I sound rude, but it has no way of not working. What makes you think it doesn't work?

[matrunchyk]

@deleugpn Ahh sorry, I didn't notice you've changed your original commit. Definitely, now it fixes the issue with TTY.

[mamor]

@deleugpn success on wercker https://app.wercker.com/madworks/dusk-on-wercker-example/runs/build/58f623877314290001d918b2

[mamor]

this problem fixed by #226 https://app.wercker.com/madworks/dusk-on-wercker-example/runs/build/58f627187314290001d91c15?step=58f6279c8380e700019091f9

thanks everyone.

[darkblackart]

@deleugpn Thanks :D

[giolf]

@deleugpn thank you 4 your update.
just one question:
When your update would be available in the composer scope ?
at the moment composer updateseems to don't have yet the last merge.

i mean in the new release.

[deleugpn]

@giolf When Taylor tags a new release. I suggest you to stick with dev-master because this package rarely gets any changes and Taylor doesn't release a new tag each pull request. I bet it might take some time until we make a breaking change.

[CoolGoose]

It seems the problem still exists on CentOS 7.2.1511 using gitlabci with dev-master for dusk (and trying with --colors and --debug)

Warning: TTY mode requires /dev/tty to be read/writable.

The CI does see colors and the tests fail / succeed so not sure if it's something to ignore or not

[deleugpn]

@CoolGoose that is just a warning, the fact that the tests are running means the fix worked. Before, CI tools couldn't even run the tests at all.