chilio / laravel-dusk-ci

Docker Test suite for Laravel Dusk in gitlab CI
MIT License
159 stars 51 forks source link

MySQL Connection refused #36

Closed Sch-Tim closed 5 years ago

Sch-Tim commented 5 years ago

This is a similar issue like #24

I have this yml file:

stages:
- build
- test
- deploy

# Variables
variables:
  DB_HOST: mysql-test
  MYSQL_DATABASE: laravel
  MYSQL_ROOT_PASSWORD: secret
  DB_CONNECTION: mysql

composer:
  image: lorisleiva/laravel-docker:latest
  stage: build
  script:
  - cp .env.gitlab-testing .env
  - composer install --no-progress --no-interaction
  - php artisan key:generate
  artifacts:
    paths:
    - vendor/
    - bootstrap/
    - .env
  cache:
    key: ${CI_BUILD_REF_NAME}
    paths:
    - vendor/
  tags:
  - docker

npm:
  image: lorisleiva/laravel-docker:latest
  stage: build
  script:
  - npm install
  - npm run prod
  artifacts:
    paths:
    - public/mix-manifest.json
  cache:
    key: ${CI_BUILD_REF_NAME}
    paths:
    - node_modules/
  tags:
  - docker  

dusk:
  stage: test
  dependencies:
  - composer
  - npm
  tags:
  - docker
  cache:
    key: ${CI_BUILD_REF_NAME}
    paths:
    - vendor
    - node_modules
    policy: pull

  services:
  - name: mysql:5.7
    alias: mysql-test

  image: chilio/laravel-dusk-ci:latest
  script:
  - cp .env.dusk.gitlab-testing .env
  - cp phpunit.dusk.xml phpunit.xml # if you are using custom config for your phpunit tests in CI
  - configure-laravel
  - start-nginx-ci-project
  - php artisan dusk --colors --debug

  artifacts:
    paths:
    - ./storage/logs # for debugging
    - ./tests/Browser/screenshots
    - ./tests/Browser/console
    expire_in: 7 days
    when: always

And am getting the same connection refused errors when running this. I also tried to add a sleep and investigate this from the inside... From the inside everything looks good, but dusk is failing.
A bit more detailed here: https://stackoverflow.com/questions/53794231/gitlab-ci-dusk-mysql-connection-refused

chilio commented 5 years ago

@Sch-Tim probably because you don't have these variables:

 MYSQL_USER: user
 MYSQL_PASSWORD: secret

Remember that these values need to match your .env. Note: mysql doesn't allow root to connect from remote host by default

Sch-Tim commented 5 years ago

Thanks for your response! I followed your instructions, but without success.
Like in the past, PHPUnit tests run (still) perfectly.
image

My .dusk.gitlab-testing file looks now like this:

APP_ENV=local
APP_KEY=
APP_DEBUG=true
APP_LOG_LEVEL=debug
APP_URL=http://localhost

LOG_CHANNEL=stack
HEADLESS=true

DB_CONNECTION=mysql
DB_HOST=mysql-test
DB_DATABASE=laravel
DB_USERNAME=laravel
DB_PASSWORD=secret

My phpunit.dusk.xml file:

<?xml version="1.0" encoding="UTF-8"?>
<phpunit backupGlobals="false"
         backupStaticAttributes="false"
         bootstrap="vendor/autoload.php"
         colors="true"
         convertErrorsToExceptions="true"
         convertNoticesToExceptions="true"
         convertWarningsToExceptions="true"
         processIsolation="false"
         stopOnFailure="false">
    <testsuites>
        <testsuite name="Feature">
            <directory suffix="Test.php">./tests/Feature</directory>
        </testsuite>

        <testsuite name="Unit">
            <directory suffix="Test.php">./tests/Unit</directory>
        </testsuite>
    </testsuites>
    <filter>
        <whitelist processUncoveredFilesFromWhitelist="true">
            <directory suffix=".php">./app</directory>
        </whitelist>
    </filter>
    <php>
        <env name="APP_ENV" value="testing"/>
        <env name="CACHE_DRIVER" value="array"/>
        <env name="SESSION_DRIVER" value="array"/>
        <env name="QUEUE_DRIVER" value="sync"/>
    </php>
</phpunit>

I changed my variables part to this:

variables:
  DB_HOST: mysql-test
  MYSQL_DATABASE: laravel
  MYSQL_USER: laravel
  MYSQL_PASSWORD: secret
  MYSQL_ROOT_PASSWORD: secretroot
  DB_CONNECTION: mysql

While investigating this a bit further, I noticed another mysterious thing. When I use this .xml file php artisan dusk doesn't run my browser tests but my Unit tests. image When I change this:

        <testsuite name="Feature">
            <directory suffix="Test.php">./tests/Feature</directory>
        </testsuite>

        <testsuite name="Unit">
            <directory suffix="Test.php">./tests/Unit</directory>
        </testsuite>

to this:

        <testsuite name="Browser">
            <directory suffix="Test.php">./tests/Browser</directory>
        </testsuite>

It runs the Browser tests but with the connection refused errors.

This is my driver() function btw.

    protected function driver()
    {
        $options = new ChromeOptions();
        $options = $options->addArguments([
            '--disable-gpu',
            '--headless',
            '--no-sandbox',
        ]);

        $capabilities = DesiredCapabilities::chrome()->setCapability(
            ChromeOptions::CAPABILITY, $options);

        return RemoteWebDriver::create(
            'http://localhost:9515', $capabilities
        );
    }
chilio commented 5 years ago

This sounds strange. Few questions then:

  1. What versions are you running (Laravel, this package, docker, gitlab, hosting)?
  2. Can you make build stage using this package only to verify if it's not cross package issue?
  3. Are you sure, that you don't have any other mysql instances named mysql-test in your gitlab environment?
  4. If it still doesn't help, please tell me more, what have you verified on running instance after sleep? (BTW this is the right approach to track problems down)
  5. As a last resort, please try to run builds and tests in one stage to eliminate complexity.

Let me know, I'll try to help...

chilio commented 5 years ago

And one more thing which I believe you should try first... My questions are still valid, however in test stage you are overriding .env with your default one without app_key. If it is present from cache then you don't need to. If it's not present then something went wrong on build stage, and you can try to recreate it. Hope it will lead you to solution...

Sch-Tim commented 5 years ago

Thanks for your help! It turned out that the problem had nothing to do with any "common" problem. It's stupid and a bit emberassing but almost funny... I refresh and reseed my database in the setUp function. The problem was that I added the --database option and used a parameter which fit locally but of course not in the CI environment.
The tests are still running so I can't definitely say it works, but in the prior tries it needed about 15 seconds to rush through all tests. So it's a good sign.
Thanks again for your effort and sorry for the somehow wasted time.

chilio commented 5 years ago

Great to hear it works 👍