Я пытаюсь импортировать файл 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 и разные значения по умолчанию. Это тоже требовало некоторого понимания с моей стороны. Наконец, это работает. Это хорошо.
Ошибка на скриншоте выше не видна. Видите ли вы какие-либо подробности в необработанных журналах?