Команда Symfony вызывает другие команды и ждет подтверждения

Я установил мета-команду, как описано здесь https://symfony.com/doc/3.4/console/calling_commands.html

Сначала он удаляет базу данных, затем выполняет миграцию с нуля и, наконец, инициализирует мои данные.

Я столкнулся с этой проблемой, так как недавно перешел с создания схемы через doctrine:schema:create на 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.');
    }
}

хорошо, это работает - ИНОГДА. Когда я выполняю это локально, это работает.

Но я использую все это внутри контейнеров докеров и инструментария Gitlab CI.

Для этого у меня есть сценарий оболочки init.sh

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

который я выполняю на этапе настройки моего тестового действия Gitlab-CI (после запуска контейнера:

docker exec php_container bash init.sh

Результат сводит меня с ума:

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

Это означает, что первая команда выполняется как надо (удаление базы данных), а вторая ждет, пока «пользователь» наберет «y» в качестве подтверждения.

Обратите внимание, что я поставил ОБА --no-interaction, а также $migrateInput->setInteractive(false);.

Странно то, что эта команда хорошо работает локально, но не сразу после того, как Gitlab-CI запускает ее! Редактировать: даже локально, я запускаю контейнер докеров php. Если я выполню здесь на моем Mac docker exec php_container bash init.sh, скрипт будет работать правильно!

Я использую локальный контейнер gitlab-ci-runner на хосте докеров (я отлично работаю уже более года).

Редактировать: Я также попробовал ввести 3 команды в init.sh с тем же результатом. Второй скрипт ожидает подтверждения при запуске из gitlab-ci.

Затем я помещаю три команды непосредственно в gitlab-ci.yml:

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 

И ЭТО РАБОТАЕТ !!! Так кажется, выполнение bash что-то не так?

Что вы имеете в виду под своим собственным бегуном на gitlab-ci? Вы можете запустить все подкоманды внутри вашего сценария .sh, чтобы избежать еще одного уровня сложности, по крайней мере, для целей тестирования.

Mcsky 03.08.2018 14:30

У меня есть компьютер, на котором запущен gitlab-runner внутри контейнера докеров. И да, это именно то, что я сделал только что, см. Мой отредактированный вопрос.

olidem 03.08.2018 14:44

Это не проблема, если вы используете официальный бегун gitlab. Я не могу понять, почему именно ваше предыдущее решение не работает. '--no-interaction' => true удалить пробовали?

Mcsky 03.08.2018 15:42

Я, конечно, использую официальный образ докера gitlab runner.

olidem 06.08.2018 22:12
Стоит ли изучать PHP в 2026-2027 годах?
Стоит ли изучать PHP в 2026-2027 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Symfony Station Communiqué - 7 июля 2023 г
Symfony Station Communiqué - 7 июля 2023 г
Это коммюнике первоначально появилось на Symfony Station .
Symfony Station Communiqué - 17 февраля 2023 г
Symfony Station Communiqué - 17 февраля 2023 г
Это коммюнике первоначально появилось на Symfony Station , вашем источнике передовых новостей Symfony, PHP и кибербезопасности.
Управление ответами api для исключений на Symfony с помощью KernelEvents
Управление ответами api для исключений на Symfony с помощью KernelEvents
Много раз при создании api нам нужно возвращать клиентам разные ответы в зависимости от возникшего исключения.
0
4
350
0

Другие вопросы по теме