forked from fa/breadcrumb-the-shire
fs
2e73cb98b4
Existing systems used to have no automatic mechanism for the db/updates/*.sql idempotent updates after `git pull` — devs had to remember which files were already applied and run new ones manually with `mariadb < ...`. Mirror module:migrate to fix this: - New `bin/console db:migrate` walks db/updates/*.sql in alphabetical order, skipping anything already recorded in the new core_migrations tracking table. Each file runs in its own transaction; failure rolls back so the file is retried on the next run. - New `db:migrate --status` lists applied vs. pending files without running anything. Useful for ops debugging "schema seems stale" symptoms. - module:sync now runs db:migrate as its first step, so the standard post-pull command stays a single invocation. README's 3-step setup is unchanged — module:sync now also covers core schema updates. CoreMigrationRepository owns its own mysqli connection (using the same DB credentials as MintyPHP\DB) and runs raw `$mysqli->query()` instead of going through DB::query's prepared statement path — MariaDB rejects some DDL (e.g. ALTER TABLE … ADD CONSTRAINT CHECK) in the prepared protocol, which the existing 18 db/updates files trip on. ModuleMigrationRepository is left untouched (no module migration uses such DDL today and changing the vendor pattern is out of scope). End-to-end verified: against an existing DB the first run applies all 19 idempotent files as no-ops and records them, second run reports "all updates already applied". Against a freshly init'd DB the same thing happens — no double work, no surprises. All encrypted seed secrets keep decrypting because APP_CRYPTO_KEY is unchanged. Tests: tests/Console/CoreCommandsTest covers success/failure/status output shapes against a FakeModuleRunner (mirror of the existing ModuleCommandsTest pattern). 5 stale baseline entries in phpstan-baseline removed (covered by the new @api annotation on the test fixture class). Docs: CLAUDE.md and docs/reference-cli-commands.md document the new command + --status flag; docs/howto-fehlerbehebung.md gains a "schema seems stale after git pull" section pointing at db:migrate --status. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
100 lines
3.2 KiB
PHP
100 lines
3.2 KiB
PHP
<?php
|
|
|
|
namespace MintyPHP\Tests\Console;
|
|
|
|
use MintyPHP\Console\Commands\Database\MigrateCommand;
|
|
use PHPUnit\Framework\TestCase;
|
|
|
|
final class CoreCommandsTest extends TestCase
|
|
{
|
|
public function testDbMigrateSuccessOutputAndExitCode(): void
|
|
{
|
|
$runner = new FakeModuleRunner();
|
|
$runner->dbMigrateResult = [
|
|
'command' => 'db:migrate',
|
|
'status' => 'ok',
|
|
'exit_code' => 0,
|
|
'vendor_warnings_ignored' => 0,
|
|
'message' => 'db-migrate: applied 3 migration(s).',
|
|
];
|
|
|
|
$command = new MigrateCommand($runner);
|
|
|
|
ob_start();
|
|
$exitCode = $command->execute([], []);
|
|
$output = (string) ob_get_clean();
|
|
|
|
self::assertSame(0, $exitCode);
|
|
self::assertStringContainsString('db-migrate: applied 3 migration(s).', $output);
|
|
}
|
|
|
|
public function testDbMigrateFailureWritesToStderrAndReturnsNonZero(): void
|
|
{
|
|
$runner = new FakeModuleRunner();
|
|
$runner->dbMigrateResult = [
|
|
'command' => 'db:migrate',
|
|
'status' => 'failed',
|
|
'exit_code' => 1,
|
|
'vendor_warnings_ignored' => 0,
|
|
'message' => 'db-migrate: failure: Core migration foo.sql failed: SQLSTATE[42S02]',
|
|
];
|
|
|
|
$command = new MigrateCommand($runner);
|
|
|
|
ob_start();
|
|
$exitCode = $command->execute([], []);
|
|
ob_end_clean();
|
|
|
|
self::assertSame(1, $exitCode);
|
|
}
|
|
|
|
public function testDbMigrateStatusListsAppliedAndPending(): void
|
|
{
|
|
$runner = new FakeModuleRunner();
|
|
$runner->dbMigrateStatusResult = [
|
|
'command' => 'db:migrate --status',
|
|
'applied' => [
|
|
'2026-02-23-tenant-scope-global.sql',
|
|
'2026-03-13-seed-default-roles.sql',
|
|
],
|
|
'pending' => [
|
|
'2026-04-29-core-migrations-table.sql',
|
|
],
|
|
];
|
|
|
|
$command = new MigrateCommand($runner);
|
|
|
|
ob_start();
|
|
$exitCode = $command->execute([], ['status' => true]);
|
|
$output = (string) ob_get_clean();
|
|
|
|
self::assertSame(0, $exitCode);
|
|
self::assertStringContainsString('2 applied, 1 pending', $output);
|
|
self::assertStringContainsString('2026-02-23-tenant-scope-global.sql', $output);
|
|
self::assertStringContainsString('2026-04-29-core-migrations-table.sql', $output);
|
|
self::assertStringContainsString("applied:\n", $output);
|
|
self::assertStringContainsString("pending:\n", $output);
|
|
}
|
|
|
|
public function testDbMigrateStatusHandlesEmptyLists(): void
|
|
{
|
|
$runner = new FakeModuleRunner();
|
|
$runner->dbMigrateStatusResult = [
|
|
'command' => 'db:migrate --status',
|
|
'applied' => [],
|
|
'pending' => [],
|
|
];
|
|
|
|
$command = new MigrateCommand($runner);
|
|
|
|
ob_start();
|
|
$exitCode = $command->execute([], ['status' => true]);
|
|
$output = (string) ob_get_clean();
|
|
|
|
self::assertSame(0, $exitCode);
|
|
self::assertStringContainsString('0 applied, 0 pending', $output);
|
|
self::assertStringContainsString("applied:\n (none)", $output);
|
|
self::assertStringContainsString("pending:\n (none)", $output);
|
|
}
|
|
}
|