Laravel testing in Gitlab CI/CD con MariaDB y edbizarro/gitlab-ci-pipeline-php

Una vez más nos vemos aquí, para contaros mi experiencia con Gitlab Ci, al ir a trabajar con un proyecto que usa MariaDb 10.3 en lugar de Mysql. Dire que hacer pruebas de testing, requiere como mínimo que estas pruebas se hagan emulando el software de la plataforma que usará nuestro software. Mejor aun si hacemos múltiples pruebas con distintas variaciones.

Pero nos encontramos con varios errores, y poca información:

php artisan migrate:fresh --seed
28    Illuminate\Database\QueryException  : SQLSTATE[HY000] [2002] Connection refused (SQL: SHOW FULL TABLES WHERE table_type = 'BASE TABLE')

Análisis

Para mi trabajo uso Gitlab en mi propio servidor VPS, y una instancia de Gitlab en otra máquina VPS, para el Docker de Gitlab donde ejecuto el testing usando, Gitlab-Ci_pipeline-PHP de Edbizarro . (Puedes ver mi artículo Laravel CI con Gitlab, Docker Runner, MySQL 8 y PHP 7.3)

La verdad es que se me antojaba raro el mensaje, que me salió al cambiar mi fichero .gitlab-ci.yml para usar la imagen oficial de MariaDB 10.3 en lugar de Mysql.

SQLSTATE[HY000] [2002]

php artisan migrate:fresh --seed 28 Illuminate\Database\QueryException : SQLSTATE[HY000] [2002] Connection refused (SQL: SHOW FULL TABLES WHERE table_type = 'BASE TABLE')

Cuando uno busca información sobre algo, lo primero que se topa es con una ejército de escritores, que no aportan nada que no sea ruido. Que si a mi me funciona, que si yo lo hice asi, etc

El error de Mysql es claro y sólo tiene tres posibilidades:

1. El servidor MySQL no esta ejecutándose de forma correcta
2. La configuración de acceso a la base de datos es incorrecta, ya sea por credenciales o porque nos dejamos, por ejemplo, en su configuración la prohibición de acceso desde otro host que no sea 127.0.0.1
3. Recursos insuficientes del servidor. En este caso, el mensaje sería SQLSTATE[HY000] [2002] Resource temporarily unavailable 

Teniendo en cuenta que teníamos claros nuestros valores en el fichero .gitlab-ci.yml están correctos de acuerdo a la configuración oficial, algo estaba pasando.

Solución

El problema estriba, en que la imagen oficial de MariaDB, tarda un poco más de lo habitual en tener operativo el acceso a MariaDB de forma remota, por un retardo en la apertura del puerto por TCP.

Así pues la solución pasa por añadir un sleep o parada, en nuestra configuración, cuando vayamos a usar el servicio de mariadb.

stages:
  - preparation
  - building
  - testing
  - security

variables:
  MYSQL_ROOT_PASSWORD: root
  MYSQL_USER: albarid_ci
  MYSQL_PASSWORD: albarid_secret
  MYSQL_DATABASE: albarid_ci
  DB_HOST: mysql

cache:
  key: $CI_BUILD_REF_NAME

composer:
  stage: preparation
  services:
    - name: mariadb:10.3-bionic
      alias: mysql
  image: edbizarro/gitlab-ci-pipeline-php:7.3-alpine
  script:
    - php -v
    - echo "{\"http-basic\":{\"nova.laravel.com\":{\"username\":\"${NOVA_USERNAME}\",\"password\":\"${NOVA_PASSWORD}\"}}}" > ~/.composer/auth.json
    - composer install --prefer-dist --no-ansi --no-interaction --no-progress --no-scripts
    - cp .env.example .env
    - php artisan key:generate
  artifacts:
    paths:
      - vendor/
      - .env
    expire_in: 5 days
    when: always
  cache:
    paths:
      - vendor/


db-seeding:
  stage: building
  services:
    - name: mariadb:10.3-bionic
      alias: mysql
  image: edbizarro/gitlab-ci-pipeline-php:7.3-alpine
  dependencies:
    - composer
  script:
    - echo
    - sleep 10 # Sleep necesario
    - php artisan migrate:fresh --seed
  artifacts:
    paths:
      - ./storage/logs # for debugging
    expire_in: 1 days
    when: on_failure

phpunit:
  stage: testing
  services:
    - name: mariadb:10.3-bionic
      alias: mysql
  image: edbizarro/gitlab-ci-pipeline-php:7.3-alpine
  dependencies:
    - composer
    - db-seeding
  script:
    - php -v
    - sleep 10
    - sudo cp /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini /usr/local/etc/php/conf.d/docker-php-ext-xdebug.bak
    - echo "" | sudo tee /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini
    - ./vendor/phpunit/phpunit/phpunit --version
    - php -d short_open_tag=off ./vendor/phpunit/phpunit/phpunit -v --colors=never --stderr
    - sudo cp /usr/local/etc/php/conf.d/docker-php-ext-xdebug.bak /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini
  artifacts:
    paths:
      - ./storage/logs # for debugging
    expire_in: 1 days
    when: on_failure

codestyle:
  stage: testing
  image: lorisleiva/laravel-docker:latest
  script:
    - phpcs --standard=PSR2 --extensions=php app
  dependencies: []

phpcpd:
  stage: testing
  image: edbizarro/gitlab-ci-pipeline-php:7.3
  script:
    - test -f phpcpd.phar || curl -L https://phar.phpunit.de/phpcpd.phar -o phpcpd.phar
    - php phpcpd.phar app/ --min-lines=50
  dependencies: []
  cache:
    paths:
      - phpcpd.phar

sensiolabs:
  stage: security
  image: edbizarro/gitlab-ci-pipeline-php:7.3
  script:
    - test -d security-checker || git clone https://github.com/sensiolabs/security-checker.git
    - cd security-checker
    - composer install
    - php security-checker security:check ../composer.lock
  dependencies: []
  cache:
    paths:
      - security-checker/

Editado: Desde hace un tiempo dejo de funcionar de esta forma. Hay un artículo que nos lo explica, Sensiolabs, The web service failed for an unknown reason (HTTP 403)

Realizado este cambio, nuestra cola de trabajos podrá procesar el acceso a MariaDB de forma correcta y realizar el seeding.

Aclaración

Un error muy común de los desarrolladores o de los usuarios, es pensar que MySQL y MariaDb son iguales. Ya hace tiempo que no, y sus diferencias, pequeñas, pueden ser un quebradero a la hora de implementar soluciones basadas en uno u otro motor, cuando no hemos comprobado su funcionamiento en ese motor.

Agradecimientos

Como siempre gracias a Unsplash y a Simone Hutsch por la imagen que sirve de portada, que edite gracias a Canva