Я пытаюсь импортировать файл SQL с помощью следующей команды, используя рабочий процесс действий GitHub. Файл SQL содержит некоторые тестовые данные, которые в дальнейшем будут использоваться для запуска модульных тестов в laravel.
Я не могу понять, неправильный ли путь к файлу или неверная команда импорта. Я сохранил файл SQL в корневом каталоге laravel.
Я столкнулся со следующей ошибкой:
Ошибка: процесс завершен с кодом выхода 1.
Ниже приведена команда, используемая в файле .yml
, который используется в рабочем процессе для laravel.
- name: Importing MYSQL file
env:
DB_HOST: 127.0.0.1
DB_CONNECTION: mysql
DB_DATABASE: test
DB_PORT: ${{ job.services.mysql.ports[3306] }}
DB_USER: root
DB_PASSWORD: password
run: mysql -u root -p password -h localhost --port=3306 test < request_data.sql
Внедрение семян базы данных займет немного времени, поэтому я использую этот способ для импорта .sql
данных. Кроме того, я немного новичок в этом рабочем процессе. дайте мне знать, если возникнут проблемы с запуском команды или если невозможно импортировать существующий файл .sql
.
Обратите внимание, что миграции, которые я выполнил с использованием файла рабочего процесса, выполняются успешно.
Следующий код используется для создания службы MySQL:
jobs:
phpunit:
runs-on: ubuntu-latest
services:
mysql:
image: mysql:5.7
env:
MYSQL_ROOT_PASSWORD: password
MYSQL_DATABASE: test
ports:
- 33306:3306
options: --health-cmd = "mysqladmin ping" --health-interval=10s --health-timeout=5s --health-retries=3
Вот ошибка рабочего процесса:
Заранее спасибо!
код ошибки такой же, как я упомянул в вопросе, и дайте мне знать, как я могу проверить необработанные журналы в действиях GitHub.
Конечно. Кроме того, подтвердите, использовали ли вы то же изображение, то есть mysql:5.7
локально, и нормально ли оно работает на вашей стороне.
да, у меня такой же mysql, даже экспорт mysqldump, похоже, не работает для действий github.
Верно. Не могли бы вы также добавить небольшой файл .sql
? Попробую воспроизвести на своей стороне.
Спасибо! Это полный рабочий процесс в вопросе, который вы используете? Не могли бы вы объединить это, чтобы сделать его одним полным рабочим процессом, и добавить, если чего-то не хватает? Похоже, sudo /etc/init.d/mysql start
не хватает. И в файле .sql
нет запроса на создание БД, то есть для создания test
БД.
@Azeem mysql --host 127.0.0.1 --port 33306 -uroot -ppassword -e «ПОКАЗАТЬ БАЗЫ ДАННЫХ, КАК 'test'», эта команда помогает убедиться, что база данных уже создана и существует, и нам не нужно создавать базу данных
Я попытался воспроизвести этот сценарий в этом рабочем процессе (github.com/iamazeem/test/actions/runs/3960617373/workflow ) с пользовательским .sql
файлом. Работает нормально ( github.com/iamazeem/test/actions/runs/3960617373/jobs/…). Что касается sudo /etc/init.d/mysql start
, я обнаружил, что в раннере предустановлен MySQL, который по умолчанию отключен. И эта команда (а также есть другие варианты с командами systemctl
и service
) используется для запуска этого экземпляра MySQL.
Вот ссылка на ту проблему, где написано, что она отключена: github.com/actions/runner-images/issues/576 (комментарий: github.com/actions/runner-images/issues/…)
Я попытался воспроизвести ваш сценарий с помощью небольшого .sql
файла, но он отлично работает с образом mysql:5.7 Docker.
Вот полный рабочий процесс:
name: MySQL Import Test
on:
workflow_dispatch:
jobs:
import:
runs-on: ubuntu-latest
services:
mysql:
# https://hub.docker.com/_/mysql
image: mysql:5.7
env:
MYSQL_ROOT_PASSWORD: password
MYSQL_DATABASE: test
ports:
- 33306:3306
options: --health-cmd = "mysqladmin ping" --health-interval=10s --health-timeout=5s --health-retries=3
steps:
- name: Import MySQL file
env:
SQL: |
SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
START TRANSACTION;
SET time_zone = "+00:00";
CREATE TABLE `person` (
`id` int(11) NOT NULL,
`name` varchar(255) NOT NULL,
`email` varchar(255) NOT NULL
);
INSERT INTO `person` (`id`, `name`, `email`)
VALUES
(111, 'abc', '[email protected]'),
(222, 'def', '[email protected]'),
(333, 'ghi', '[email protected]'),
(444, 'jkl', '[email protected]');
ALTER TABLE `person` ADD PRIMARY KEY (`id`);
COMMIT;
run: |
mysql --host 127.0.0.1 --port 33306 -uroot -ppassword -e "SHOW DATABASES LIKE 'test';" 2>/dev/null
echo "$SQL" > person.sql
echo "--- SQL ---"
cat person.sql
echo "--- --- ---"
echo "Importing from person.sql file"
mysql --host 127.0.0.1 --port 33306 -uroot -ppassword test < person.sql 2>/dev/null
echo "Checking the imported data"
mysql --host 127.0.0.1 --port 33306 -uroot -ppassword test <<< 'SELECT id,name,email FROM person;' 2>/dev/null
Выход
Database (test)
test
--- SQL ---
SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
START TRANSACTION;
SET time_zone = "+00:00";
CREATE TABLE `person` (
`id` int(11) NOT NULL,
`name` varchar(255) NOT NULL,
`email` varchar(255) NOT NULL
);
INSERT INTO `person` (`id`, `name`, `email`)
VALUES
(111, 'abc', '[email protected]'),
(222, 'def', '[email protected]'),
(333, 'ghi', '[email protected]'),
(444, 'jkl', '[email protected]');
ALTER TABLE `person` ADD PRIMARY KEY (`id`);
COMMIT;
--- --- ---
Importing from person.sql file
Checking the imported data
id name email
111 abc [email protected]
222 def [email protected]
333 ghi [email protected]
444 jkl [email protected]
Кроме того, команда, т. е. sudo /etc/init.d/mysql start
(и ее другие варианты, например, service
и systemctl
), предназначена для предустановленной MySQL. Вот актуальная проблема: https://github.com/actions/runner-images/issues/576
В вашем сценарии, поскольку требуется протестировать контейнер Docker, выдача команд для локально установленного MySQL (который отключен по умолчанию) вообще не требуется.
Я также смог импортировать файл sql, используя mysql -Dtest -uroot -ppassword -h127.0.0.1 -P33306 < "request_data.sql"
Спасибо за ваши старания. вы пробовали оба пути. используя команды sql и файл sql.
@Ankit: Приятно слышать. Ваше здоровье! :)
@Ankit: Добро пожаловать! Да, мне нужно было проверить, действительно ли были импортированные данные, поэтому я использовал второй встроенный запрос вместо добавления его в файл. Тем не менее, сочетание предустановленного MySQL по умолчанию и одного через докер было хорошей находкой. :)
Я использовал локальный хост вместо 127.0.0.1 перед разрешением, и это не сработало, и я долго не замечал.
@Анкит: Верно. Кроме того, предустановленный и тот, что находится в докере, имеют разные настройки конфигурации через env vars и разные значения по умолчанию. Это тоже требовало некоторого понимания с моей стороны. Наконец, это работает. Это хорошо.
Ошибка на скриншоте выше не видна. Видите ли вы какие-либо подробности в необработанных журналах?