Я установил мета-команду, как описано здесь 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-runner внутри контейнера докеров. И да, это именно то, что я сделал только что, см. Мой отредактированный вопрос.
Это не проблема, если вы используете официальный бегун gitlab. Я не могу понять, почему именно ваше предыдущее решение не работает. '--no-interaction' => true удалить пробовали?
Я, конечно, использую официальный образ докера gitlab runner.




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