1
0
Files

96 lines
2.3 KiB
PHP
Raw Permalink Normal View History

<?php
declare(strict_types=1);
namespace MintyPHP\Console\Runner\Module;
interface ModuleRunnerInterface
{
feat(console): add db:migrate CLI for idempotent core schema updates 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>
2026-04-29 08:59:57 +02:00
/**
* @return array{command: string, status: string, exit_code: int, vendor_warnings_ignored: int, message: string}
*/
public function dbMigrate(): array;
/**
* @return array{command: string, applied: list<string>, pending: list<string>}
*/
public function dbMigrateStatus(): array;
/**
* @return array{command: string, status: string, exit_code: int, vendor_warnings_ignored: int, message: string}
*/
public function migrate(): array;
/**
* @return array{
* command: string,
* status: string,
* exit_code: int,
* vendor_warnings_ignored: int,
* created: int,
* updated: int,
* unchanged: int,
* deactivated: int,
* total: int,
* message: string
* }
*/
public function permissionsSync(): array;
/**
* @return array{
* command: string,
* status: string,
* exit_code: int,
* vendor_warnings_ignored: int,
* core_entries: int,
* module_entries: int,
* message: string
* }
*/
public function build(): array;
/**
* @return array{
* command: string,
* status: string,
* exit_code: int,
* vendor_warnings_ignored: int,
* mode: string,
* created: int,
* updated: int,
* removed: int,
* unchanged: int,
* message: string
* }
*/
public function assetsSync(): array;
/**
* @return array{
* command: string,
* status: string,
* exit_code: int,
* vendor_warnings_ignored: int,
* message: string
* }
*/
public function deactivate(string $moduleId, bool $confirm, bool $dryRun): array;
/**
* @return array{
* command: string,
* status: string,
* exit_code: int,
* vendor_warnings_ignored_total: int,
* duration_ms: int,
* steps: array<string, array{status: string, exit_code: int, vendor_warnings_ignored: int}>,
* message: string
* }
feat(console): add db:migrate CLI for idempotent core schema updates 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>
2026-04-29 08:59:57 +02:00
*
* The `steps` map is keyed in execution order:
* `db-migrate`, `migrate`, `permissions-sync`, `build`, `assets-sync`.
*/
public function runtimeSync(): array;
}