0

I have setup a meta command like described here https://symfony.com/doc/3.4/console/calling_commands.html

It first deletes the database, then runs a migration from scratch, and finally initializes my data.

I am facing this problem since I recently switched from creating the schema via doctrine:schema:create to doctrine:migrations:migrate

class ResetDatabaseCommand extends ContainerAwareCommand {

   protected function configure()
    {
        $this
        ->setName('app:resetDb')
        ->setDescription('Reset database')
        ->setHelp('Resets the database (only for testing)');
    }

    /**
     * {@inheritdoc}
     */
    protected function execute(InputInterface $input, OutputInterface $output)
    {
        $command = $this->getApplication()->find('doctrine:schema:drop');
        $dropInput = new ArrayInput([
            'command' => 'doctrine:schema:drop',
            '--full-database'  => true,
            '--force'  => true,]);
        $returnCode = $command->run($dropInput, $output);


        $command = $this->getApplication()->find('doctrine:migrations:migrate');
        $migrateInput = new ArrayInput([
            'command' => 'doctrine:migrations:migrate',
            '--no-interaction' => true
        ]);
        $migrateInput->setInteractive(false);
        $returnCode = $command->run($migrateInput, $output);


        $command = $this->getApplication()->find('app:initialize');
        $initInput = new ArrayInput(['command' => 'app:initialize']);
        $returnCode = $command->run($initInput, $output);
        $output->writeln('done.');
    }
}

ok, this does work - SOMETIMES. When I execute this locally it works.

But I am using all this inside docker containers and a Gitlab CI toolchain.

To this end I have a shell script init.sh

#!/bin/bash
set -x # <- does not make a difference
php bin/console app:resetDb --env=prod --no-interaction

which I execute in the setup phase of my Gitlab-CI test action (after the container is running:

docker exec php_container bash init.sh

The output then drives me crazy:

Dropping database schema...

 [OK] Database schema dropped successfully!                                     


                    Application Migrations                    


WARNING! You are about to execute a database migration that could result in schema changes and data loss. Are you sure you wish to continue? (y/n)ERROR: Job failed: execution took longer than 1h0m0s seconds

It means that the first command is executed as it should (drop database), but the second one waits for the "user" to type "y" as confirmation.

Note that I supplied BOTH --no-interaction as well as $migrateInput->setInteractive(false);.

The weird thing is that this command does work well locally, but not as soon as the Gitlab-CI is running it! Edit: even locally, I am running a php docker container. If I execute here on my mac docker exec php_container bash init.sh the script runs correctly!

I am using a local gitlab-ci-runner container on a docker host (I works fine since over a year).

Edit: I also tested to put the 3 commands into the init.sh, with same result. The second script waits for confirmation when executed from gitlab-ci.

Next, I put the three commands into the gitlab-ci.yml directly:

test1:
  stage: test
  script:
    - docker-compose -f docker-compose_deploy.yml up -d
    - docker exec php_1 php bin/console doctrine:schema:drop  --env=prod --full-database --force
    - docker exec php_1 php bin/console doctrine:migrations:migrate --no-interaction --env=prod
    - docker exec php_1 php bin/console app:initialize --env=prod
    - docker exec php_1 bash docker/php-fpm/initialization.sh # this is the old line that included the 3 previous commands until now
    - docker exec php_1 ./vendor/bin/simple-phpunit 

AND THIS DOES WORK!!! So it seems the bash execution ist somehow wrong?

olidem
  • 1,961
  • 2
  • 20
  • 45
  • 1
    What do you mean by your own gitlab-ci runner ? You could launch all the sub commands inside your `.sh` script to avoid one more level of complexity, at least for test purpose – Mcsky Aug 03 '18 at 12:30
  • I have a computer here running a gitlab-runner inside a docker container. And Yes, this is exactly what I did just now, see my edited question. – olidem Aug 03 '18 at 12:44
  • This isn't a problem if you are using the official gitlab runner. I can't figure out why exactly your previous solution isn't working. Did you try to remove `'--no-interaction' => true` ? – Mcsky Aug 03 '18 at 13:42
  • I am of course using the official gitlab runner docker image. – olidem Aug 06 '18 at 20:12

0 Answers0