freemo
399939a6db
CI / benchmark-publish (pull_request) Has been skipped
CI / build (pull_request) Successful in 16s
CI / quality (pull_request) Successful in 33s
CI / security (pull_request) Successful in 54s
CI / unit_tests (pull_request) Successful in 3m21s
CI / integration_tests (pull_request) Successful in 3m41s
CI / e2e_tests (pull_request) Successful in 3m56s
CI / coverage (pull_request) Successful in 7m38s
CI / docker (pull_request) Has been skipped
CI / lint (pull_request) Successful in 14s
CI / typecheck (pull_request) Successful in 44s
CI / lint (push) Successful in 13s
CI / build (push) Successful in 18s
CI / quality (push) Successful in 28s
CI / security (push) Successful in 40s
CI / typecheck (push) Successful in 1m0s
CI / benchmark-regression (push) Has been skipped
CI / e2e_tests (push) Successful in 4m12s
CI / unit_tests (push) Successful in 5m28s
CI / coverage (push) Successful in 4m27s
CI / integration_tests (push) Successful in 5m50s
CI / docker (push) Successful in 55s
CI / benchmark-publish (push) Has been cancelled
CI / benchmark-regression (pull_request) Successful in 37m42s
Complete the Alembic migration infrastructure by adding CLI commands, improving stamp logic, and adding comprehensive lifecycle tests. Key changes: - Added agents db CLI command group (db.py) with 5 subcommands: migrate (autogenerate), upgrade, downgrade, current, history. All delegate to MigrationRunner which wraps Alembic command API. - Registered the db command group in main.py CLI registration. - Fixed legacy database stamp logic in MigrationRunner to stamp at "head" instead of "001_initial_schema" when pre-Alembic tables are detected. This avoids migration failures when create_all-produced tables already exist (migrations would try to CREATE TABLE and fail with "table already exists"). - Added commit() after stamp to ensure alembic_version is persisted before subsequent operations on the same in-memory database. - Added FakeConnection.commit() method to the mock test infrastructure to support the new commit call in the stamp path. - Added Behave feature (db_migration_lifecycle.feature) with 8 scenarios covering: forward migration, rollback, round-trip, CLI upgrade/current/downgrade, legacy stamp logic, and init_database schema validation. - Added vulture whitelist entries for new CLI commands. Note: init_database() still uses Base.metadata.create_all() as the primary schema creation path. Full migration to Alembic-only init is deferred until ORM model constraints are reconciled with migration scripts (action_arguments UniqueConstraint mismatch). ISSUES CLOSED: #941
51 lines
2.1 KiB
Gherkin
51 lines
2.1 KiB
Gherkin
Feature: Database migration lifecycle
|
|
As a CleverAgents administrator
|
|
I want to manage database schema via Alembic migrations
|
|
So that I can safely evolve the schema with rollback capability
|
|
|
|
Background:
|
|
Given a fresh in-memory database for migration lifecycle testing
|
|
|
|
Scenario: Apply all migrations forward on a fresh database
|
|
When I run all migrations forward to head
|
|
Then the database should have all expected tables
|
|
And the current revision should be the head revision
|
|
|
|
Scenario: Roll back all migrations to base
|
|
Given all migrations have been applied
|
|
When I downgrade all migrations to base
|
|
Then the current revision should be None
|
|
And the database should have no application tables
|
|
|
|
Scenario: Round-trip forward then rollback to initial
|
|
Given all migrations have been applied
|
|
When I downgrade to the initial migration "001_initial_schema"
|
|
Then the current revision should be "001_initial_schema"
|
|
When I upgrade back to head
|
|
Then the current revision should be the head revision
|
|
|
|
Scenario: CLI db upgrade command applies migrations
|
|
When I invoke the db upgrade CLI command
|
|
Then the CLI should report a successful upgrade
|
|
And the database should have all expected tables
|
|
|
|
Scenario: CLI db current command shows revision
|
|
Given all migrations have been applied
|
|
When I invoke the db current CLI command
|
|
Then the CLI should display the current revision
|
|
|
|
Scenario: CLI db downgrade command rolls back
|
|
Given all migrations have been applied
|
|
When I invoke the db downgrade CLI command with revision "m6_004_container_metadata_column"
|
|
Then the CLI should report a successful downgrade
|
|
|
|
Scenario: Stamp logic detects pre-Alembic database
|
|
Given a database with legacy tables but no alembic_version
|
|
When I run init_or_upgrade on the legacy database
|
|
Then the database should be stamped with alembic_version
|
|
And the database revision should be at head
|
|
|
|
Scenario: init_database creates a valid schema
|
|
When I call init_database with an in-memory URL
|
|
Then the resulting engine should have a valid schema
|